Why is this of interest to Ordnance Survey, a 230-year-old organisation with a history of creating maps? Put simply, creating these built environment simulations is inherently a place-based challenge. It involves creating accurate, consistent and trusted geospatial data that can be relied upon to help deliver results that enable the outcomes being sought.
The OmniCAV project was conceived to accelerate the testing of autonomous driving systems through simulation, so when OS were invited to participate we jumped at the chance. Building a digital representation of the built environment to support self-driving is the kind of challenge we enjoy and would give us great insight into the future geospatial data requirements in this important developing area.
OS were tasked with providing the baseline information for the simulation route – the “digital map” for want of a better term. It would have been easy to provide data from one of our many existing digital products that already contain rich information about the roads, buildings, addresses and features in and around the areas required, but to support the ambitions of the simulator, a new type of data was needed.
The chosen route comprised a loop of approximately 32 kilometres, taking in the town of Abingdon, the western fringes of the city of Oxford and various villages in the Oxfordshire countryside. The route is a mix of urban and rural environments which is significantly different to other self-driving testing areas developed to date in the UK, that have often been far more controlled or based around one particular type of environment. The route includes hamlets, farms, narrow roads and many, many trees and bushes as well as built-up urban environments and complex, busy road junctions – a true representation of the UK’s road environment. A digital 3D geospatial model of the route was required to be produced and this needed several different data sources to complete it fully. The specification agreed with partners meant that no one single method of capture or existing data source would provide everything required from features to imagery and attributes, or to get the level of accuracy. To support this, high accuracy control surveys had to be carried out to capture ground control information along the route; a road vehicle mounted mobile mapping system with multiple sensors used to drive the route and airborne surveys used to fill in the detail away from the immediate environs of the road. Ordnance Survey took on the role of creating the geospatial data model, using input from Korec and GeoXphere, who supplied the raw data from mobile mapping and aerial survey systems, respectively. A Trimble MX9 mobile mapping system captured both imagery and lidar data of the route. The Oxfordshire loop was driven twice in the daytime (clockwise and anticlockwise) and twice in the nighttime (clockwise and anticlockwise) to produce multiple views of the same route, important to ensure coverage of all features that may be occluded by parked cars. Lidar point clouds from the different passes were combined and each point was assigned a colour from the daytime imagery. Processing large volumes of this type of data can extremely time-consuming, so to mitigate against this the point clouds were “thinned” to provide a dataset which was dense enough to model the surface of the road in sufficient detail but not too dense to make the 3D model too unwieldy. Surface modeling needs to be accurate but smooth as even small imperfections can be noticed in “clean” simulation environments.
Aerial imagery was collected using XCAM, an oblique camera system which is flown in an advancing circular path rather than the traditional series of straight lines. This enables multiple views of every point on the ground and allows objects such as buildings to be viewed from many different angles.
In order to build the 3D models used in the simulation, many different skills were employed, including the capture of kerbs and road edges, the crafting of 3D objects for all the features encountered on the route, the creation of terrain surfaces and the collection of the positions of all the street furniture and vegetation lining the route. Coordination of all these skills and requirements is complicated and a lot was learned throughout the process.
For example, it was originally thought that a “traffic light” could be treated as a single object that could simply be copied and pasted into the model at the appropriate positions. It soon transpired that traffic lights come in many different configurations (including red-amber-green, red-amber-green_right_arrow, red-amber-green_left_arrow, red/amber/green_straight_arrow, and many more), each of which needed its own model. The nature of the road itself was also more complex than previously envisaged. Upright, uniform and crisp kerb edges at the side of the road are not common across rural areas. Instead the edges of the road are often obscured by vegetation, mud or leaves and it is a challenge to define a linear representation of the road edge, as was needed in the model. These had to be modelled as a “closest possible” representation of the real-world, with some acceptance that this would never be entirely accurate but that the simulation could introduce scenarios and vagaries to create an experience as close as possible to reality. All of these complexities, and the constraints on time and resources, meant that delivering the whole route to such an immense level of detail was a significant challenge. It was agreed that a set of data models that would satisfy the requirements of the simulator in the timescales required based around a set of representative “areas of interest” would be delivered. These were captured to the full data specification, while the areas between were captured to a lower level of accuracy. This will allow us to establish a ‘standard’ for the level of accuracy required to support the functions of a simulator designed for CAV development testing and in the future, potentially certification testing. Full resolution vector data, describing the road network, was provided for the entire route – this was a more simplistic data offering o the whole route that could also be used in the simulation environment.
All in all, preparing geospatial data for simulation of self-driving systems is a complex task with many different requirements depending on the scenarios and technology to be tested. At this time there is no one single standard, set of standards or industry best practice for the preparation of this data. We believe as data accuracy levels and industry requirements are agreed, that the complexity and cost to create 3D models for multiple uses including test and simulation environments will reduce as the industry moves from R&D/concept demonstration phase into production.
Ordnance Survey, working with Zenzic and industry, developed a study of the type of GeoData required for such outcomes including recommendations that begins to set the scene for how test and simulation environments can be develop using location information. To summarise, drivers have used paper maps, and more recently satellite navigation systems, for many years; maps for self-driving vehicles, however, need to be more detailed, and are often referred to as high-definition (or HD) maps. These HD maps are more complex than maps used for simple driver-based navigation systems. Mapping must be highly accurate (better than 5 cm in resolution) and needs to contain a minimum set of road information – for example, lane-level geometry, and information relating to street furniture. OmniCAV provided us with a fantastic opportunity to test those recommendations and learn more about future requirements and we look forward to the next phase in this exciting collaborative project.
OS continues to work with industry and organisations such as CCAV and BSi to develop the location requirements and standards for the future of mobility.