HUNGARIAN JOURNAL OF INDUSTRY AND CHEMISTRY Vol. 48(1) pp. 117–121 (2020) hjic.mk.uni-pannon.hu DOI: 10.33927/hjic-2020-17 GEOSPATIAL DATA MANIPULATION SUPPORTING THE IMPLEMENTA- TION OF DRIVING SIMULATION ENVIRONMENTS FERENC SPEISER∗1 , KRISZTIÁN ENISZ1 , AND DÉNES FODOR1 1Research Institute of Automotive Mechatronics and Automation, University of Pannonia, Egyetem u. 10, Veszprém, 8200, HUNGARY A lot of highly detailed geospatial information (obtained by mobile mapping and spatial data processing) is available that can be used to describe the exact road parameters for simulation and modeling. A gap between the freely available geospatial information and the descriptive standards of the road is present that is used in driving/traffic simulation as well as the systems of test vehicles. The toolset of GIS (Geographic Information Systems) provides wide-ranging functionality for spatial data processing, but is yet to offer support for standard formats of road description (OpenDRIVE data). This paper describes a method for gathering and converting road-network information from OpenStreetMap to OpenDRIVE data format. Using a similar conversion tool, the scenario generation and synthesis of realistic road networks for driving simulator applications can be more convenient and faster. Keywords: OpenDRIVE, OpenStreetMap, road-network conversion 1. Introduction Location information plays an important role in our ev- eryday lives. To go somewhere, e.g. shopping, our exact position and destination is required. This location infor- mation can be obtained by GPS or a cellular network even with a high degree of accuracy, depending on the applica- tion area. However, other data (map, road network, terrain model) may be required to reach the destination. Detailed route planning can be achieved by these collected data (spatial databases) and has a great degree of significance in driver assistance. The reliability of positioning and location awareness plays a crucial role in the field of autonomous vehicles and communication between them. It is important to val- idate the entire functionality of vehicles in all possible circumstances that could occur in real life during the de- velopment of all systems, subsystems and sensors of the Advanced Driver-Assistance Systems (ADAS) [1]. This kind of testing is expensive and requires a lot of resources to provide real-life conditions, e.g. the establisment of a proving ground like ZalaZone in Hungary. During the first development stages of a function, it is appropriate to test basic functionality in a simulation environment. This environment can simulate all the in- formation that is needed by the sensors of the control unit that runs the test build of the development. Of course, the more detailed the simulation environment, the more accurate the validated test result can be. This means that ∗Correspondence: kohlrusz.gabor@mk.uni-pannon.hu if a simulation environment were to be established, which can provide data in exactly the same mode as would occur in real life, the number of real-life tests necessary during the development of a functionality could decrease. There- fore, the rate of product development would accelerate and development costs decrease [2]. How can a simulation environment emulate real-life signals? Software-in-the-Loop (SIL), Hardware-in-the- Loop (HIL) and Model-in-the-Loop (MIL) solutions are able to emulate the signal level of real environments. All the necessary signals are obtained by the software, hard- ware or model components in the simulation as would be obtained in real life. The location information is a param- eter that can also be loaded for the software, hardware or model component that is being tested. What kind of location data can be used for testing, and how can the route, road as well as terrain on which the vehicle drives be described? A huge amount of lo- cation data is available, but the accuracy of data is the key question with regard to usability. Nowadays, many leading data-mapping and location-data service compa- nies have access to a huge amount of data and services in the traffic-navigation industry partnered with large au- tomotive manufacturers facilitating the development of ADAS, e.g. HERE HD Live Map [3]. The goal of these companies is to provide a high-quality, self-healing map that is a clear representation of the physical world for the navigation services. However, in terms of testing, not only navigation matters. It is important to have the tools necessary to create the data-mapping environment for the https://doi.org/10.33927/hjic-2020-17 mailto:kohlrusz.gabor@mk.uni-pannon.hu 118 SPEISER, ENISZ, AND FODOR simulations. This paper elaborates on the options avail- able to provide the proper format of location data for the TESIS DYNA4 HIL/SIL environment toolset of GIS (Ge- ographic Information System). An overview will be given of the available road data formats as well as the available crowdsourced OpenStreetMap data. A lot of highly de- tailed geospatial information (obtained from mobile map- ping and spatial data processing) is available that can be used to describe the exact road parameters for simulation and modeling. A gap exists between the freely available geospatial information and descriptive standards of roads that is used in driving/traffic simulation and systems of test vehicles. The goal is to provide an accessible, open- source and easy-to-use solution that is able to generate logical data concerning the description and visualization of roads for driving simulation environments based on available map data. 1.1 NDS Building Blocks The Navigation Data Standard (NDS) is a standard- ized format for automotive-grade navigation databases established by automotive Original Equipment Manu- facturers (OEMs), map-data providers and navigation- device/application providers. This is a standardized bi- nary database format that allows the exchange of naviga- tion data between different systems. The goal is to sepa- rate layers of data from the layers of software, mainly for navigation purposes. The following layers of data could be used from the NDS in a simulation environment: • Digital terrain model • Traffic information • Basic map display • Routing • Lane information 1.2 OpenDRIVE road format OpenDRIVE is an open format specification to describe the road networks developed by VIRES. It is a standard road description format that should help data exchange between different driving simulation environments. It has direct support without the necessity to convert into DYNA4, IPG’s CarMaker or CarSim formats. Open- DRIVE has special features like complex road networks with junctions, crossfall, superelevation, road markings and barriers, traffic signs and lights, gantries, as well as the ability to integrate high-resolution road surface pro- files in OpenCRG format [4]. The toolset of GIS (Ge- ographic Information System) provides a wide range of functions for spatial data processing, but is yet to offer support for the OpenDRIVE standard road-description format [5]. This paper describes a way of gathering and converting road network information from Open- StreetMap into OpenDRIVE format. Using a conversion tool like this, the generation and synthesis of a scenario with regard to real-life road networks for driving simula- tor applications can be more convenient and faster. Figure 1: The filtered OSM dataset of Veszprém 1.3 RoadXML Like OpenDRIVE, this is also an open file format for the logical description of road networks. The goal is to sim- plify the production of road databases as well as improve the consistency and ensure the interoperability of simu- lation models. This is an XML-based file format that can be easily edited to enhance road descriptions with cus- tom data using a simple text editor. RoadXML is used by many driving simulator software programs as an alterna- tive file format for describing road networks [3]. 1.4 Freely available map data Other commonly used formats for road networks, e.g. OpenStreetMap and LandXML, are available for geo- graphical needs, but are not suitable for ADAS simulation purposes, however, they can be used as an input source since these have worldwide coverage. OpenStreetMap is a free, editable map of the whole world that is being built, by and large, from scratch us- ing crowdsourcing methods and has been released un- der a Creative Commons Share-Alike license. The data records are mostly based on GPS navigation data that can be used to create configurations of road networks based on the line segments of the database [6]. Further descrip- tive data is necessary to fulfill the needs of simulation environments. A question that might be raised is whether and how vector data can be used in geographic informa- tion systems? Geofabrik is a free, community-maintained data ex- traction service from OpenStreetMap [7]. This can pro- vide the necessary road-segments data in addition to other information to describe the segments, e.g. the number of lanes, traffic signs, etc. (Fig. 1). Another option to obtain road-vector data is overpass- turbo.eu. Using this service, interesting map data can be Hungarian Journal of Industry and Chemistry GEOSPATIAL DATA MANIPULATION FOR DRIVING SIMULATION ENVIRONMENTS 119 Figure 2: Main components of the NI-based system selected by a special query language, downloaded, dis- played and used in GIS applications. Other data sources can be used to obtain other de- scriptive information. Information concerning elevation can be derived from the Digital Terrain Model produced with the aid of satellites (ESA’s Copernicus Sentinel-1 and Sentinel-2) and/or aerial images. 1.5 Open Source GIS software If the necessary map data is downloaded, a data man- agement and process system is needed to make further data preparations for this GIS software to be used. GIS software (Geographical Information System) is an appli- cation that enables geographical data to be managed on different platforms. Quantum GIS (QGIS) is one of the most popular open-source software solutions. QGIS is an official project of the Open Source Geospatial Foundation (OSGeo) that runs on all operating systems and supports numerous vectors, rasters and database formats as well as functionalities, moreover, allows conversion between different reference systems. This has been selected to im- plement the data management tasks on the downloaded road data. 1.6 Simulation software environment The road models are mainly necessary for testing and validating position estimation algorithms as well as ad- vanced driving support systems for autonomous vehicles. A hard real-time environment based on National In- struments devices has already been built for testing, and a soft real-time simulation system based on Vector’s VT System is currently under construction. NI’s LabVIEW as well as VeriStand are the base software programs, and MATLAB/Simulink-based TESIS DYNA4 software is used for automotive simulation purposes. VeriStand provides the connection between the mod- els and hardware components, while LabVIEW and DYNA4 provide opportunities to develop new models as well as other software components. In addition, NI’s Test- Stand can be used to create tests and automated test se- quences as needed (Fig. 2). TESIS DYNA4 is also the development environment for vehicle simulations in the Vector-based simulation en- vironment. Other software components and add-on mod- els can be developed primarily in Visual Studio and CA- Figure 3: Main components of the Vector-based system Noe in this environment, moreover, vTESTstudio pro- vides a framework for creating tests and test sequences (Fig. 3). TESIS DYNA4 serves as the vehicle simulation de- velopment environment in both cases, which is why the initial goal was to be able to use the data exported from the map databases in this environment. 2. Results and Analysis An important aspect of simulation tests is how to model the different sections of road. This location informa- tion can be obtained from real measurements or map databases. The selected sampling area is a short track in Veszprém. Using the service of geofabrik.de, it is pos- sible to download the latest dataset of the city from the OSM database (Fig. 4). This dataset provides the network level which consists of more data layers, roads and traffic signs, moreover, the buildings can probably be used as an information base for the description of roads. The nec- essary information was selected and processed by QGIS Desktop GIS software, moreover, the coordinate informa- tion of the points from the selected segment of road was exported in a suitable input format for data conversion. After the data collection task, the next step is to con- vert the data into the appropriate road-description format Figure 4: Selected track designated for testing in Veszprém (OSM) 48(1) pp. 117–121 (2020) 120 SPEISER, ENISZ, AND FODOR Figure 5: Transformation process that can be imported by the selected simulation environ- ment. DYNA4 has a conversion option that can create a track model in its own format from plain GPS coor- dinates, but has limitations. It does not allow the width of the road segments to be changed significantly, as well as data concerning the width of roads, number of lanes to specific coordinates or data concerning imported traf- fic signs and lights to be assigned, therefore, no de- scriptive information with regard to traffic levels can be found. Furthermore, the DYNA4-converted road descrip- tion cannot be exported into other formats of road data exchange, e.g. OpenDRIVE or RoadXML. 2.1 Data conversion To solve these problems, a self-developed conversion program was created that can create DYNA4-compliant path models from CSV and XLS file formats. The necessary conversion steps are the following: Import coordinates (OSM); convert input data and normalize (PROJ); define track segments and calculate; generate descriptive text; and define descriptive param- eters, e.g. width, length and number of lanes as well as heights (Fig. 5). The program reads the descriptive CSV/XLS file for- mats and then converts the coordinate data from the WGS84 geographic coordinate system to the Cartesian coordinate system to simplify the calculations. The HD- 72 – Hungarian National Datum (EPSG:23700 SRID) was selected, which is a meter-based coordinate sys- tem. A proper coordinate transformation is necessary for transformation between the two coordinate reference sys- tems that is provided by the PROJ library A special pro- jection string was applied during the transformation, so the standard transformation error remained below 1m. The program creates an approximate path according to the input points based on spatial geometry calculations Figure 6: Testing track in Veszprém compiled from lines, circles and splines corresponding to the DYNA4 format. Based on the path created in this way, DYNA4 files are created that can already be used directly in TESIS projects (Fig. 6). 3. Discussion Even though the conversion program worked properly, it has one disadvantage. The DYNA4 format does not sup- port the creation of complex intersections and multi-lane roads. Further development is needed to solve this problem. The conversion tool has to be able to save data in Open- DRIVE format so much more complex track models can be created as well as in other simulation software formats such as IPG’s CarMaker. The coordinate transformation also causes a bottle- neck because a meter-based coordinate system is needed for the geometric calculations. Not all projected and ge- ographic coordinate systems are appropriate for simple meter-based calculations. It is important to apply an ac- curate transformation method that places the coordinate points accurately. The projection string that was used is only suitable in Hungary. 4. Conclusion This paper introduced a map-tool that can be applied for the conversion of open-source map data to open road data formats. The converted road-description file can be used in different vehicle test systems as a basis for the func- tional testing of vehicle dynamics and driver assistance systems. The main advantage of the proposed framework is that if some kind of road network data is available from an area, it is possible to convert it into a road-description format. The created description file can be imported into most vehicle test systems. However, some limitations should be taken into consideration. Although a lot of road data can be found from open-source map databases, cur- rently not all of it is available, e.g. traffic signs and lights, and the quality of the data content needs to be enhanced. Our goal is to perform data collection tasks on the tracks that have been used in this case study. Hungarian Journal of Industry and Chemistry GEOSPATIAL DATA MANIPULATION FOR DRIVING SIMULATION ENVIRONMENTS 121 Acknowledgements The research was supported by EFOP-3.6.2-16-2017- 00002 “Research of Autonomous Vehicle Systems re- lated to ZalaZone autonome proving ground”. REFERENCES [1] Dupius, M.; Strobl, M.; Grezlikowski, H.: Open- DRIVE 2010 and beyond – status and future of the de facto standard for the description of road networks, Proceedings of the Driving Simulation Conference Europe 2010, 2010, pp. 231-242 ISBN: 978-2-85782-685- 9 [2] Richter, A.; Fischer, M.; Frankiewicz, T.; Schnieder, L.; Köster, F.: Reducing the gap between simu- lated and real life environments by introducing high- precision data, Driving Simulator Conference 2015 Europe, 16–18 Sep. 2015, Tübingen, Germany ISBN 978-3-9813099-3-5 [3] Chaplier, J.; Nguyen, T.; Hewatt, M.; Galee, G.: Toward a standard: RoadXML, the road network database format, Proceedings of the Driving Simu- lation Conference Europe 2010, 2010, pp. 211-221 ISBN: 978-2-85782-685-9 [4] Richter, A.; Scholz M.: Deploying guidelines and a simplified data model to provide real world geodata in driving simulators and driving automation, Transp. Res. Part F Traffic Psychol. Behav. 2019, 61, 305– 313 DOI: 10.1016/j.trf.2017.04.004 [5] Despine, G.; Baillard, C.: Realistic Road Modelling for Driving Simulators using GIS Data, Advances in Cartography and GIScience, 2011, 2, 431–448 DOI: 10.1007/978-3-642-19214-2_29 [6] Over, M.; Schilling, A.; Neubauer, S.; Zipf, A.: Generating web-based 3D City Models from Open- StreetMap: The current situation in Germany. Com- put. Environ. Urban Syst., 2010, 34(6), 496–507 DOI: 10.1016/j.compenvurbsys.2010.05.001 [7] Kulawiak, M.; Dawidowicz, A.; Pacholczyk, M. E.: Analysis of server-side and client-side Web- GIS data processing methods on the example of JTS and JSTS using open data from OSM and geoportal, Comput. Geosci., 2019, 129, 26–37 DOI: 10.1016/j.cageo.2019.04.011 48(1) pp. 117–121 (2020) https://doi.org/10.1016/j.trf.2017.04.004 https://doi.org/10.1007/978-3-642-19214-2_29 https://doi.org/10.1007/978-3-642-19214-2_29 https://doi.org/10.1016/j.compenvurbsys.2010.05.001 https://doi.org/10.1016/j.compenvurbsys.2010.05.001 https://doi.org/10.1016/j.cageo.2019.04.011 https://doi.org/10.1016/j.cageo.2019.04.011 Introduction NDS Building Blocks OpenDRIVE road format RoadXML Freely available map data Open Source GIS software Simulation software environment Results and Analysis Data conversion Discussion Conclusion