Monthly Archives: October 2017

TFL JamCam Video Feeds Integrated into CASA ViLo

For a number of years TfL have been providing open access to feeds from over 170 traffic cameras or ‘JamCams’ distributed at key locations across London’s road network. In addition to static images each camera also provides a five second video which is updated every 5 minutes. The feeds of these videos have now been incorporated into CASA’s ViLo platform.

I’d been fascinated by the videos for some time. Every morning when I arrive at CASA I check out CASA’s London CityDashboard which we have on in our reception area. The dashboard includes two static images from the cameras chose at random along with a looped video feed from another in the top right.

I was always struck by the sense of ground truth the cameras seemed to offer for a particular place. At the same time I was frustrated by the fact that I couldn’t get a sense of the wider context: What’s just out of shot? What’s the wider context in which each camera is situated? What’s going on over at the next nearest camera and the rest in the surrounding area Incorporating the feeds from those cameras into ViLo provides a spatialised sense of context in a way that the dashboard can’t. The 3D models also help users understand the orientation of each camera in a way that a map might not. Finally their incorporation in ViLo also facilitates comparison with other spatialised streams of data data.

By comparison with other real-time feeds like TfL’s real-time bus information the traffic cameras provide a much richer sense of what is happening in an area, at least within the five minute time scale provided by the video updates. Not only do we get a sense of the flow of traffic and any blockages, the information provided by the cameras also provides a wider situational awareness of factors like local weather conditions and pedestrian footfall. In this way the information they provide offers a degree of validation to other data sets that can be particularly useful when additional context is required for decision making by city officials and members of the public alike.

Thanks to Oliver O’Brien and Steven Gray for providing access to the TFL Traffic Cam data via CityDashboard the Big Data Toolkit.

 

Advertisements

Roames: Virtual Asset Management With Unity

Roames is a Unity-based 3D data visualisation platform created by Dutch company Fugro for the purpose of asset management. In particular it has been used to visualise LiDAR point clouds as the basis for the management and maintenance of power networks. In the video below Glen Ross-Sampson and Peter O’Loughlin from the Fugro Roames team discuss the challenges involved in creating a platform for geospatial data in Unity.

Behind the scenes Amazon Web Services (AWS) are used to provide scalable computation for processing large amounts of point cloud data. Algorithms are run on the AWS clusters to classify and extract different types of features from the point cloud. These include power lines, poles, vegetation and buildings. Further business rules can then be applied and visualised to help users make decisions. In this case they helped Ergon Energy in Australia assess the risk of damage to overhead power cables caused by growing vegetation. The benefit of this kind of ‘virtual asset management’ is that it allows clients like Ergon to make assessments about the assets they manage without having to send crews to inspect every site. By prioritising those sites most at risk they can expect to make significant savings.

Roames was the outcome of a five year project. Unity was chosen as the visualisation client because commercial GIS software didn’t provide the performance they required. They also wanted to be able to customise the interface and experiment with simulation. Using Unity enabled the team to prototype without having to build low level functionality from scratch.

The system allows the user to explore the scene in real-time. Data are streamed in to the scene and unloaded dynamically with the aid of memory and hard-disk caches. Changing level of detail (LOD) is used to support zooming the view from out of space all the way in to a ground level view. As the user zooms in points are replaced by a voxel representation. All of this is achieved using Amazon S3 for cloud storage.

As well as discussing the motivation behind Roames’ and their technical stack the talk does a great job of discussing some common problems and solutions in working with large spatial data sets in Unity.

Technical notes:

Regionation – Map data in Roames is structured according to the Tile Map Service (TMS) specification developed by the Open Source Geospatial Foundation (OSGeo) and served via a Rest API endpoint. Tiles of different LOD are provided based on proximity to the camera. This is also used when the camera is tilted to ensure lower levels of details are used for objects that are further away.

Floating Point Precision – Unity using 32-bit single precision floating point numbers to store the positions of assets. This gives an average accuracy to 7 significant figures. The need to map data across the whole globe to millimeter precision. However, on the scale of the globe accuracy to the nearest metre alone requires 8 significant figures. The spatial uncertainty this introduces is visibly represented by an onscreen spatial jitter. This was resolved by storing the positions of objects with 64-bit double precision and using a floating origin. The floating origin was achieved by setting the position of the main camera to the Unity world origin (0,0,0) each frame and moving the other objects relative to that position rather than moving the camera.

Manipulating large numbers of objects – Manipulating the positions of thousands of objects is computationally expensive and reduces the frame rate. The Roames team used a number of evenly distributed empty game objects or ‘terminal nodes’ as references that other objects could be parented to. This meant Instead of updating the positions of all objects in the scene they just had to update those of the terminal nodes.

Memory Management – As objects are loaded and removed from the scene their are spikes in activity caused by lags in Unity’s automated memory management or ‘garbage collection’; the process by which unused memory is freed for reuse. These issues were resolved by reusing existing objects to avoid allocating more memory and making those objects static where possible. Use of for loops or enumerators was recommended over foreach loops which allocate memory internally. Reducing the amount of string manipulation is also recommended.

Scratch Arrays – Roames introduced their own ‘Scratch Array’ pattern to resuse commonly sized arrays.

Binary Formats – Rather than use KML which is a verbose, text-based XML format, Roames uses the Binary PLY format which performs much better. This reduced file sizes and improved load times and garbage collection allocations.

In order to display the points efficiently they are batched into single meshes on 65,000 vertices. They also lower the density of their clouds prior to loading.

The Core Engine and the other aspects of the product like the user interface were separated to make the project easier to handle. This enabled the 14 developers on the project to work more efficiently. It also meant that other custom tools could be quickly developed in separation from the main project.

The team’s goals going forward to get the product working across the web, to open the Core API to developers, and to start using Unity physics for simulations.