Modeling and simulating traffic of “ringweg Groningen”

A network approach for modeling traffic of “ringweg Groningen”

Authors:

Ömer Arslan S1810715

Hendrik Schokker S2076217

Date: 04-6-2013

Course: Modelling and Analysis of Complex Networks

Instructor: Ming Cao

Introduction

The German mathematician Dietrich Braess stated that adding extra capacity to a network

when the moving entities selfishly choose their route can in some cases reduce overall

performance. (Wikipedia, 2013)

The performance of a road network is of great importance in order to reduce traffic jams

and improve the capacity and throughput of the traffic network.

In this report the main roads of the city of Groningen will be modeled as a network and

weights can (optionally) be added to nodes by looking at the capacity, intensity or a

function of these two parameters. With this model it can become possible to see which

nodes (junctions) are important for the network and which nodes are less important. A

algorithm will be sought that shows how important the nodes and/or edges are for the

performance of the network.

After there is an idea of which nodes could be more or less important the roads can be

modeled in a more detailed way which will allow for simulations to be run. With these

simulations it can then be possible to check whether or not the expected importance of

the nodes according to the first model is correct.

Seeing as the behavior of entities are an important factor on the performance, it can be

interesting to see the effect of what will happen when users do not selfishly choose their

route but are “controlled” in choosing their route in a centralized way. This centralized

control could be executed for example by either electronic billboards next to the roads or

by a navigation hardware unit such as TomTom.

This report will try to give an introduction into the modeling of a road network in Gephi

by explaining the steps taken to model the road network of the city of Groningen.

Secondly, this report looks at important factors to the performance of the road network. A

model for simulating the traffic on a real road network is then introduced by use of

SUMO. Finally the report will give some ideas on how use the models in practice.

Contents Introduction ......................................................................................................................... 2

1. Modeling of main roads in Gephi ............................................................................... 5

2. Results of the Groningen model in Gephi................................................................... 7

3. Modeling of complete road network in SUMO .......................................................... 9

4. Results of simulations in SUMO .............................................................................. 16

5. Conclusion and suggestions for further research ...................................................... 20

Bibliography ..................................................................................................................... 21

1. Modeling of main roads in Gephi

“Figure 1 - Graphical representation of ring Groningen and the city roads” provides a

simplified network representation of the traffic roads in the city of Groningen. The roads

to the city center are simplified due to the many small roads and are only considering the

roads parallel to the canals. The ring is most important part of the network, because it

connects to the city with the outside world. Destinations outside of the city are modeled

as nodes. The south side of the ring is known for its high occupation. Edges have been

given weights, where the weights represent the Intensity-capacity ratio. Hence, weights

between 0-1 mean the capacity is sufficient to deal with the usage. Complementarily,

weights above 1 represent insufficient capacity to deal with the usage. These weights are

deduced from a rapport concerning the expansion of the south ring of Groningen.

(waterstaat, Groningen, Groningen, & Groningen-Assen, 2007)

Multiple algorithms are used to find different characteristics of the network. Notice that

the network is a constant, non-dynamical system that does not take the traffic flows into

account. The only thing we can show is the interconnections between the nodes and

edges.

Figure 1 - Graphical representation of ring Groningen and the city roads

The algorithms used are betweennes centrality, closeness centrality, eccentricity

distribution, weighted degree, and eigenvector centrality. The meaning of the algorithms

will be explained briefly.

Betweenness centrality Measures how often a node appears in the shortest paths

between nodes in the network

Closeness centrality The average distance between a certain starting node to all

other nodes

Eccentricity distribution The distance from a certain starting node to its farthest

node in the network

Weighted degree Takes the weight of the edges that connect the node to its

neighbors into account when the degree is calculated.

Eigenvector centrality A measure of node importance based on the node’s

connections.

In the next chapter a table will be provided with the outcome of the previously mentioned

algorithms calculated in Gephi. Important results will be discussed and then analyzed

with the help of simulations.

2. Results of the Groningen model in Gephi

Id Label Degree Eccentricity Closeness

Centrality

Betweenness

Centrality

Weighted Eig. vector

Centrality Degree

1 driebond 3 7 3.71 53.22 5.33 0.54

2 europaplein 5 6 3.21 108.22 6.66 1

3 westerbroek 2 7 4.06 20.63 2 0.36

4 hereweg 4 6 3.32 107.33 4.26 0.78

5 julianaplein 4 6 3.18 128 4.36 0.59

6 vrijheidsplein 3 7 3.76 79 4.43 0.3

7 assen 1 7 4.15 0 1 0.17

8 helpman 2 7 4.24 33 2 0.24

9 rijksweg 1 8 4.56 0 1 0.17

10 oosterhoogebrug 4 7 3.59 74.44 3.5 0.62

11 lewenborg 1 8 4.5 0 1 0.16

12 noorddijk 4 7 3.53 80.49 3.5 0.56

13 eemshaven 1 9 5.06 0 1 0.11

14 oranjewijk 1 8 4.47 0 1 0.18

15 zernike 1 8 4.47 0 1 0.18

16 friesestraatweg 3 8 4.03 42.12 3 0.37

17 plataanlaan 5 7 3.5 106.61 4.5 0.6

18 vinkhuizen 1 8 4.44 0 1 0.16

20 stationsweg 4 5 2.97 76.38 2 0.97

21 lopendediep 4 6 2.94 161.03 2 0.78

22 schuitendiep 4 6 3.09 86.51 2 0.94

23 turfsingel 4 6 3.03 122.64 2 0.79

24 westerhaven 4 5 2.82 151.01 2 0.8

25 hoendiep 1 8 4.91 0 1 0.09

26 noordzeehoogebrug 3 8 4.09 41.37 3 0.35

27 noordzeeweg 3 7 3.59 55.78 2.5 0.51

28 vinkhuizen/friesestraatweg 4 7 3.47 80.49 3.5 0.53

29 hoendiep/westring 3 7 3.94 48 3 0.27

30 drachten 1 9 5.65 0 1 0.04

31 friese/aweg 3 6 3.35 70.64 2.5 0.47

32 zuidhorn 1 9 5 0 1 0.12

33 hoogkerk 2 8 4.68 33 3 0.12

34 haren 1 8 5.21 0 1 0.07

35 europaweg/rijksweg-west 3 8 4.56 35.07 3 0.29

36 winschoten 1 9 5.53 0 1 0.09

Table 1- Gephi results on algorithms

Eigenvector centrality is a measure of the influence of a node in a network. It assigns

relative scores to all nodes in the network based on the concept that connections to high-

scoring nodes contribute more to the score of the node in question than equal connections

to low-scoring nodes. Google's PageRank is a variant of the Eigenvector centrality

measure. As can be obtained from “Table 1- Gephi results on algorithms”, Europaplein is

the most central node according to the eigenvector centrality algorithm. 108 Shortest

paths are going through Europaplein and its closeness is 3.21. As mentioned earlier, this

network is not a dynamical network which takes traffic flow into account. Hence the

nodes in the city centre have a better overall score. However, the eigenvector centrality

proofs the importance of Europaplein and hence this will be considered in the following

section with the simulation software SUMO.

3. Modeling of complete road network in SUMO

Doing representative simulations of a (complete) road network is quite complex and not

easy to realize in software such as Matlab.

There are a few software packages that allow for the modeling of a road network. Most of

these packages are not free to use and therefore out of the scope of this project.

SUMO is an open source, highly portable, microscopic and continuous road traffic

simulation package designed to handle large road networks. It is mainly developed by

employees of the Institute of Transportation Systems at the German Aerospace Center.

SUMO is open source, licensed under the GPL. (Center, 2013)

Roads are modeled as nodes and vertices. This creates a directed graph. An example of

this is shown in the figure below. (Papaleontiou, 2008)

Figure 2 - Network representation of roads

With SUMO there are different possibilities for importing a map. One of these

possibilities is importing an OSM file. An OSM file is an extract from the service

OpenSteetMap

By using the website of Openstreetmap (OpenStreetMap - de vrije wikiwereldkaart,

2013) it is possible to export a square area to an OSM file. It is only possible to export

very small areas. An alternative method is to make use of the overpass-api.

By going to the query form of the site overpass-api (Overpass API Query Form, 2013)

and using the query stated beneath the area id-code of the city Groningen can be

generated.

“

<query type="relation">

<has-kv k="boundary" v="administrative"/>

<has-kv k="name" v="Groningen"/>

</query>

<print mode="body"/>

“

The area id-code turned out to be “409862”

A new query can be made to download to OSM file which contains the geographical data

of the area.

“

<osm-script timeout="180" element-limit="20000000">

<union>

<area-query ref="3600409862"/>

<recurse type="node-relation" into="rels"/>

<recurse type="node-way"/>

<recurse type="way-relation"/>

</union>

<union>

<item/>

<recurse type="way-node"/>

</union>

<print mode="body"/>

</osm-script>

“

This generates an OSM file of around 40 mb that contains all the required data.

The file can’t directly be used in SUMO so it should first be converted to a “SUMO

network file”.

“A SUMO network file describes the traffic-related part of a map, the roads and

intersections the simulated vehicles run along or across. At a coarse scale, a SUMO

network is a directed graph. Nodes, usually named "junctions" in SUMO-context,

represent intersections, and "edges" roads or streets. Note that edges are unidirectional.”

There are different methods to convert the OSM file to a network file accepted by

SUMO. One of these methods is by the use of the software “eworld”. This software gave

some errors on converting. A method that did turn out to work was by the use of the

SUMO application “netconvert”. This first gave some errors due to version conflicts

between the OSM file and what netconvert expected. Apparently, with newer versions of

the OSM file it is required that every part of the code in the file is given a version

number. By changing the internal version number of the OSM file to an older version this

requirement was no longer necessary with importing.

After this a model of Groningen could be imported into SUMO. With this, a SUMO

network file has been generated.

Optionally, additional files such as the “typ” file can be used with netconvert to import

additional items such as local speed rules for different types of roads.

The physical model is shown in the next figure.

Figure 3 - SUMO network file of Groningen

There are a lot of options with using netconvert. In the above figure there are a lot of

abundant roads such as pedestrian and bicycle lanes. By adjusting these options a more

optimal model can be made. After a lot of tries the following netconvert options gave

satisfactory results:

netconvert --remove-edges.by-vclass hov,taxi,bus,delivery,transport,lightrail,cityrail,

rail_slow,rail_fast,motorcycle,bicycle,pedestrian --geometry.remove --remove-

edges.isolated --tls.guess --tls.join --tls.join-dist 50 --junctions.join --junctions.join-dist 8

--ramps.guess --no-turnarounds.tls --verbose --osm-files groningen.osm.xml --output-file

groningenv10.net.xml

The options used in this conversion will be discussed shortly.

Geometry remove will remove items that are still in the OSM file and not required for the

network file.

With remove-edges.isolated the edges that are not connected to the full graph will be

removed. This option will help to reduce the amount of trips for which no route can be

made.

With Tls.guess the netconvert process will try to guess where the streetlights are

supposed to be positioned. Ideally all of these positions are checked in the actual SUMO

network file after conversion.

From SUMO wiki:

Joining traffic lights

OSM does not have the possibility to assign several nodes to a single traffic light. This

means that near-by nodes, normally controlled by one traffic light system are controlled

by two after the network is imported. It is obvious that traffic collapses in such areas if

both traffic lights are not synchronized. Better representation of the reality can be

achieved by giving the option --try-join-tls to NETCONVERT. NETCONVERT then

assigns near-by nodes to the same traffic light.

This option is thus used for a new net representation of the osm file. It was depreciated

and replaced with “--tls.join”. The distance for this joining of streetlights is set at 50

meters. This seems like a high number but with the guessing of tls’s there will be

situations where there are a few streetlights in a row. Without the joining of tls’s for these

streetlights there will be large traffic jams.

Another aspect:

When loading networks with defined connections, the results of joining nodes may be

quite surprising. Please note the - quite pathologic - network on the left side and compare

it to the one on the right. You may note some big differences in lane-to-lane connections,

especially for the edge coming from the south.

Figure 4 - Effect of merging of junctions

The reason is that during joining, edges are subsequently merged, and the connections are

tried to be kept. In the case of the straight connection on the left lane of the road from

south, it is propagated along the intersection - along all four edges that are lying within

the intersection - yielding in a further right-turning connection. Note: If you use the option --junctions.join during OSM import, the connections are guessed based on the joined junctions and no pathologies should occur

Thus, junctions.join is used in the netconvert process. The distance for joining is set at 8

meters because else very large and unrealistic intersections will appear.

With ramps.guess the on- and off-ramps for the roads are guessed by netconvert.

Finally, with no-turnarounds it will not be possible for cars to make a u turn. With

efficient routing this will not be necessary for cars and in the city Groningen it is also

prohibited at many intersections.

With the netconversion for “groningenv10.net.xml” the following figure was generated.

Figure 5 - SUMO network file for "Groningenv10"

The model could be further improved with other applications suchs as netedit. In the

model of “Groningenv10” there are still some aspects that are different from reality and

will cause some traffic jams at certain intersections. Improving this model will require a

lot of time and is therefore out of the scope of this project.

With a correct physical model the next aspect is to include traffic and simulate the traffic.

To include the traffic there are different options. One could generate traffic based on

origin-destination tables that could be provided by the municipal of Groningen.

Another way is to randomly generate trips on the network and then convert these trips

into actual routes. This process of generating trips is done with the python script

randomtrips.py and these trips are then converted to routes with the program duarouter.

Both are supplied with the SUMO software package.

The script of randomtrips.py gave some errors when used in Windows (8). With Mac

OSX it was possible to use the script. Input of the script is the net file generated with

netconvert and output is the trips.xml file.

With the randomtrips script a Fringe factor is used to take into account more traffic from

outside towards inside of city. With a fringe factor of 10 it is 10 times more likely that a

car will enter the graph from an edge that is coming from outside.

A minimal distance of 100 meter between origin and destination is attained for the

generation of trips.

A trip (and therefore, a car) will be generated every 0.5 seconds and the trips will start at

time 0 and stop after 1 hour.

After the trips have been generated it is up to duarouter to convert these trips into routes.

Duarouter uses the shortest route by Dijkstra’s algorithm (Dijkstra, 1959) between the

origin and destination tables from the file generated by the randomtrips.py script. This

will not reproduce the Braess’s paradox effect and does not allow to simulate a

centralized control effect. This is a very basic way of routing cars and will cause some

undesired effects that will be explained in the results.

After all these steps we now have the following files:

Groningen.osm.xml The OpenStreetMap file

Groningenv10.net.xml The SUMO network file

Groningenv10.trips.xml The trips file

Groningenv10.ruo.xml The routing file

After this one more file is necessary to start the simulations in SUMO, this is the cfg.xml

file. This file contains the following content to direct to the required files and use the

necessary parameters to generate output data.

“

<?xml version="1.0" encoding="UTF-8"?>

<configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="http://sumo.sf.net/xsd/sumoConfiguration.xsd">

<input>

<net-file value="groningenv10.net.xml"/>

<route-files value="groningenv10.rou.xml"/>

</input>

<output>

<summary-output value="groningenv10.sum.xml"/>

</output>

<time>

<begin value="0"/>

<end value="4800"/>

</time>

<processing>

<time-to-teleport value="-1"/>

<lanechange.allow-swap value="true"/>

</processing>

</configuration>

“

The summary-output will give us data on mean waiting times for the traffic at all time

steps of 1 second.

In order to check the effect of removing a node/intersection the following steps could be

taken:

1. Generate Net file from OSM file

2. Copy the Net file and delete the intersection from this file

3. Generate trips for the degraded Net file

4. Use this trips file to generate routes for both the original as the degraded Net file

5. Run SUMO for the original Net file with routes file for the original Net file

6. Run SUMO for the degraded Net file with routes file for the degraded Net file

7. Compare results

Note that both routes files are based on the trips file for the degraded Net file.

This way it is possible to see what the effect is of removing a node/intersection from the

network.

Another way would be to use the trafficmodeler supplied with SUMO.

4. Results of simulations in SUMO

With earlier versions of the SUMO network file there were many problems with traffic

jams. One of these problems is captured and visible on youtube at:

http://www.youtube.com/watch?v=qewufs0Xsq0

Most of these problems were fixed by adjusting the options of the netconvert process.

After running the simulation with the final “groningenv10” model some problems

became clear with the simulation model.

A first problem is the lack of “green-waves”. This is very visible when the simulation is

run from the graphical user interface. Cars are queuing for a streetlight and then when it

finally becomes green all the cars will start waiting again for a next streetlight that is a

little further. Whether and how the green-wave can be implemented in the model is

unknown and thus material for further research.

The second problem is the algorithm used by the Duarouter program.

Duarouter uses the “Dijkstra” algorithm to decide on the shortest route for trips. This can

cause suboptimal use of the roads. A practical sample of this suboptimal use of roads is

shown in the figure below.

Figure 6 - Problems with "Dijkstra's" routing algorithm

The cars will choose a road that is shorter in distance but has a very weak capacity. This

is leading to a small traffic jam that is unlikely to appear in real life.

The effects of this routing problem can become quite serious as can be seen in the next

figure.

Figure 7 - Serious traffic jam

In the example above the allowed speed of the ramp is the same as that of the main road.

The Duarouter program might include the speed of the roads when calculating lane

weight and still cause this problem. A solution would be to either adjust duarouter to look

more carefully at lane capacity or to change the max speeds of the lanes.

Another problem is with remaining unrealistic intersections. There is one intersection in

the model that is still giving traffic jams due to its design. This is the intersection of the

“Bedumerweg” and the “Sumatralaan”.

The intersection and the representation in the model are displayed in the following figure.

Figure 8 - Problematic intersection Bedumerweg-Sumatralaan

Due to available time, the process of removing edges/intersections as described in

Chapter 3 “Modeling of complete road network in SUMO” could not be executed. The

program “Netedit” which could be used to accomplish this process is not directly

available and should be requested.

When using the option “Queue-output” with the SUMO process all the queuing times and

lengths for all the lanes are outputted to a file. This makes it possible to get hard data on

the bottlenecks of the network.

This queuing data can be used to compare different traffic situations.

With the following parameters in the SUMO simulation, it is possible to use active

rerouting for cars.

“

<processing>

<time-to-teleport value="-1"/>

<lanechange.allow-swap value="true"/>

<routing-algorithm value="astar"/>

</processing>

<routing>

<device.rerouting.probability value="1"/>

<device.rerouting.deterministic value="true"/>

</routing>

“

With routing-algorithm a rerouting algorithm can be set. With device-rerouting-

probability a probability can be set for the chance of each car to have a rerouting

capability (tomtom). Active information on the network is used for this rerouting.

With device.rerouting.deterministic it is possible to have the rerouting capability to look

ahead in the future estimation of the network status.

After implementing these parameters all the traffic jams disappeared from the simulation.

The maximum mean waiting time for the cars (percentage) went from 0.21 to 0.2 using

the Astar, or A*, (Efficient point-to-point shortest path algorithms, 2005) algorithm as a

rerouting device for all the cars. The average travel time went from 852 to 854 seconds.

After a run time of 4800 seconds, with no new cars entering the system since 3600

seconds, the cars left in the system went from 478 to 122 cars. This is a significant

improvement.

The astar algorithm doesn’t look at the whole graph but only looks at parts of the

complete graph to decide on a route. This is a faster way of determining the route and

will generate good results for graphs that are efficiently build. Most of the traffic

networks are not build efficiently. Because of this a route that seems long can actually be

the fastest.

Next, rerouting with the Dijkstra algorithm is used. The other parameters are the same as

with the Astar rerouting algorithm. With this algorithm the mean waiting time went down

to 0.18, the average travel time went down to 845 seconds but the cars still left in the

system were 189 cars.

Overall, both the Dijkstra as the Astar algorithm seems to generate very satisfactorily

results when used with rerouting.

When turning off the deterministic rerouting option the average travel time went up to

849 seconds, the mean waiting time remained at 0.18 and the amount of cars still left in

the system were 107 cars.

Note that these results are the results at the end of the simulation. The waiting time and

travel time is the largest at the end of the simulation but the cars still left in the system

varies and can of course only decrease after 3600 seconds. (no new cars entering the

system)

These measures are thus not the best for evaluating the performance of the traffic but do

give an overall idea. It is likely that the results for the mean waiting time and the average

travel time are based only on the cars that have left the system. Therefore, when there are

still many cars in the system the waiting times and travel times seem lower than they

really are. The simulation should be run for a length that will allow all cars to exit the

system.

At least some level of rerouting capability can be expected, even without devices to give

this information. This is due to persons operating the car that can see in front of them

what is happening, or hear this on their car radio or maybe even through some billboards

that are already providing this information. Therefore, in the next table, “Table 2 - Traffic

performance of network” the rerouting probability is set against the mean waiting time

and average travel time.

For this new data the simulation length is set at 9000 seconds, thus allowing all cars to

exit the system.

Traffic network performance based on rerouting algorithms and probabilities

Rerouting Astar Dijkstra

Probability Mean waiting time Average travel time Mean waiting time Average travel time

0 0.21 995 0.21 995

0.2 0.16 883 0.17 883

0.4 0.15 829 0.17 829

0.6 0.2 822 0.17 824

0.8 0.2 843 0.19 843

1 0.19 861 0.18 863 Table 2 - Traffic performance of network

5. Conclusion and suggestions for further research

In the available time it was not possible to investigate on the results from the model in

Gephi. It was possible however to simulate with SUMO the effect of rerouting capability

of the cars. This turned out to significantly improve the performance of the traffic

network.

It turned out that even a small probability for rerouting capability significantly improved

the performance of the network. When a larger amount of cars were given the ability to

reroute the performance degraded after a certain point. This effect showed the sensitivity

of the traffic network.

The Astar algorithm turned out to be more efficient (for certain rerouting probabilities)

than the Dijkstra algorithm. This might be because the Dijkstra algorithm could make

cars take a longer (but shorter) route more easily than the Astar algorithm. This would

optimize perhaps the performance of the individual car but could result in longer waiting

times for other cars and thus degrading the overall performance of the network.

Further research can be done to:

Improve the model (conversion)

Implement realistic trip model (from municipal)

Implement and evaluate more (re)routing algorithms

Find the effect of accidents or closing down of junctions

Test and evaluate possible improvements or alterations to the network

Find more efficient reroute algorithm / implementation (decentralized rerouting?)

Bibliography Efficient point-to-point shortest path algorithms. (2005). Retrieved 2013, from cs

princeton:

http://www.cs.princeton.edu/courses/archive/spr06/cos423/Handouts/EPP%20sho

rtest%20path%20algorithms.pdf

How to use sumo to generate trace file for ns2. (2010, August 10). Retrieved May 22,

2013, from Elephant chenchen:

http://elephantchenchen.blogspot.nl/2010/08/sumo.html

OpenStreetMap - de vrije wikiwereldkaart. (2013, May 20). Retrieved May 20, 2013,

from http://www.openstreetmap.org/

Overpass API Query Form. (2013). Retrieved May 22, 2013, from Overpass API:

http://www.overpass-api.de/query_form.html

Center, G. A. (2013, May 3). SUMO simulation of urban Mobility. Retrieved May 20,

2013, from http://sumo.sourceforge.net/

Dijkstra, E. W. (1959). A note on two problems in connexion with graphs. Numerische

Mathematik 1, 269-271.

Papaleontiou, L. G. (2008). High-Level Traffic Modelling and Generation. University of

Cyprus.

waterstaat, M. v., Groningen, G., Groningen, P., & Groningen-Assen, R. (2007,

November). Verkenning Zuidelijke Ringweg Groningen 2e Fase. Retrieved May

15, 2013, from www.aanpakringzuid.nl: www.aanpakringzuid.nl

Wikipedia. (2013, May 23). Braess's paradox. Retrieved May 28, 2013, from Wikipedia:

http://en.wikipedia.org/wiki/Braess's_paradox