Development of VISSIM Generator Based on Openstreetmap

Proceedings of 7th Transport Research Arena TRA 2018, April 16-19, 2018, Vienna, Austria Development of VISSIM generator based on OpenStreetMap

Dzenan Dzafic, M.Sc. a*, Leon Oss, B.Sc. a Christian Dernehl, M.Sc. a, Dipl.-Ing. Miriam Geulen b, Univ.-Prof. Dirk Vallée b, Univ.-Prof. Stefan Kowalewski a

a Embedded Software (Lehrstuhl für Informatik 11), RWTH Aachen University, Ahornstrasse 55, 52074 Aachen, Germany bInstitute of Urban and Transportation Planning, RWTH Aachen University, Mies-van-der-Rohe-Straße 1, 52074 Aachen, Germany

Abstract

VISSIM is a popular tool for traffic simulation. Before the simulation can be started, a model of the road network must be created which is a mostly manual and therefore tedious and time-consuming process. We present a VISSIM model generator which reduces the time spend for this task considerably. The generator creates a VISSIM model from an OpenStreetMap (OSM) file, which can be used by engineers as a skeletal structure. It creates all links, connectors, desired speed decisions, reduced speed areas and vehicle routes in a chosen area. Then the engineers can directly start with the parameterization.

The architecture of the generator is client server based. This means the user chooses in his browser an area on the OSM map. Then this information goes to the generator. Consecutively, the generator loads the map data from the OSM server and processes them to a VISSIM model, which the user can then download. To add more valuable information, the generator will be extended to include hold lines recognized on aerial images. The evaluation shows, that using the generator saves some hours to the users.

Keywords: VISSIM, Generator, Modell, OpenStreetMap, Automatization

1. Introduction

Microscopic traffic flow simulation is an established technique for mapping and simulating the traffic flow at junctions, on routes and in networks. The VISSIM program of PTV AG is a widely used tool for traffic flow simulation. Before starting a simulation study, the planning area in VISSIM must first be modelled. This requires information on the routes, the number of lanes, the traffic regulations and the position of stop lines and signal heads. The construction of the network in VISSIM and the adjustment to the real situation are time-consuming. The question therefore arises as to whether this time expenditure can be reduced by automatically generated VISSIM networks. In this paper the VISSIM network is generated using publicly accessible data. The open source project OpenStreetMap (OSM) provides with its information freely accessible map material and geodata.

The paper is organized as follows. First, two software products are presented, which can also be used to generate VISSIM networks. Chapter three describes the basics that are relevant to the development of the generator. Building on the foundations, the generator is presented with its architecture and its features (chapter 4) and then evaluated in chapter five. In the end, upcoming work steps will be presented and an outlook will be given (chapter 6).

2. Related Work

In this section, we discus two programs which can generate VISSIM models with OSM Data. The first one is VISUM, which is like VISSIM a product of PTV (2016). VISUM can import OSM Data to an own network, and export a network to VISSIM. Primarily it is for macroscopic transport modelling and not build to generate models in VISSIM. Macroscopic models do not need exact geometries in contrast to VISSIM models. This affects the quality of the approach to use VISUM for Microscopic simulation. Apparent in the fact that the generator VISUM only creates links and connectors. The links on a crossroad in the VISUM network all meet in one point. This makes it difficult to adjust it. The generator, described in this work, shortens the links at crossroads to avoid this. The generator and VISUM both add Desired Speed Decisions to the network. VISUM also adds conflict areas, which are used to model priority in the traffic. In VISSIM there is also a node object, which is different to the node object in OSM. This object is used to evaluate the traffic later. VISUM adds such nodes on each crossroad. The VISSIM-Generator does not do this, because the engineers wish to mark own nodes in the network.

The second software to generate a VISSIM model with OSM data is VS-SimGen by Verkehrs-Systeme AG (2017). VS-SimGen uses NAVTEQ data, which is more detailed than OSM. In contrast to VISUM, VS-SimGen is made to generate VISSIM models. The features of VS-SimGen are the following:

• Generation of links and connectors • Desired Speed Decisions • Conflict areas • Stop signs

In contrast to the VS-SimGen and other generators the proposed generator adds vehicle routes. They are used in almost every model and are therefore an important feature. The generator only creates the routes, without usage distribution, so the user must add them per hand.

3. Basic

This chapter introduce some basics to help with the understanding the content of this paper. It starts with the definition of the eXtensible Markup Language (XML), which is the language that describe OpenStreetMap (OSM) and the PTV VISSIM. Since VISSIM is the simulation software used for the work introduced in this paper, it will be the next topic to be introduced. It is also crucial to the comprehension to know that the OSM builds the map foundation.

3.1. eXtensible Markup Language (XML)

The W3C (World Wide Web Consortium) developed the XML Language with the goal to overcome some limitations in HTML. The name XML means eXtensible Markup Language and defines a package of rules to encode documents in a format that can be read from both humans and machines - Marchal (2002). XML works with the concept of key-value pairs. For example, in the OSM document (Fig. 1), one key is highway and one of the associated values is residential. An XML documents is composed out of elements. An element can have

Fig. 1 XML Code some attributes and some elements in a lower hierarchy (Fig. 1). The element within the lower hierarchy is called child. The higher element is called parent.

3.2. VISSIM

VISSIM is a program of PTV AG for microscopic traffic flow simulation. This tool is state-of-the-art and is, according to the company, “the leading microscopic simulation program for modeling multimodal transport operations” PTV (2016). VISSIM includes a traffic flow model and a signal control. The traffic flow model simulates the movement of different road users through a network. The model is based on a car following model and on a lane-changing model. VISSIM uses the psychophysical perception model developed by Wiedemann for modeling the car following.

The network consists of the following components:

A. links, number of lanes, connectors, public transport stops, stop line and positions from signal heads and detectors B. Vehicle inputs, routes, headway and time gaps from priority rules, information from public transport lines e.g. departure time.

The first ones describes static data, which does not change during the simulation. The second components are dynamic data, which can change. PTV (2016) A VISSIM file uses XML to save data. Every network has a root called network with children for every object in the model. Some of the children are in every VISSIM file. For example, desSpeedDistributions stores the standard speed distributions for VISSIM. Some of the children of network are not in every VISSIM file. An example for this is vehicleRoutingDecisionsStatic. This element is added, when the user saves vehicle routes. Later the generator uses this modular construction of a VISSIM file, to add features independently.

3.3. OpenStreetMap (OSM))

OSM is the best open source project found to use as map source for the proposed generator. According to Ramm F and Topf J (2010), no other open source project exists with a comparable world map data density and reliability like OSM. As mentioned above, the data format of OSM is XML. Additionally, other data input can be used by adding new tags to a model.

The main structure of OSM files consists of three components: node, way and relation. The node gives information about position (Latitude - Longitude), traffic signals, stop signals, etc. Secondly, ways connect some of the nodes and gives information about the following topics:

• highway – Provides information about the sort of roads • lines – Provides information about the number of roads tracks • maxspeed – Provides information about the maximal licensed speed • oneway – Provides information weather a street has an opposite lane • junction – Provides information weather we have roundabout traffic

Lastly, a relation connects the ways. The VISSIM Generator needs only the information of nodes and ways to build VISSIM files that are also based on XML. 4. Generator

4.1. Architecture

Fig. 2Architecture of VISSIM Generator

The architecture of VISSIM generator (Fig. 2) is based on client-server. This means that a user chooses one quadrant from the map on the desktop (clients). The coordinates of this quadrant will then be sent to the VISSIM generator server. Since the VISSIM generator has no data about the map, this server needs to send a request with the coordinates to a data source. In this case the data source is the OSM Server. After the VISSIM generator receives a XML file with all information about the map from the OSM server, the VISSIM generator begins to parse the road information from OSM to VISSIM. At first the generator matches the tags of the XML file from the OSM format to the VISSIM format. After this matching, the VISSIM generator starts converting the OSM information to the VISSIM format. Afterwards the generator generates further features for the VISSIM model. More information about the functionality of the parser can be found on the chapter 4.2 of this paper. Finally, the generator sends the VISSIM model to the client and the user can open it with the VISSIM software.

By using a client-server architecture is possible to outsource complex calculating. Simultaneously, it is not necessary to have all the data local. For instance, the generated file is only 50 Mb, but the generator uses data sources with an approximate value of several terabytes.

4.2. Features

This chapter explains the work process of the VISSIM Generator with all features. From the basic features such as links to the more complex features like vehicle routes. It also gives an overview on the dependencies found during generation. The VISSIM model is stored within a XML format. A VISSIM model has for every type of object a main element. There are 35 main elements. But relevant for this generator are: desSpeedDecisions, links, netPara, reducedSpeedAreas and vehicleRouteDecisionsStatic. First the generator creates the not relevant elements, which are the same in every VISSIM model. After this the generator creates the relevant elements which he should be added. With this method, the generator returns a file, which looks like a normal VISSIM file. In the development, it is also possible to add features independently.

Ref. Point

Links

Links in Opposite Direction

Connector

Desired Speed reduced speed Vehicles Route Decisions areas

Fig. 3 The work process of the VISSIM Generator

In the following is described, which features are generated and how they influence each other. Figure 3. shows all features and their dependencies. A VISSIM network needs a reference point. The objects of the network are relative to this point. The generator uses the coordinate of the first node in the OSM file as reference point. This reference point is important as orientation on the background maps in the VISSIM network i.e. bing. For the generation of consecutive features, this point will be used. Since OSM- and Vissim Coordinates differ, the generator transforms them from WGS 84 to a cartesian, metric Sphere Mercator system - Ramm F and Topf J (2010). Intern the generator still uses the WGS 84 coordinates to calculate the distances in meter from and to the reference point.

Now the basic feature is the computation of the links in VISSIM. As can be seen in Figure 3, all other object that are generated are based on links. The idea behind the generation of the links is, that it should be simple to modify them, so the generator will not only copy them from OSM, but it will modify them for this purpose. The Links are computed from the OSM ways element having the attribute highway. The tag highway in OSM contains information about the kind of road which is represented. Examples for highway tags are motorway or track. Since not every tag is relevant for the traffic simulations, the generator will not use every tag. OSM represents roadways in one single vector for both directions. VISSIM represents a roadway with one link for each direction. For this reason, the generator computes the opposite direction. It does not make a difference whether the lane has a width of 3.25 m or 3.5 m. Here the links are moved 3.5 m away from each other. 3.5 m is the standard width of a lane of a link in VISSIM – PTV (2016). The generator gives every lane this width, because in general the width is not important for the simulation. But there are exceptions, for example if someone with a car wants to pass a cyclist on shared lane. Main roads with double-sided advisory bike lanes have a recommended width of 7.5 m – FGSV (2006). After computing the links, they are shortened, if possible. Shortening in this context means that the generator cut of the last meters of a link. The reason for this shortening is, that this makes it easier for a user to change the model, after it is generated. Otherwise in a full generated model, it would be almost impossible, due to overlapping at the crossing point, to mark a single object on a complex crossroad.

After all links are generated, the connectors will be computed. For this the generator looks which nodes are situated on which highway in OSM. Then he computes all possible connectors at a crossroad, except U-turns. The reason for computing every possible connector is, that the user shall decide, which ways can be used and which don’t. U- turns are an exception for this, because according to the feedback of the engineers there are very rarely used, but would be added at many points in the network. In this step, it is clear which connectors shall be computed, and each one gets a unique number to identify them. This number will later be used for VISSIM, and it helps for future computations by the generator. The connectors will be generated with four points. Two for the start and the end of the link and two as supporting points. The start- and end point are given in the distance of the corresponding link. The coordinates of the supporting points are computed with splines of degree two. This puts the points on a curve between the two-connected links. With this technique, it is also possible to generate more points on the curve. The Generator does not compute more points, because in general OSM has no exact information about connectors and it is expected, that the user has to modify them - Ramm F and Topf J (2010).

After the connectors are calculated into the model, the other features are generated, based on the existing generated network. . In the following the computation of the vehicle routes is described. Vehicle routes are used in VISSIM to control the flow of the traffic. The generator computes vehicle routes as follows. For every crossroad, the generator decides whether there are more than two links on the crossroad. If not, no vehicle route is needed. Then for every incoming link it generates the start of the vehicle route. A vehicle route should start as early as possible, because a car on this route may need time to change its lane, but since a car cannot be on two vehicle routes simultaneously, the vehicle routes cannot overlap. For this reason, the vehicle route starts 5 m after the last crossroad. Then the ends of the vehicle routes will be set 4.5 m after every outgoing link on the crossroad. This assures, that two vehicle routes do not overlap. Two routes should not overlap because in the simulation a car always has the information on which route it is. This changes only if it leaves a route or drives over the start of a new route. When two routes overlap, the car will never know, that it is on the second route, which leads to unwanted behavior. The vehicles routes also store the information over which connector they reach the next link. The generator does not set a distribution for the vehicle routes. This should be done by the user.

The desired speed decisions are also based on the network with the connectors. In OSM not every street has its own speed limit. For this reason, the generator adds speed limits as follows. When a street in OSM has a speed limit, the street in VISSIM gets it. If the there is no speed limit, but a street with a known speed limit leads to the street, both streets get the same speed limit. This shall assure, that if a user sets a vehicle input at a point in a model, it is more likely to have a nearby speed limit. Connectors get their own speed limit, based on the speed limit of the corresponding link. The desired speed decisions get parsed on 0.5 meter after the start of each link.

Also, independent from the vehicle routes and the desired speed decisions are the reduced speed areas. They are, like the desired speed decisions, based on the links and connectors and their speed limit. But it is more complex to compute them, since a decision should be made, whether a reduced speed area is needed or not. Therefore, the generator looks at every angle between three points at a link, including the connectors, first. If an angle is too small, the generator adds a reduced speed area, which is 5 meters before the change of direction and has a length of 10 meter. With this technique, the generator produces more reduced speed areas, than an engineer would do. In future this shall be replaced by an exact model that is based on the relation between the angle and the speed.

4.3. Challenges with OSM Data

One challenge in the OSM Data is the stop line. Stop lines are important for the VISSIM model because they are sometimes far away from the traffic lights and it becomes a problem when OSM has no information about them. One solution for this challenge could be to take the position from the traffic lights and set a fixed distance from this point. But because they are different in most cases, we can’t use this solution. An alternative could be to use the satellite images and pattern matching to detect the stop lines. This pattern matching is not practicable since on the one hand, the image quality is not yet good enough and on the other hand, it is hard to find a reference point between OSM data and the images. If you use the OSM traffic lights as reference point for the matching of the images to coordinates, we have the problem that there is an offset between the real-world location of the traffic light and the location of the crossing node in OSM.

Figure 4 is one example that shows that the traffic light is in the middle of the cross-way and Figure 5 shows an example where it is exactly on the stop line. Most notable other obstacles for this method are that not all pedestrian crossings are determined (Fig. 4), not all the pedestrian lights are tagged (Fig. 5), the traffic lights are just in a complete wrong place. There is a solution for the most of those very specific cases but it requires to make separate generators for all these use cases. There are two reasons for this. The first reason is that the most crossroads are individually. The second reason is that the OSM restrictions are not strong enough. Restrictions of the OSM mapper are only recommendations. This is not relevant, as a generator is just significant if it can be used for more than one case.

Fig. 4 The traffic light is in the middle of the cross-way - JOSM

Another challenge is the generation of vehicle routes on complex crossroads. The algorithm works fine on simple crossroads, because then it makes a new vehicle route on every node and a start as early as possible. But sometimes a crossroad has a complex model in OSM. Two crossing streets can consist out of several highways in OSM and other streets can cross those streets. In this case, the algorithm of the generator cannot determine exactly one starting point of the vehicle route outside of the crossroad. This leads to the behavior, that the generator builds three vehicle routes at a crossroad, where a human would only build one.

A problem which is more comparable with the challenge with the stop lines is the number and position of lanes in OSM. The problem in this situation is, that the OSM data has no precise information about the lanes. In the development of the generator it was assumed, that a user should manually add some lanes. For this reason; the model of the generator is designed to be modified. The links at crossroads are shortened to make it easy for a user to add extra lanes on a link. Here complex crossroads also pose a problem, because then, there are many short links, which cannot be shortened. Some possible solutions for this problem are more detailed traffic data from other sources than OSM or pattern matching on satellite images as pointed out above. Fig. 5 The traffic light is exactly on the stop line- JOSM

5. Evaluation

To be able to evaluate the generator the crossroad had to be carefully selected. Afterwards, usersneeded to design a VISSIM model without the generator. After that, the same usersdesigned the same crossroad with the generator. The construction duration of the complete VISSIM model is compared between the manual construction method and the automated one. First tests show that thedevelopers needed 2 hours to model a single node with the generator in contrast to the 8 hours spend without it. That means that the generator achieves over 75% improvement. However, the knowledge of the engineers cannot be abdicated. Practical traffic engineers should also evaluate the generator, but this is very time-consuming.

Fig. 6 a) OSM View b) VISSIM View For the optimization of the model some steps should be done in almost every case. Since OSM has no detailed information about the turning lines, they should be checked manually. For this reason, sometimes a lane must be added. Then the vehicle routes need a distribution for the incoming traffic. Then the complete model should be checked again for completeness and correctness, since we cannot guarantee correct and complete OSM data. Lastly, missing objects like vehicle inputs should be added. (Fig. 6)

6. Future Work

To improve the functionality and quality of the generator, the next step of the project will be the extraction of information using aerial view image recognition. By using this method, the generator can detect the stop line of a street, a turn lane and the number of lanes. The turn lane information is important for the VISIM model to generate the turning instructions. The number of the lanes is already partially contained within OSM data, but they are sparse.

One other possible extension will be the integration of traffic counting data from the public authorities to model the traffic in a VISSIM model. The biggest challenge in this extension is to design an interface for all data types because the data types differ between every public authority.

Another extension could be the usage of machine learning to generate an optimal traffic network. For this extension it is very important to have many VISSIM models to train the computer.

7. Conclusion

This paper presents a generator that can help traffic engineers to build a VISSIM model. The generator uses the information of OSM Maps and converts them into a VISSIM model. This model cannot be completed without traffic engineers because OSM does not contain all information needed for the VISSIM model. The generator can model all links, connectors, desired speed decisions, reduced speed areas and vehicle routes. Features like the turning lane and the stop line cannot be modeled using OSM data. For these two challenges, the generator could be extended to use aerial view image recognition.

An evaluation showed that the generator reduces 75% of time needed to model a VISSIM model and therefore is already a great help to the engineers.

Acknowledgements

We gratefully acknowledge the contribution of the late Univ.-Prof. Dirk Vallée to the CiTi project and this paper. With his open, constructive nature and his professional knowledge, ideas and experiences, he has enriched our interdisciplinary discussion continuously.

8. References

Ramm F, Topf J 2010 OpenStreetMap –Die freie Weltkarte nutzen und mitgestalten. Berlin PTV AG (2016) PTV VISSIM 8 User Manual. Karlsruhe Verkehrs-Systeme AG, http://www.vs-plus.com/xml_1/internet/de/application/d2/d29/f366.cfm , 27.09.2017 Marchal B 2002 XML by Example 2nd Edition, Que Publishing, Indianapolis pp.6 Forschungsgesellschaft für Straßen- und Verkehrswesen 2006, Richtlinie für die Anlage von Stadtstraßen. FGSV Verlag. Köln, pp69