Modelling Altitude Information in Two-Dimensional Traffic Networks for Electric Mobility Simulation

Elevation data is important for electric vehicle simulation. However, traffic simulators are often two-dimensional and do not offer the capability of modelling urban networks taking elevation into account. Specifically, SUMO Simulation of Urban Mobility, a popular microscopic traffic simulator, relies on networks previously modelled with elevation data as to provide this information during simulations. This work tackles the problem of adding elevation data to urban network models particularly for the case of the Porto urban network, in Portugal. With this goal in mind, a comparison between different altitude information retrieval approaches is made and a simple tool to annotate network models with altitude data is proposed. The work starts by describing the methodological approach followed during research and development, then describing and analysing its main findings. This description includes an in-depth explanation of the proposed tool. Lastly, this work reviews some related work to the subject.

Shuttle Radar Topography Mission (SRTM) (NASA Jet Propulsion Laboratory, 2015) data and retrieve precise altitude information for most regions of the world.The SRTM is a mission conducted since the year 2000 to obtain elevation data for most of the world with high precision and resolution and making it available to the general public.
Despite using OSM and the SRTM plugin and then directly importing the data to SUMO being simple to do and accurate regarding three-dimensional information, this approach does not allow adding the altitude value to pre-existent SUMO network files.Fully modelling an urban network to use in SUMO can be a time demanding task and disregarding old network files and starting anew in order to use an OSM file for altitude purposes may not be viable.Network files generated by OSM file conversion are often created with issues that require user maintenance to patch, such as inaccurate road representations, which translate into an added effort to use this method of network creation.As such, it is important to have an alternative to retroactively, and automatically, add the altitude information to previously existing and maintained network files.Google Maps Elevation API: The Google Maps Elevation API (Google, 2015) allows the retrieval of precise altitude information for any point of the world whose data Google possesses.The API receives (longitude, latitude) coordinates and retrieves the altitude for them.It allows querying for single points, multiple ones in bulk or along a path defined by a start and ending point.
Using this API has the advantage of directly accessing Google's data, which is known for its precision and availability all around the globe.Nonetheless, a disadvantage of the API is related to free access limits.Free access to the API is limited to 2500 requests per day, a maximum of 512 locations per request and a total of 10 requests per second, which may make the usage of tools resorting to this API not viable for certain situations.
Nonetheless, with the objective of pre-processing and annotating SUMO network files with altitude data before running the simulations, the API was chosen to be used for the purpose of this work.Network altitude model creation and integration of the model with SUMO Altitude data is combined with the original SUMO network file in order to create a new network file enhanced with three-dimensional information.These recreated files can be considered the altitude model for the urban networks, as the simulation can extract needed altitude information from it.Since SUMO simulations rely on the network files to function, that part of the integration is set by default.
However, the developed work takes into account the possibility of, in the future, interacting with SUMO externally.As such, single point lookup capabilities were implemented and questions addressing how to store data for future queries were thought about.Conclusions regarding future work related to this issue are described in section V.Although the possibilities mentioned in the future work are not yet implemented, the development was made with future extensibility in mind.

Urban network simulation
To allow for future testing and integration of the altitude data into more complex simulation systems, the simulation architecture proposed by Macedo et al. (Macedo et al., 2013b, 2013c) was installed and configured.This architecture comprises in the interconnection of the SUMO simulator with Simulink models, through a High Level Architecture (in the case of this work, Pitch pRTI (Pitch Technologies, 2015)).
The configured system seemed to run properly after setup.However, since the simulations did not implement usage of altitude information from SUMO yet, no testing of its performance was made.

General comparison between methods
Section II mentioned that several elevation data retrieval approaches were taken into account and analysed.Table 1 summarizes the main advantages and disadvantages for each of the methods, found during research.The elevation data retrieval tool The main practical output of this work was the development of a tool to automatically retrieve altitude data given coordinates in SUMO's projection space.Specifically, this tool is able to either read a previously created SUMO network file and create a new one, annotated with altitude data, or receive a single two-dimensional (x, y) coordinate and retrieve the corresponding elevation data.
The architecture of the tool is simple and modular.The parser / writer module parses the original SUMO network files in order to extract coordinate information and is responsible to recreate the file with altitude information.A geographic projection converter manages the conversion of coordinates in the network files to usable latitude and longitude projections.A basic http module queries the Google API for the needed altitude information.Lastly, our work interacts with SUMO's native NETCONVERT tool to merge the altitude data to the network file, in the correct format.

Manual GPS
+ Keep data for offline access; + Adapt to region of interest; + Possible path reconstruction.

OSM + SRTM
+ OSM is free, open content; + Highly detailed networks; + Can extract just a region of the world; + Fast processing for big networks.
-Cannot integrate directly with SUMO; -Cannot be used to extend old network files.

Google API
+ Accurate data; + Near-global availability; + Ease of use.
-Limited free access; -Slow for real time; -No offline access.
At the time of writing, the execution flow of the tool for network file handling, in general, is as follows, summarized in Fig. 1:

Summary of the tool's execution flow.
Parse the SUMO XML network file to extract the two-dimensional (x, y) coordinates of the relevant nodes, as well as information about the geometric projection used by SUMO (in particular, the "offsets" for the 'x' and 'y' coordinates (DLR -Institute of Transportation Systems, 2015c)); Convert each of the obtained coordinates to a latitude and longitude based projection.Currently, the tool supports converting from Universal Transverse Mercator (UTM) coordinates (MapTools, 2015), as it is the projection found in the network files used for testing during development.The Java library Proj4J (OSGeo Foundation, 2015) is used to implement the geographic projection conversions; Each one of the converted points is bundled into a single query to the Google Maps Elevation API, mentioned in section II-C.3, which retrieves the elevation data for every point.A single query is performed instead of a query per point, in order to save on the number of API calls executed for each converted file; A new, temporary, XML network file is created, with the same information as the original file, but with a 'z' dimension added to the previously two-dimensional nodes, containing the elevation data; Lastly, SUMO's NETCONVERT tool (DLR -Institute of Transportation Systems, 2015b) is used on the aforementioned temporary network file.NETCONVERT uses the three-dimensionally annotated node information to generate a new network file with all the expected elevation data.
Fig. 2 shows a comparison of the SUMO GUI without any kind of three-dimensional data and with provided elevation data, colouring the network edges relatively to their inclination ratio.
General comparison of elevation retrieval approaches.
It is also possible to use the tool to retrieve data for a single coordinate, without providing any SUMO network files.In this case, the user needs only provide a UMT coordinate and the corresponding "offsets" for the 'x' and 'y' coordinates.The execution flow is similar to the aforementioned one, but in this case only the coordinate conversion step is performed before querying the API with the single point.Then, the retrieved elevation data is displayed to the user in the system console.Such an approach can be useful to extend multi-paradigm, multiresolution, and multi-perspective simulation, integrating different models as proposed by other literature (Rossetti & Bampi, 1999;Rossetti et al., 2008;Timóteo et al., 2010;Pereira & Rossetti, 2012).

Google Maps Elevation API access times
In order to explore a possible real-time usage of the developed tool integrated with a SUMO simulation, the average API times, over 10 attempts, for different number of points were measured.Real-time usage could be interesting to explore in order to, instead of previously annotating the complete network file, query for the information as needed, during the simulation.The results are shown in Table II.It is possible to observe that the access times remain approximately constant regardless of the number of points sent in the query.However, these access times are close to 0.8 seconds, which can be considered slow.

Related Work
This section summarizes two of the main works this paper is based on.A HLA-based multi-resolution approach to simulating electric vehicles in simulink and SUMO This work defines a High Level Architecture (HLA) to interconnect different simulation systems (Macedo et al., 2013c).In specific, the HLA integrates a Matlab / Simulink (The MathWorks Inc., 2015) model of an electric bus subsystem with a microscopic traffic simulation using SUMO.
Using the referred system it is possible to make a real-time analysis of electric vehicle performance under dynamic conditions.The work was tested on a scenario based in the Porto Aliados bus network, in Portugal.This is the same urban network used for the experimentations on the present work.
Despite the importance of elevation data for precise electric vehicle simulation, it does not take into consideration this dimension.The search for a way to correct that shortcoming motivated this work.Besides using the same urban network for the simulations, the developments of this work were implemented with recourse to a similar system, in particular the Simulink + SUMO over HLA approach.This paper was found to be relevant to the present work due to the implemented HLA system.Currently, the developed tool mentioned in section III-B does not make use of the system's functionality as it interacts with SUMO on a network file preprocessing basis.However, future work contemplates the usage of the tool as a real-time standalone altitude retrieval, to communicate both with SUMO and Simulink to provide altitude information when needed (and not already available on the SUMO simulation).If successful, such an improvement could be considered an important complement to the work of Macedo et al. (Macedo et al., 2013c), providing a more robust electric vehicle simulation platform.
Electric vehicle simulator for energy consumption studies in electric mobility systems In this work (Maia et al., 2011), an electric vehicle model implemented directly in SUMO is suggested, as opposed to the Simulink model mentioned in the previously.At the time of writing of that paper, SUMO was lacking a direct way to integrate electric vehicles in its simulation capabilities.As such, the paper proposed an extension to the simulator's capabilities by adding electric vehicle models, validated with a series of tests.It is worth noting, though, that as of version 0.24, released in 2015, SUMO offers native electric vehicle simulation capabilities, along with electric charging stations data (DLR -Institute of Transportation Systems, 2015a).As of yet, advantages of using SUMO's native capabilities in place of the approach proposed by R. Maia et al. remain to be analysed by the authors.
Despite the aforementioned electric vehicle simulation capabilities in the current SUMO versions, the paper was still found to be relevant regarding the addition of elevation data in the simulations.In particular, it proposes the integration of an independent altitude information file with the SUMO network using SUMO's NETCONVERT tool, which was already mentioned in section III-B.The work showed that SUMO already provided some native capabilities to integrate elevation data and motivated the usage of SUMO's NETCONVERT for the tool mentioned in section III-B.It is worth mentioning, however, that this work did not specify how that altitude information was obtained, how the file was structured nor exactly what kind of integration NETCONVERT did with the file.In contrast to the work developed by R. Maia et al., the current work and the developed tool intended to offer a more extensive explanation of how elevation data is obtained and integrated into SUMO, as well as provide a way to retroactively extend SUMO network files with altitude data, without any pre-prepared altitude information files.

CONCLUSIONS
Relating to the compared elevation data retrieval approaches, it was possible to see that all three have their advantages and disadvantages.In particular, the Google Maps API can be considered fast to process large bulks of data, however no clear advantage in API call time is obtained by querying for a single point.Since the average call time reaches near 0.8 seconds, this approach may not be suitable for real-time usage.However, the data obtained using the API is the same used in Google Earth / Google Maps which, in general, means good quality data.In addition, the data availability is high, with most of the world being mapped and automatic data interpolation being made in cases of unavailable points.
Regarding the OpenStreetMap integrated with the Shuttle Radar Topography Mission, one can consider it to be a good option to retrieve altitude data, especially because the SRTM data is very accurate.However, in order to use this approach, it is necessary to start by extracting a mapped region from OpenStreetMap, retrieve the altitude data using SRTM and only then generate the SUMO network file.This means that this approach cannot annotate previously existing network files.Since these files can be time-consuming to create, disregarding previous work in order to start anew using OSM + SRTM may not be viable.In addition, real time usage is not directly possible.
Lastly, when considering manual GPS altitude data capturing, one must take into account that consumer-grade GPS devices are considered to be inaccurate when acquiring altitude information.In addition, to minimize the necessity of interpolating data, which leads to even further inaccuracy, it is necessary to capture a large number of points.Since this capture needs to be done in-site, it can be a very time-consuming task.Nonetheless, keeping a local database of GPS data minimizes the need for online tools, which reduces access times and reliability issues, in turn making it a great alternative for real-time usage.
Regarding the possibility of using a local geospatial database, some considerations have been made.It has been considered integrating one of these databases within the developed tool, in order to store captured GPS coordinates.Besides the previously mentioned offline access capability, it could be possible to reconstruct travelled tracks and integrate that functionality with SUMO networks.In addition, information from other altitude data retrieval approaches could be stored as well, meaning online API accesses would only need to be made once per point and possibly pre-loaded before SUMO simulations, to allow for real-time usage.
At the moment, an initial version of the proposed tool has been implemented, capable of annotating a SUMO network file with altitude information retrieved from the Google Maps Elevation API.The resulting file is directly usable in any future SUMO simulations.As it stands, it is also possible to use the tool to perform altitude queries for single points (as opposed to annotating an entire network file).The tool should be open-sourced and made publicly available soon, integrated in the MAS-Ter Lab specification (Rossetti et al., 2002(Rossetti et al., , 2005(Rossetti et al., , 2007)).As main contributions from the developed work, the general comparison between altitude information retrieval techniques and the developed tool can be considered.Hopefully, these can help improve the precision of urban network simulation, in particular for electric vehicle simulation cases.However, the tool has other usages in arguably different environments, such as those using serious games and gamification strategies as modelling support tools (Rossetti et al. 2013;Silva et al., 2013), as these can benefit from a more realistic representation of the network.
Regarding possible future work, the main priority would be implementing the local geospatial database, possibly using the PostGIS (PostGIS Project Steering Committee, 2015) technology.Using this database, the information retrieved from the Google Maps Elevation API could be stored for future offline usage and, additionally, implement some of the previously mentioned capabilities.In particular, PostGIS was considered for its data interpolation and track information storage capabilities "out of the box".
In addition, it would be important to try and implement a High Level Architecture Federate for the developed tool in order to allow real-time usage in conjunction with SUMO, Further experimentation would then be needed to attest the viability of this.Lastly, some direct improvements to the developed tool's code could be made.In particular, some of the geographic projection parameters are "hard-coded" when they could be extracted from the SUMO network file.