Open HD map service model: an interoperable high-Definition map data model for autonomous driving

ABSTRACT

With the growth in the vehicle industry, autonomous driving has become a hot topic worldwide and has attracted increasing attention from both industrial and academic sectors. Maps, as pivotal geospatial information carriers, play a vital role in route planning and navigation service. Compared with conventional maps, high-definition (HD) maps possesses higher precision, richer information, and various services and are regarded as critical infrastructure for autonomous driving. However, heterogeneous HD map data standards and models have different characteristics and advantages, and thus they rarely meet all autonomous driving requirements for different driving objectives. This research presents an interoperable map data model, the Open HD Map Service Model (OHDMSM), to provide a reference for HD map development. The designed OHDMSM, which contains three data layers and a set of corresponding interfaces, demonstrates high interoperability for HD map data fusion and application. As a proof of concept, an HD map data system is implemented with all functions following the designed data model and interfaces of OHDMSM. The design and development of OHDMSM data structures, interfaces and systems will benefit data requesting, updating, and interoperation for HD map data worldwide, which can be helpful for developing autonomous driving and intelligent transportation in the Digital Earth.

KEYWORDS:

• HD map
• data interoperation
• autonomous driving
• data standards
• smart cities

1. Introduction

With the growth of the vehicle industry, autonomous driving for connected and autonomous vehicles (CAVs) has become a hot topic worldwide (Levinson et al. 2011; Seif and Hu 2016; Guanetti, Kim, and Borrelli 2018; Li et al. 2019; Liu, Wang, and Zhang 2020; Feng et al. 2021; Liu et al. 2022). Related research can contribute to developing intelligent transportation and the Digital Earth (Chen et al. 2014; Mamede 2022). Recently, many companies and research groups have increased their interest in developing autonomous driving, such as Google, BMW Company, FZI Research Center for Information Technology, and Stanford Artificial Intelligence Laboratory (Aeberhard et al. 2015; Levinson and Thrun 2010; Schreiber, Knöppel, and Franke 2013; Fairfield and Urmson 2011). As the key geospatial data source, maps contain much information for driving, including roads, junctions, obstacles, and points of interest (POIs). Hence, maps can provide the required semantical understanding of roads with an unlimited field of view under any condition and play a key role in navigation (Epstein et al. 2017; Goodchild 2022). Conventional maps, generally speaking, rarely meet the requirements for autonomous driving. Compared with traditional navigation, autonomous driving has more requirements for mapping, such as higher precision, richer information and real-time interactions. High-definition (HD) maps, which contain detailed information about lanes, traffic lights, and relevant objects with higher precision, are regarded as the key infrastructure for autonomous driving (Seif and Hu 2016; Chu et al. 2018; Jo, Kim, and Sunwoo 2018; Liu, Wang, and Zhang 2020; Li, Shao, and Zhang 2020; Shao et al. 2022). In addition, the HD map should provide more interactions with dynamic or real-time data (e.g. data requesting and processing) for advanced requirements, such as assisting vehicle positioning. Hence, the development level of HD maps can enrich the functions of autonomous driving, such as route planning, obstacle avoidance, and driving control. In addition, with massive detailed static or dynamic digital information collected, the HD map can be a paradigm for Big Earth Data science (Guo et al. 2020).

Recently, many data standards for HD maps have been designed and developed by different groups and organizations, such as OpenDRIVE, Navigation Data Standard (NDS) Open Lane Model, RoadXML, and Lanelets (Dupuis and Strobl 2010; Navigation Data Standard Association 2016; Millet 2020; Bender, Ziegler, and Stiller 2014). However, these data standards still have some limitations for advanced requirements in modern cities, such as the highly densified and vertical city of Hong Kong. The rapid development of cities brings more challenges to HD map design, including autonomous driving for nonvehicles (such as wheelchairs and delivering unmanned aerial vehicles (UAVs)) (Li et al. 2023), various complex and dynamic information in HD map data, function services for data updating and additional requirements, and interoperation with other data standards. The detailed challenges are listed below:

1. Due to rapid urban and rural development, an extensible and flexible data model is needed for increasing features. The data model should have a well-developed structure and a system that can extend feature types. It should also support different kinds of driving objects, such as wheelchairs and delivering UAVs.

2. Autonomous driving requires various data interactions with HD map data. The data interactions between driving systems and data sources have different requesting or updating interfaces. Different kinds of interfaces stunt data interaction among different autonomous driving systems.

3. Due to the heterogeneity of different HD map data standards, they cannot use data based on other standards directly. However, different HD map data standards have different advantages and shortcomings. Hence, the HD map data should have the ability to interoperate with other standards that can utilize the advantages of these standards for data fusion and application.

In summary, we need an HD map data model with a flexible and extensible data structure, enriched interactive interfaces, and interoperability with other standards. This research describes an HD map data model named the Open HD Map Service Model (OHDMSM) for autonomous driving and implements a system as a proof of concept for the designed data model. The OHDMSM has three data layers (i.e. static map layer, dynamic data layer, and real-time data layer) for data description and interactive interfaces (i.e. data requesting, updating, and interoperating) by web service, which can be helpful for intelligent autonomous driving.

The following sections are organized as follows. Section 2 introduces the background and related research on this topic. Section 3 presents the design of the OHDMSM, including the detailed design of data structures and interactive interfaces. Section 4 introduces the implementation of an HD map system and a case study to validate the above design. Section 5 discusses the advantages and limitations of this research. Section 6 presents the conclusions and potential directions for future work.

2. Literature review

As an intelligent map, a high-definition (HD) map has higher accuracy and richer information that can be used not only for autonomous driving but also for urban planning, safety, and smart cities (Dannehy 2016; Vardhan 2017; Liu, Wang, and Zhang 2020). Hence, HD map standards also have many relevant research trends, such as data structure descriptions, grid map applications, and data processing platforms. For HD map data structure description, many companies and associations have designed and promoted many standards, especially in Europe. OpenDRIVE is a popular data standard promoted by the Association for Standardization of Automation and Measuring Systems (ASAM) (Dupuis and Strobl 2010). It is an HD map data structure for describing the location, association, and features of lanes in maps for autonomous driving. OpenDRIVE also has several tool supports, and a certain number of companies (such as BMW and Baidu) use it as an essential standard for developing autonomous driving systems (Althoff, Urban, and Koschi 2018; Yu et al. 2021). ASAM also designed a data format named OpenSCENARIO for dynamic content of driving and traffic simulators (Association for Standardization of Automation and Measuring Systems 2022). It can record multiple traffic participants by actions or trajectories (e.g. pedestrians and vehicles). The Navigation Data Standard (NDS) is widely applied by driving navigation (NDS 2022). The NDS Open Lane Model is an open standard that has highly accurate lane data and, thus, enables next-generation autonomous driving (NDS 2016). It contains massive highly accurate data structures (e.g. lanes, boundaries) for autonomous driving. It also has full NDS format standards for dynamic information in HD maps. RoadXML is an open file format first developed in 2009 for the logical description of road networks (Millet 2020). It contains data layers that can meet the needs of driving simulator applications. Lanelets is an efficient map representation for autonomous driving (Bender, Ziegler, and Stiller 2014). It is an atomic data structure and can carry other kinds of additional data in maps for autonomous driving. The ISO/TC 204 Intelligent transport systems Technical Committee in International Organization for Standardization (ISO) published an overall data specification named Intelligent transport systems – Geographic Data Files (GDF) (ISO/TC 204 Intelligent transport systems 2020). It provides conceptual and logical data models and physical encoding formats for intelligent transport systems, which can be applied for HD map data description.

In addition to vector maps, grid maps are also an important data source for autonomous driving. Related research can be used for mapping and autonomous driving system development. For example, Deep Grid Net is a deep learning system for autonomous driving using a grid map (Marina et al. 2019). NeuralMapper is a deep neural network-based method for grid map large-scale mapping (Cardoso et al. 2020).

Data processing platforms can be used for data production, collection, and processing, and massive companies and research groups focus on this topic. DynamicMap is a dynamic and static data collection platform for HD map production and related research (Watanabe, Sato, and Takada 2020). It is a platform that uniformly treats features in HD maps (e.g. static data and dynamic information). Research groups from Wuhan University focus on data collection platform development from crowdsourcing (Zhang, Zhang, and Liu 2021). This platform can collect volunteered data from onboard equipment in vehicles (e.g. cameras, Global Navigation Satellite System (GNSS), and Radio Detection and Ranging (RADAR)). Another research group from Konkuk University designed an edge-fog-cloud system that aims to produce an HD map with data from autonomous vehicles (AVs) (Lee et al. 2020). They designed a fog computing server model that can generate a high-definition (HD) map by light detection and ranging (LiDAR) data.

3. OHDMSM design

This research presents an interoperable data model named Open HD Map Service Model (OHDMSM), which is designed for HD map data fusion and application on the web for autonomous driving. Hence, it provides a flexible data structure for HD map feature recording and interfaces for various interaction requirements in autonomous driving. As shown in Figure 1, the OHDMSM has three data layers for data description and three kinds of interfaces for related function implementation. The data layers in the OHDMSM include the static map layer, dynamic data layer, and real-time data layer. The static map layer is designed to store the static objects of the map. The dynamic data layer can record the dynamic information for roads and the environment information. It can be regarded as the information supplement for the static map layer. The real-time data layer is designed to store the data that need to be updated frequently (e.g. walkers, other vehicles, and traffic signals). The interactive interfaces for OHDMSM include data requesting, data updating, and data interoperating. The interfaces for data requesting are designed for the data requirements of car systems and drivers, including information for autonomous driving/assisting driving/navigation, assisted positioning, and special needs (e.g. parking, gas/charge). The interface for data updating aims to gather data from different sources for corresponding data layers, including basic map data, measurement data, public data, and volunteered data. The interfaces for data interoperating can help users convert data in other formats (e.g. OpenDRIVE, Open Lane Model), which are helpful in further application and collaboration.

Figure 1. Framework of the OHDMSM (Open HD Map Service Model).

The classification of OHDMSM objects depends on the data updating frequency. As shown in Figure 2, the objects that update monthly or daily (e.g. roads, lanes, trees, buildings, or others) can be classified in the static data layer. The data source in the static data layer should be existing map data or measurement data. The dynamic data layer includes road-related and environmental information (e.g. road work, ground condition, and weather) that is updated hourly or shorter. The information in the dynamic data layer can be public information from the web that is linked to objects in the static layer. The information in the real-time data layer is updated by seconds or shorter. They always come from volunteered interactions around the required object. The following subsections illustrate the data structure in different data layers and the detailed interface design.

Figure 2. The objects in three layers in the OHDMSM.

3.1. Detailed design of the data model

3.1.1. The static map layer

This layer is a data layer for basic map data and contains road networks, lanes, roadside features, restrictions, etc. The data in the static map layer would not be updated frequently or would be updated only by need. As shown in Figure 3, the data in the static map layer have four parts: metadata, nodes, roads, and junctions. The metadata have attributes such as name, ID, version, and spatial reference. The nodes are the collection of points in the data layer. The features in this layer use Cartesian coordinates for spatial location recording. All the points in this layer have three attributes for spatial location: X, Y, and Z. The meaning of X, Y, and Z should be referred to by spatial reference in metadata. Roads and junctions are collections for road networks. They all have geometry for shape description and links for topology description. In addition, they also have specific attributes, such as LaneCollection (for lane description), Restriction (for obstacle description), Feature (e.g. gas station, shop, streetlight, manhole cover, waste bin), and Signal. In our junction design, it can not only stand for conventional traffic crossings but can also be used for any points on the road for stops or with signals. A detailed description of the attributes can be found in the supplementary document, Table 1.

Figure 3. Data structure of the static map layer.

There are some special statements for the attributes in the static data layer. The Geometry attribute describes the outline of different objects in the layer. The Type of Geometry is designed to distinguish different types of shapes, including points, lines, polygons, and 3-D objects, which can present different shape types, and Points stores the necessary discrete point index in the Nodes. If the objects are 3D, their geometries are minimum oriented bounding boxes. The points store the outline of the bottom surface of 3D objects, and the Height is the extension of the third dimension. The Links can store the topologic relationship (e.g. left lane, right lane, successor, and predecessor) between different objects and give the mark for permission if the driving object can cross it by Cross. The Material can store the surface material information of the object (e.g. lanes, features). The material information can help autonomous driving systems judge the object by pattern and color using sensors (Fujiyoshi, Hirakawa, and Yamashita 2019). In addition, driving control in different materials on roads can benefit road pavement maintenance, which can be helpful for sustainable development (Chen, Song, and Ma 2020). Lane and Speed have different traveling applicable subjects, which can be marked in Subjects (e.g. walker, vehicle, and bicycle).

In this model, part of the fields is flexible for description, such as Type/Props in the lane description and Pattern in the material description. However, this does not mean that it can be marked irregularly. In the case of ambiguity and repetition for the same objects, we use field dictionaries to store different keywords of these fields. Each item in the corresponding dictionary has a key, a code, a related description, and a demo image. For example, as shown in Figure 4, in the dictionary, to describe different types of roads, we can use a string to define expressways, and the key can be described as ‘Expressway’ with code ‘RT00001’, which can be recorded in the road type dictionary. In this research, we also define massive frequently used items in field dictionaries, such as left-turn in the type of lane and pedestrian-crossing in the type of restriction. With the help of field dictionaries, the OHDMSM can be compatible with heterogeneous road conditions around the world. It has strong extensibility in the future and flexibility to apply it to other HD map data standards. The requirement and updating of each dictionary will be stated in Section 3.2.2.

Figure 4. Different road types in the field dictionary.

3.1.2. The dynamic data layer

This layer records dynamic traffic information or related environment information, including road construction, temporary traffic restrictions, traffic flow, and sorronding environmental conditions (such as weather and icy road). Dynamic data are designed as supplementary information for static maps that can help human or autonomous driving systems redesign routing or optimize navigation strategies. Hence, the data in the dynamic data layer are always updated by hour or shorter. The data structure of the dynamic data layer is shown in Figure 5. This layer has four parts: metadata, nodes, restrictions, and weather. Similar to the static map layer, metadata are the basic information of this layer, and nodes are the collection of the points in this layer. Restrictions are used to record different kinds of temporary restrictions (e.g. road work, traffic control, and traffic incidents), which can be distinguished by field Type. As shown in Figure 6, related regions of restrictions can be stored in the field Targets, which can be bound with the objects in the static map layer or customized by Geometry. Each restriction can also have several limitation rules (e.g. blocked, low speed, and no entry for trucks), which are stored in the Limitations fields. In addition to these fields, the restriction also stores start time, end time, and appended description by the Start, End, and Note fields. The weather can present information about local weather, including temperature, rain, snow, wind, fog, and visibility. It can also store warning information by field Warnings, such as road freezing, storms, and landslides. A detailed description of the fields in this layer can be found in the supplementary document, Table 2.

Figure 5. Data structure of the dynamic data layer.

Figure 6. The relationship between restrictions in the dynamic data layer and objects in the static map layer.

3.1.3. The real-time data layer

This layer is designed to store the data of active objects or information around the vehicle, such as traffic flow, cars, walkers, and traffic signals. The data in this layer are always collected by sensors around roads or on other vehicles. The real-time data layer can help driving systems react in driving or avoiding obstacles. The information in real-time is designed for connected vehicles, which obtain surrounding information from the web (Lu et al. 2014). Autonomous vehicles, which are equipped with adequate sensors, can also require real-time data for blind area information (Lv et al. 2022). Therefore, the data in this layer are always updated by seconds or milliseconds. As shown in Figure 7, in addition to the general metadata mentioned above, the real-time data contain information about traffic flow, vehicles, walkers, signals, and service facility loads. The traffic flow information is stored in the TrafficFlows field, which stores the level of crowding by field Flow and the mean speed of vehicles by field Speed. The active vehicles, walkers, and other moving subjects can be recorded in the MovingObjs field, which can be distinguished by Type. MovingObj can record the position information, shape information, velocity, customized information, and related points stored in Nodes. The Signals store the current status of traffic signals in junctions. It can be linked to the signal in the static map layer and provide the current status and signal rules. ServiceLoads are designed to record the service load of service POIs, such as gas/charge stations and parking spaces. The ServiceLoad can store its type, availability, maximum, load level, and other attributes and be linked with the facilities in the static map layer. Any unclassified events that occurred on the ground can be recorded in Events, which has type, position, and customized attributes for the related description. A detailed description of the fields in this layer can be found in the supplementary document, Table 3.

Figure 7. Data structure of the real-time data layer.

Similar to the dynamic data map, the data in the real-time data layer should also be linked with the static map layer. Due to the high timeliness of real-time data, all objects in this layer have the field Update, which means the recording time. Hence, all objects have a tight relationship with the requesting interface, so they can be updated separately. For example, through the specific web interface, users can request the traffic signal data by signal ID. The detailed statement can be found in Section 3.2.1.

3.2. Detailed design of interfaces

3.2.1. Interfaces for data requesting

The interfaces for data requesting are designed to provide information services for navigation, autonomous driving, assisted positioning and POI services. The interfaces should provide the information around the vehicle or by object ID (e.g. gas station) from three layers in the OHDMSM. Because data in different layers have different timeliness and organization methods, this research provides various approaches for data requesting in different layers. First, the static map layer can be divided into massive areas for data requests. With a located position, users can obtain the data in the located area and nearby areas. As shown in Figure 8, the vehicle is located in area A, and can obtain information about areas A, B, and D from the static map layer. Then, the dynamic data layer, as a supplement for the static map layer, should keep the same area dividing method as the static map layer. As shown in figure 8, the data in the dynamic data layer can also provide information about areas A, B, and D by the located position. Different from the static map layer and dynamic data layer, the real-time data layer has higher timeliness, so the data requesting for real-time data requesting are based on the current position or obtain the service information binding with the static map layer. As shown in figure 8, the vehicle gives a position and gets the real-time data (e.g. active vehicles and walkers) around (within a certain distance) from the real-time data layer by interfaces. In addition, vehicles can also obtain the load level of gas stations by POI service interfaces and gas station IDs, which can be found in the static map layer. The detailed interface design for data requesting can be found in supplementary document, Table 4.

Figure 8. Data requesting from different layers by interfaces.

3.2.2. The interface for data updating

The interfaces for data updating are designed for data updating. Due to the wide variety of data in HD maps, HD maps need massive kinds of data sources. As shown in Figure 9, the data in the static map layer always come from basic map data and measurement data. For example, the road network always comes from existing map data (e.g. adjusted Open Street Map (OSM) data or data from government offical websites), and lane lines come from measurement data, such as measuring packets or measuring cars. The data in the dynamic data layer are always collected by measurement or public data gathering, so the interface should provide related functions. For example, information about restrictions and temporary obstacles is always measured by professional users, and information about traffic flow, temporary restrictions (such as traffic accidents and control) and the environment (such as weather or icy road warnings) is gathered from web or government announcements (i.e. news from media). The real-time data layer collects data from the public, volunteers, and more frequently. Hence, the interface in these data should have much more load capacity. In addition to interface publishing, the interfaces for data updating also provide data fusion service integration in the interface that can process the raw data. The detailed interface design for data updating can be found in supplementary document, Table 5.

Figure 9. Data updating for layers by interfaces.

As mentioned in Section 3.1.1, some of the objects in the OHDMSM are abstract and flexible, and we use field dictionaries to distinguish them. Therefore, in data updating, different data sources should follow the existing items in field dictionaries. For example, if a terminal wants to share real-time walkers’ information and the field dictionary for the type of MovingObj has the item named ‘Walker’, it cannot update the data with other keywords, such as ‘Pedestrian’. If the field dictionary does not have a corresponding item, we also provide an interface to apply the new field dictionary item. To date, the system has 22 field dictionary types, including Lane, Feature, Restriction in the static map layer and MovingObj in the real-time data layer. The detailed field dictionaries can be found in supplementary document, Table 6.

3.2.3. Interface for interoperating

The interfaces for interoperating are designed to provide functions to interoperate with other HD/general map standards or formats (e.g. OpenDRIVE and OSM). It can provide several functions to receive other HD/general map data to OHDMSM or format OHDMSM-based data to other formats or standards. As shown in Figure 10, the designed interfaces can receive data from various data sources with heterogeneous data standards and formats. With the help of data processing in the HD map system, the data can be formatted as different popular HD map data standards (e.g. OpenDRIVE and Open Lane Model), which are widely accepted by existing CAVs.

Figure 10. Data interoperation among different data standards or formats by interfaces.

The interfaces for data interoperating are also helpful for data fusion with the interfaces for data updating. For example, users can convert the data in OSM to OHDMSM as basic data and use the interfaces for data updating to enrich the detail. Hence, the interfaces for data interoperating can be helpful for collaboration or applications with other HD/general map formats or standards. The detailed interface design for data interoperating can be found in supplementary document, Table 7.

4. An HD map system implementation

4.1. HD map data system design

As proof of the OHDMSM and relevant interfaces, we developed an HD map data system based on the design above. As shown in Figure 11, the system has a database, four modules, and two kinds of interfaces. We design a lightweight system that can reuse distributed services from volunteers for related data processing and conversion.

Figure 11. Framework of the HD map system.

The system uses node.js as a server for services publishing. The database is designed to store the data in OHDMSM, which uses MongoDB to store related JSON-based data. The four modules in the system are the data processing module, data-indexing module, interoperation module, and visualization module. The data processing module processes the raw data from data providers for updating. The data-indexing module is designed to provide the spatial index for the data stored in the database. The interoperation module can provide interoperation functions for different HD map data standards or formats with OHDMSM-based data. The visualization module in this research used Cesium.js SDK as the visualization foundation component. It can provide visualization functions for various data types in this OHDMSM on the web. The data processing module and interoperation module can link the services that can help the system process the raw data and interoperate with other standards.

In this research, we choose the Open Geographic Modeling and Simulation (OpenGMS) standard as the data processing plug-and-play module standard. Users can wrap their data processing methods in OpenGMS standards that can be contributed as services on the web. OpenGMS is a platform that can help users share and reuse geo-analysis models on the web (Chen et al. 2020; Zhang et al. 2021a; Ma et al. 2022). The OpenGMS Wrapper System is software that can publish models on the web as a service (Zhang et al. 2019). Users or applications can invoke published model services by related SDK (Zhang et al. 2020). In addition, OpenGMS can also provide a distributed computing solution for volunteers’ models or data processing methods (Zhang et al. 2021b). With the help of OpenGMS SDK, the data processing module and interoperation module can reuse the related model services from volunteers worldwide.

As proof of the OHDMSM, the system also publishes the corresponding data interfaces designed above, including data requesting, data updating, and data interoperating. In addition to these interfaces, the system also provides a user interface (UI) on the web for data display and system management.

4.2. Data collection

4.2.1. Data source

This research provides two case studies for demo display. First, we use measurement HD map data in San Francisco based on OpenDRIVE shared on the web (Aspin 2020) and reference data from OSM as the basic static map layer. The OpenDRIVE data have rich information about roads, lanes, junctions, and features (e.g. poles, manhole covers). We used an interoperating interface to merge the data in OpenDRIVE format with data in OSM format, which has rich information about roads and buildings, to OHDMSM. As shown in Figure 12 (a), we wrapped relevant functions into a model service following the OpenGMS standard that can be a plug-and-play component in an HD map data system. As shown in figure 12 (b), this model service can merge measurement data with OSM data to OHDMSM data. The HD map data system can invoke the corresponding model services for data processing or data interoperation. Due to the limitation in the extent of available static map data, the dynamic data and real-time data in the system are artificial and can be matched in the map display, such as restriction areas, weather information, and active walkers and vehicles.

Figure 12. OpenGMS model service for OpenDRIVE data and OSM data conversion to OHDMSM data.

In the second case study, we merged measurement data and OSM data from Hong Kong Science & Technology Parks. The measurement data are produced from point clouds, which are measured by LiDAR. The measurement data can provide information about roads, lanes, road signs, etc. The OMS data can provide information about buildings and roads. As shown in Figure 13 (a), the related functions are wrapped as an OpenGMS model service that can be a flexible module in an HD map system. As shown in figure 13 (b), this model service can merge processed point cloud data with OSM data to OHDMSM data.

Figure 13. OpenGMS model service for measurement data and OSM conversion to OHDMSM data.

4.2.2. Field dictionary building

To record and classify the data from OpenDRIVE, we initialize the field dictionaries in the system by popular fields or exited fields to be input. We review several object types for field buildings, including road type, lane type, and geometry type. As shown in Figure 14, we listed 22 field dictionaries for different object type descriptions in the three data layers.

Figure 14. Part of field dictionaries in the system.

With the help of field dictionary related pages, we reviewed different data sources to complete kinds of fields. As shown in Figure 15, we reviewed the field iB50000 Data Dictionary (Digital Topographic Map) in the Lands Department of Hong Kong SAR, Google Map, Open Street Map, and Department for Transport of U.K. for relevant field development (Department for Transport 2012; Lands Department 2022). Of course, the items in these dictionaries are not rigorous enough and require extensive review. The items in the field dictionaries shown in this research only meet the requirements for the data in this research.

Figure 15. Different road data types in field dictionary.

4.3. System demonstration

As shown in Figure 16, we developed the HD map data system following the data model and interface design above. We implemented the visualization of HD map data by Cesium.js, so the HD map data can be shown on the earth. In this system, we design several functions for data interaction and visualization, including data uploading, loading data for display in the static map layer, dynamic data layer, and real-time data layer.

Figure 16. System UI.

After data uploading, the system can load in different layers. We convert the HD map data at San Francisco in OpenDRIVE format and OSM format to the data in the OHDMSM static map layer. We display different kinds of data with different symbols. As shown in Figure 17, we use blue lines to express roads, green dotted lines for lane centerlines, and yellow lines for lane boundaries. In addition to the data in the static map layer, the data in other layers can be displayed on the map simultaneously. As shown in Figure 18, we marked part of Geary Street as a road work area that belongs to the restriction area in the dynamic data layer. After loading dynamic data by the interface, part of the street can be displayed in red. As shown in Figure 19, we put some active walkers as real-time data in the real-time data layer. After loading real-time data by the interface, the active ‘walker’ can be displayed on the map.

Figure 17. Load data in the static map layer.

Figure 18. Load data in the dynamic data layer.

Figure 19. Load data in the real-time data layer.

Besides the case study in San Francisco, we also provide a case study in Hong Kong Science & Technology Park. As shown in Figure 20, we collected point cloud data about roads, lanes, and related road surface signs. Then, we merged the processed point cloud data with OSM data in OHDMSM format.

Figure 20. The case study in Hong Kong Science & Technology Parks.

5. Discussion

There are still some key questions to discuss. First, accuracy among different data sources is a key issue that needs to be discussed. The data sources of OHDMSM may have different accuracies. For example, the data in the static map layer can achieve accuracy, but the information about temporal road work in the dynamic data layer, coming from volunteers, can only achieve 10 cm or meter accuracy. When fusing data in the OHDMSM, the different data accuracies may mislead terminal users, which may cause some accidents. However, autonomous driving has different accuracy requirements for different objects. For example, the accuracy of lane lines, stop lines and other restriction lines is high, reaching 1 cm. Compared with these lines, the accuracy of surrounding objects from OSM (such as buildings) only reaches 1 m∼3 m, but it does not affect driving directly. Therefore, the information in the HD map can also have two classes: one for autonomous driving and the other for reference. The information for autonomous driving requires high accuracy but reference information. In this system, we can also provide a plug-and-play module for data matching and calibration for reference data, and this can be our further research.

Then, there may be field ambiguity when fields are increasing in the field dictionaries. Different standards or regions have different semantics in the same words, or the same words have different corresponding meanings or objects. For example, the Guangdong-Hong Kong-Macao Greater Bay Area has two sets of traffic rules (rules from Hong Kong SAR and Chinese mainland). The expressways in the Hong Kong SAR can also be regarded as controlled-access highways in Chinese mainland. Meanwhile, field parsing also requires experts or volunteers to distinguish different fields in different standards or semantics. In addition, the fields to be appended in the dictionaries need to be checked by the managers. Relevant processes should be wrapped as common methods or components, which can be invoked by the system as interoperation components.

Finally, different standards have different geometry recording methods. In OpenDRIVE, the geometry data are always recorded by an inertial coordinate system and kinds of lines (e.g. reference line, lane width, and lane offset) by different methods (e.g. line, spiral, arc, and polynomial). In our case study, most of the geometry and location variables in OpenDRIVE data need to be calculated by the traveled distance and relevant polynomial. The OHDMSM records data by massive discrete points. Compared with the recording method in OpenDRIVE, the OHDMSM may be friendlier for data gathering and updating. Moreover, OpenDRIVE may have advantages in navigation or autonomous driving in tunnels without the signal of the GNSS because vehicles can calculate the traveled distance, and the autonomous driving system can calculate most parameters by the traveled distance by OpenDRIVE data.

6. Conclusion and future work

This research presented an HD map data model named OHDMSM for autonomous driving. The data model that contains three data layers and four kinds of interfaces has high flexibility and interoperability. This research also designed and developed an HD map data system as proof of the OHDMSM. The system can help terminal users request, update, and interoperate HD map data in the OHDMSM by designed corresponding interfaces to address various driving requirements. Related exploration of HD maps can contribute to developing autonomous driving, which is a key technology for intelligent transportation and Digital Earth.

However, there is still some work that needs to be done in OHDMSM. First, we need to complete the field dictionaries. Due to heterogeneous traffic rules around the world, there should be more fields to be clearly defined. Hence, in addition to being mentioned in this research, we need more standard and protocol reviewing work for related fields to be supplied in field dictionaries.

Then, in addition to the OpenDRIVE standard, we need more standard formatted data to interoperate with OHDMSM, such as the Open Lane Model and Lanelets. Therefore, we need more interoperation components that can reuse data from other standards and apply OHDMSM-based data to other standards, which requires much development work and can benefit data fusion and application.

Finally, we are planning to validate the practicality of our research by map autonomous driving cars. We are trying to contact several companies or research groups about mapping and intelligent driving to discuss how to apply the OHDMSM in HD map production and autonomous driving systems.

Software availability

Software name: HD map data system.

Developer: Fengyuan Zhang, Xintao Liu, Wenzhong Shi.

Year first official release: 2022.

Hardware requirements: PC.

System requirements: Windows, Linux, Mac.

Program language: Node.js.

Program size: 30 MB.

Availability: https://gitee.com/geomodeling/hdmapsystem.

License: MIT.

Documentation: https://gitee.com/geomodeling/hdmapsystem/blob/master/README.md.

Display address: http://8.130.35.228:8082/

Acknowledgement

The work described in this paper was supported by the National Key R&D Program of China (2021YFB2501101), the Smart Cities Research Institute (Q-CDA7) at the Hong Kong Polytechnic University, and Guangdong Science and Technology Strategic Innovation Fund (the Guangdong – Hong Kong-Macau Joint Laboratory Program) (2020B1212030009). The authors would like to thank the editor and anonymous reviewers for their comments and suggestions that significantly improved the manuscript.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Data availability statement

The data that support the findings of this study are openly available in Science Data Bank (ScienceDB) at http://do i.org/10.57760/sciencedb.03483, reference number 31253.11.sciencedb.03483.

Additional information

Funding

This work was supported by National Key Research and Development Program of China: [Grant Number 2021YFB2501101]; Smart Cities Research Institute (Q-CDA7) at the Hong Kong Polytechnic University: [Grant Number Q-CDA7]; Guangdong Science and Technology Strategic Innovation Fund (the Guangdong–Hong Kong-Macau Joint Laboratory Program): Guangdong Science and Technology Strategic Innovation Fund: [Grant Number 2020B12120300092020B1212030009].