PRE2018 3 Group14

Group Members

Name	Study	Student ID
Joost de Boer	Software Science	1016745
Yanic Dobler	Software Science	1007100
Leon Kersten	Software Science	1006966
Pietro Maschera	Psychology and Technology	1220953
Koen Vlaswinkel	Software Science	1016271

Problem statement

Traffic management and prediction is a major concern and industry all over the world. City planers are always on the lookout for new methods, algorithms and procedures to guide the ever-growing car masses through the narrow streets of urban areas. These engineers focus mostly on developing means of controlling traffic light switching and while it is an important area to optimize, it has one looming downfall: It can only dictate the paste and rythm at which traffic flows through a specific intersection and not how traffic is split among possible intersections. Therefore to fully maximize the efficiency of the traffic network, an expert system which gives advice to city planners and administrators is needed. This software will find how the flow of the traffic can be optimized and it will give potential solutions as advice.

Objectives

• To evaluate the current state of the art on traffic advice.
• To evaluate the current state of the art of road pricing systems and implications.
• To interpret real-life traffic data provided in real time to feed the simulation (below).
• To develop an algorithm to solve the aforementioned problem.
• To develop a traffic simulation showing the effects with and without the provided soltuion on heavy traffic in urban areas.

Approach

Our approach will be based on mathematical and logical models with whom we aim to derive the best possible advice to improve road congestion. To do so we begin by understanding current models for traffic behavior and prediction. We then use this knowledge to formulate new models which fulfill our purpose. Using these models and real life traffic data a simulation is created, showing traffic with and without the created algorithm.

Planning

Who does what

The general planning per person:

• Koen: Data analysis and fixing
• Yanic: Software and distance based pricing
• Pietro: Research of the USE aspect, data matching and contacting municipalities
• Leon: Research of dynamic pricing and zone-based pricing
• Joost: Implementation of the advice and optimization

Weekly deliverables

In short, we want to do a research on the topic of flow control in traffic situations and improve the flow by analyzing data and creating a software model. The research will be detailed further on the wiki.

There are two things that keep occuring each week, one before each meeting, and one at the end of the week. What is done at the start of each meeting is discussing work done that has been divided last meeting. What is done at the end of the week is a short evaluation meeting with the tutor to compare progress and discuss issues that might have come up. This will start in week 2, as week 1 is the introductory week, with no assigned meeting.

• Week 1:
  • Brainstorm on the project idea and pick one idea.
  • Elaborate on it by finding sources(indiviually, at least 5 per person).
  • Divide the work for the first meeting and work on this individually. Make sure all of the points of the slides have been covered before the first meeting with the tutor.
• Week 2:
  • Start researching with the found papers, looking for how flow control works currently and finding ways to help improve it.
  • Look for databases of traffic data (in the Netherlands, or outside of it), which might be used in later research/in the software model.
  • Search for algorithms or discuss and make one on our own.
• Week 3:
  • Start work on a software model based on an algorithm found/created in week 2. Collectively implement a start for the algorithm using data.
  • Keep on researching for databases to use and finalize on a choice for database to use in the software model.
  • Write about the research that has been done in week 2.
• Week 4:
  • Implement details of the software model and fix possible bugs. Discuss ideas that might improve the model, and implement the data reading such that we can get results on our improvement.
  • Continue working on writing about the research done, and report on the software model on the wiki.
  • Research for new studies/algorithms should not be needed after this point, as the software should be largely done.
• Week 5:
  • Finalize the software model and process data from the database. If needed, fix bugs in the software model.
  • Compare the data from the results and think of conclusions linked to the outcomes.
  • Collectively look for reasons why the data behaves like how it is found.
  • If there is time for it, start working on the questionnaire for the USE aspect.
• Week 6:
  • Continue processing of the data and results of using the software model. The software model should be done at this point, because otherwise data will not be reliable for later.
  • Find interesting results, and compare them to real life data. Couple the found results to USE: is it helpful in improving daily life? Done in the form of a questionnaire perhaps.
  • Start with picking interesting topics to discuss about our results for the presentation in week 8.
• Week 7:
  • Finalize a presentation about the work that has been done on the project.
  • Finish conclusions on the results, and update the wiki accordingly. If it did not turn out to improve flow, explain why. Similarly, if it did improve flow, show how this was done.
• Week 8:
  • Give the presentation for the tutors.
  • Update the wiki with last information on the project.

Milestones

• Evaluation of both main topics completed
• Complete report on opportunities and threats of their co-operation.
• Interpret real life traffic data to feed the simulation
• Develop functioning algorithm for the problem.
• Having a simulation prototype making use of real life traffic data.
• Combining everything together to create a working simulation showing the positive effects of the algorithm on urban traffic.

Deliverables

• This wiki page on all our research and literature study as well as our findings and processes
• A flow control and pricing algorithm
• A model for simulating and testing our algorithm consisting of a functional simulation
• An analysis of the feasibility

SotA

Previous Groups

Subject and relevancy	Summary	Group
Vehicle intersection control This could be interesting to see what final algorithm they have introduced to solve the problem. They only work on autonomous cars, even if a part of the algorithm is dedicated to traffic lights in order to have the best solution in an environment of both normal and autonomous cars. Moreover their project was mainly for research sake - no actual simulation.	The idea is to design an algorithm that will use the benefits of autonomous cars on intersections with mixed traffic.	PRE2016 1 Groep2
Traffic light solution They have had kind of a similar idea to ours. They picked the ring of Eindhoven as a model and they used Netlogo as the software of simulation. They only focus on lights and green waves - no closing streets.	One of the methods to improve traffic flow is through the use of green waving. Here cars can continuously get a serie of green lights when they drive at an appropriate speed. For this project it was decided to try to implement green waving in a ring system. This was modelled through the use of the program Netlogo, where eventually a ring of twelve crossings was achieved.	PRE2016 3 Groep11
Pedestrian crossing This can be interesting for a research point of view and the method the used, even if it involves only autonomous cars and pedestrians. They conducted interviews, questionnaires and asked to specialists to gather information. They looked also at experiments made from the big companies (Tesla and Volvo).	The problems pedestrians face when crossing streets where autonomous vehicles drive and the other way around. Then we will look at numerous stakeholders and possible solutions. After that, questionnaires/interviews will be held with stakeholders to determine the needs of a system that offers a solution to the defined problem. After this, a design for our solution will be made and a prototype will show some of the working principles that need to be proven in order to give credibility to the final design.	PRE2017 3 Groep16
Self-learning navigation software This can be cool for the study of traffic jams that they made and the actual navigation system that could be something collateral to our project.	Every day in the Netherlands people commute to work with their cars, and every day the same thing happens, traffic jams causing a lot of pollution and waiting time. Most of the time people are traveling a lot longer than necessary to reach their goal. This gave us the idea to create a system that will reroute this traffic through secondary roads to minimize the overall waiting time or maybe even prevent traffic jams. By doing a lot of user research we hope to create a user friendly system that will help the user and society with this problem.	PRE2016 3 Groep13

Traffic light SotA evaluation

The current industry standard on traffic light control varies a lot within areas, cities and countries. Most use a fixed, cyclic schedule which was determined by some software or a human engineer. Other, more sophisticated crossroads might employ a dynamic system which uses factors such as day of time, holidays and other trends to control the traffic light, but in essence it is still a system that repeats, at least partly. Current SotA research develops into two major directions:

• The development of traffic light control systems using sensors to determine traffic load on the relevant lanes. Based on the actuator data, the system would leave open busy lanes for a longer time to increase traffic flow and reduce congestion.
• The development of prediction systems using big data and artificial intelligence which aim at predicting, with a high accuracy, the traffic behavior of the future. Using these predictions the traffic lights would then adjust its cycle to maximize traffic flow and reduce congestion.

The first direction runs into a widespread issue of robotics, any type of sensor is vulnerable to noise and can occasionally provide false information. Distorted information would lead these systems to break and/or misbehave. Consequences could be at worst fatal. The second direction is more predictable and less error prone, but it remains to be seen whether traffic can truly be predicted with a high enough accuracy for the process of developing such an AI to be worth the resource investment necessary. Also any unforeseen change in traffic due to outside circumstances will render the prediction model useless.

There is one more type of approach which was found to be very interesting and potentially a great co-system for what we are developing. The idea is that each car, given a starting point and a destination, receives a virtual "budged" to perform its journey. Traffic lights all have spots in their lanes which incoming cars can "purchase" using previously mentioned virtual budged. A car can only enter the lane of a traffic light if it has purchased a spot for itself. Upon passing the traffic light, the spot can be sold again by the traffic light to another vehicle. The vehicles on-board software would constantly engage with the environment (traffic lights, toll gates etc.) in a virtual market place, trying to find the cheapest spots which allow for the quickest route. This system in particular is only believed to be implementable if self driving cars make up the majority of traffic, however the idea of being able to assign numerical values to routes based on demand is a valuable corner stone for our own algorithm, as it provides another numerical fix point which is determined by the system of traffic vehicles and not on a potentially falsified.

State of the Art Traffic Congestion

Most researchers agree that the most effective way to fix congestion in cities is implementing tolled roads. These tolled roads should be priced based on marginal cost (including marginal social cost to account for externalities). Vehicles that carry high number of passengers such as buses should have a reduced price or be exempted from the charging system, as these vehicles should be encouraged. This is because, if more people use those type of vehicles, less vehicles overall are needed, and hence these vehicles help reducing congestion. An example of a country which already implements this system quite effectively is Singapore where automatic charging gates charge cars automatically the moment it drives onto a tolled road.

To fix traffic congestion however, good traffic congestion detection is needed. At the status quo this is done by tracking a set of cars (usually taxis) with GPS systems, and then checking the positions of those cars occasionally. Shared Nearest Neighbor Algorithm is often used to find congestion after those GPS systems are implemented. observation.

Other relevant State of the Art papers

Tettamanti et al. discuss a method of responding to real-time traffic using a signal split algorithm taking uncertainty into account. They try to minimize the queue length while doing so.

Ge et al. look at how a traffic jam stabilizes and does both an analytical and simulation study. They derive that a three-car lookahead is enough for cooperative driving.

Konishi et al. use a single-lane model and a lead car and following vehicles to observe traffic jam formation. When the speed of the lead car is varied, there are varying degrees of traffic jams. They derive a condition under which no traffic jam is formed.

Davis adds reaction time (delay) to an already existing model to observe how driver delay impact the flow of traffic. In his modified model, traffic jams are caused primarily by driver reaction time.

Koukoumidis et al. show how mobile phones can be used to reduce delays caused by traffic lights. Users receive the schedule of traffic lights ahead on their mobile phone and can adjust their speed so as to avoid coming to a complete halt. They evaluate SignalGuru, a service that collects and predicts the traffic signal schedule.

Mellodge et al. discusses the details of a path following lateral controller implemented on a prototype car by using a kinematic model for a wheeled robot. The complete architecture of this is discussed and how it has been simulated.

Ge proposes a new car-following model where the optimal speed is determined based on the velocity of the two cars in front of it. They also discuss the steady and error states and how they occur, including a state in which no traffic jam occurs. Moreover, a control scheme under which no traffic jam occurs is discussed.

SUMO is an open source traffic simulation package including supporting tools. Krajzewicz et al. discusses the current state of the package as well as its major application and future developments. The current version is available as well. [1] Traffic Control Test Bed is an open-source piece of software built on SUMO that allows traffic control systems to be evaluated and benchmarked against each other.

MITSIM is another piece of software that was developed for modeling traffic networks, just like SUMO. It includes advanced traffic control, route guidance and surveillance systems. It simulates invididual vehicle movements. The current version is available as well. [2]

Another open-source software developed for traffic networks is YatSim. This software focuses on testing consensus-based control strategies in urban road networks. By using a consensus-based control strategy, the traffic system requires agreement to guarantee several factors.

A test bed for multi-agent control systems is presented by Van Katwijk et al. The test bed was created to aid research and two examples are discussed.

Machine-to-machine communications can be used for road traffic management as well, as discussed by Foschini et al. Their design is built on top of existing production systems, unlike other proposals at the time. A year later, another paper on this was published by Fernandes et al. They discuss mitigations for communication delays inherently present and simulations of intraplatoon information management strategies. They find that the effects of communication delays may be cancelled out by better communication.

Van Arem et al. discuss the impact of cooperative adaptive cruise control on traffic flow. Cooperative adaptive cruise control is an extension of adaptive cruise control which also communicates with the predecessor by wireless communication. This allows a shorter following distance and a simulation executed by the authors show an improvement of the stability of the traffic flow and a slight increase in the traffic-flow efficiency.

Papageorgiou et al. show how a reduced throughput can be achieved and a number of countering methods. They discuss these methods in three context: urban road networks, freeway networks and route guidance.

USE Aspects

Target users

Our project aims to provide motorized traffic advice to whoever is in control of the road network, hence the direct target user will be the city administrators or government, depending on the governmental structure of the country.

Users

The direct users of this product would be the ones who control the road network (i.e municipality or government) because they are the only ones who interact with the product. This is because the municipalities and the government are the ones who have a choice to listen to the expert system or ignore the advice given. However, road users such as car drivers will be an indirect user of this product too as any choice implemented by the road network controllers will affect the ones who use the road.

Society

Society could benefit from any modifications that is implemented to the road network based on the advice given by the expert system. This is because any optimization in the road network for vehicles, leads to less congested roads and hence a lower amount of total travel time. Therefore, most individuals will have more time for other activities and also save money with gas. From a broader point of view, less total travel time also means that pollution from cars will be reduced, meaning less damage towards the environment which is a good social impact as a whole. However, road networks might become more car-centric as the expert system only tries to optimize the traffic for cars. This may lead to negative consequences for other road users such as bikers and pedestrians, which might have to deal with issues such as but not limited to: crossing broader intersections, waiting longer at traffic lights and cars going faster on roads.

Enterprise

Enterprises could be hired by governmental departments to control the road network, while the government still owns the roads itself. Then these companies would be the users of this expert system. Also in cases for smaller private road networks, this software could be used.

Trade-Offs

The expert system gives advice to the government purely to optimize the congestion of a road network. Naturally, following these advices blindly may result into negative consequence to other stakeholders. Firstly, reducing traffic light duration will be useful for cars who are able to accelerate quickly and thus leave an intersection before the light turns red again. However, for pedestrian roads running parallel to this road, the lights might turn from green to red faster than a person can cross the road. This is especially problematic for societal groups such as the elderly or physically disabled who are not able to move as fast as other pedestrians.

Another advice the expert system may give is to increase the speed limit for certain roads to reduce congestion. This is beneficial for car users as they can now quicker move from point a to b. However, following this advice blindly might have greater negative influences on people walking and living around those roads. Car with biker or car with pedestrian accidents are more likelier to be deadly as the car collides with a greater force. Furthermore, cars which move at a greater speed creates more noise. Therefore, the people living around the roads will have to suffer from greater noise pollution. This is especially problematic for people living in towns as in Netherlands, one of the potential reasons of people choosing to live in towns is because these people value rest and quietness more as opposed to people who live cities.

Finally, the expert system may advice to set a toll charge or increase toll charges to improve the congestion of that road. This measure is beneficial for ones who do not use cars as this measure contains the negative impacts only to those who are using the road directly. Furthermore, this measure will also be beneficial for vehicle users who value their time saved more than the toll charge payed, as now the driver will have to wait less in traffic. However, for vehicle users who value the amount of toll charge more than the time saved, this measure will not be appreciated.

Stakeholder research

Questions to town hall

Contacting municipalities

In order to enrich the value of the software, a research on the on the current methods of traffic management can be useful. For this reason we have sent the following email to the 50 biggest municipalities in the Netherlands. This email had as mere purpose the research of specialized people inside the relative town halls that could be able to answer questions about traffic handling and congestion.

"To whom it may concern,

We are a group of students involved in a project at TU/e. The project involves the analysis of traffic jams and flows. We would like to ask some questions about it to someone that is in charge of this field of operation. Would it be possible to have an email address or a phone number?

Thank you in advance, we hope to hear from you soon.

Kind regards".

Several municipalities have answered to this email with contacts of engineers and specialists of the subject. A second message containing a brief description of the project and the questions has been sent:

"Hello,

We are a group of 5 students at the Eindhoven University of Technology working on a robotic system for a project. Our goal is creating a software able to take traffic data from any given city as input, the output is the simulation of the optimized solution to manage traffic in the selected city. Along with the simulation, the program will also provide suggestions on how to handle the traffic in the different areas of the city (e.g. closing/opening lanes, lower/higher the speed limit, closing roads) without building nor changing the architecture of the roads. In order to arrive to such a program, we are asking the 50 biggest cities in the Netherlands how they handle their traffic and how they would react if our system would be implemented.

1. What is the current method used by the town hall to handle traffic congestion? Is there an adaptive system or is it rule-based?

2. Are you satisfied with the current management of traffic?

3. In case of an accident how do you deal with the traffic? How about road construction?

4. Do you apply any traffic limitation based on the level of pollution of an area?

5. Is there a dedicated team for the traffic control? How does it work?

6. Would you be open to use a computerized system to improve the traffic situation?

7. To what level would you apply the solutions provided by the software?

8. With the advancement of technology, cars and traffic are evolving. What kind of plans do you have for the future?

We hope to receive an answer from you as it would help our research a lot. If you have any doubts about our questions or software, do not hesitate to ask.

Best regards."

Report and discussion of answers

In order to better understand traffic management, and more precisely traffic management in the Netherlands, a questionnaire composed of 8 questions has been sent to the 50 biggest cities in the Netherlands. Out of these municipalities, only 6 took care in answering our questions. These cities are: Utrecht, Enschede, Zaanstad, ‘s-Hertogenbosch, Zoetermeer and Arnhem. Below a transcription of the answers to the questions, and the relative summary and conclusions can be found.

1. What is the current method used by the town hall to handle traffic congestion? Is there an adaptive system or is it rule-based?

All the town halls use adaptive systems for traffic lights control, especially in areas with a high flow of cars. For what matters smaller roads, it can be possible to find a rule based system. The handling of these traffic lights is managed in different ways, though. In ‘s-Hertogenbosch, for example, there is not a global network that controls everything, but avery traffic light works on its own. Unlike Zoetermeer and Arnhem which use the cloud to connect the traffic lights all together (VRI).

2. Are you satisfied with the current management of traffic?

Overall, every town halls is satisfied with their current traffic management systems, even though there is the common feeling that it could always be better. It can be noticed an advancement towards a more automatic and efficient system. For example the town hall of Enschede has the desire to have a better management of non-normal conditions (e.g. weather). The rest of the cities are just proceeding with a good pace towards an automatic and autonomous system.

3. In case of an accident how do you deal with the traffic? How about road construction?

In case of an accident all the municipalities leave the control to the police or the relative authorities to handle it. While in road construction situations, the traffic gets diverted in such a way that does not bother too much car divers.

4. Do you apply any traffic limitation based on the level of pollution of an area?

Only in Utrecht and ‘s-Hertogenbosch there are traffic limited areas with regard to pollution. In Zaanstad discussions are being made about this topic.

5. Is there a dedicated team for the traffic control? How does it work?

In every municipality there is at least one person dedicated to traffic control and the bigger the city is more people are dedicated to this job. In case of the municipality of Arnhem, this job is carried out from an external agency (i.e. RWS).

6. Would you be open to use a computerized system to improve the traffic situation?

All the cities are evolving towards a more and more computerized system, in order to have an efficient and autonomous service. Some already have an advanced system nowadays, others are working on it.

7. To what level would you apply the solutions provided by the software?

All the cities would be open to have external insights about the traffic congestion management in their areas, even though they would not apply the suggestions without having their own insights on the matter.

8. With the advancement of technology, cars and traffic are evolving. What kind of plans do you have for the future?

The municipalities are embracing different kind of projects and ideas for the future. For example Utrecht is dedicating its effort to include partially connected and cooperative systems, intelligent TLC’s, dedicated area network management. Enschede is investing in government programs and to include Doorstoming in their system. Other cities like ‘s-Hertogenbosch are investing on pilot programs.

Key insights on answers

The software, in order to be useful for society, needed some background research. The questionnaire sent to the 50 biggest cities in the Netherlands had a key role in the process of evolution of the software. Three are the main points in which the questions have brought insights in.

Firstly, there was the need to understand the current methodologies and strategies used by the different municipalities. What has been discovered is that everyone is putting an effort in having an automatic and adaptive system to follow in every moment and aspect traffic jams. The sample of cities that have answered to the questionnaire allows the research to take an interesting turn in the matter of needs that these cities require. Every city has a different way of supervising their traffic control, and it seems to be independent from how large a city is. Let’s now consider three of these cities and their position in the rank of biggest cities in the Netherlands: Enschede (11), 's-Hertogenbosch (17) and Zoetermeer (22). Enschede, the biggest amongst the three, has only one person monitoring the traffic situation, while 's-Hertogenbosch has five and Zoetermeer has three. As it it possible to notice there is not a very clear pattern. Moreover if Arnhem (13), with its handling of traffic executed from an external agency, gets thrown into the bunch, things get even more confusing. Further and deeper analyses should be conducted in order to obtain a scheme, but one lesson that can be extrapolated from this first analysis is that every city has its own parameters and priorities, and before inputting data of any city in the software, an evaluation of the city’s means and methodologies needs to be carried out in order to develop the best user-centred design possible for the simulation.

Secondly, the research was aiming at understanding if municipalities would be interested in using the software. All of the answers to these questions came back positive, meaning that from being a prototype the software could have a chance in succeeding in the real world, helping out municipalities. Confirmation to this hypothesis is provided also from another question that was placed in the questionnaire: “are you satisfied with the current management of traffic?”. This question has only collected positive answers and in most of them there was a “but”. Some cities would like more autonomy and others more efficiency, for these reasons all of the municipalities are in continuous evolvement. Providing the cities with the software could solve the problem of having a continuous evolution in the computerized system that they are using. The software has the need to provide the user with the best possible outcome and organization of the traffic handling in any situation, meaning that the software needs follow and fit any change that a city might carry out.

Thirdly, the research needed to assess to what extent the municipalities would apply the solutions provided by the software. Different kind of answers came back from this question, following the different kind of concerns that the engineers and the specialized people working in the traffic sector have. The kind of answers provided by the municipalities are mainly three. Cities like Utrecht and Enschede would trust the advice if the solutions provided are proved to guarantee the safety of traffic users, Zaanstad and Arnhem would be open to receive advice but they would need to have their own studies about the solutions and finally 's-Hertogenbosch prioritised the fact that the solutions provided need to be able to be overruled by hand if necessary. This suggests once again that we (as the developers and sellers of the software) and the software need to be flexible to the parameters and priorities that each city has, therefore having different kinds of solutions and attitude towards every different account. This means that there should be a stratified set of advices that we can provide to our clients. In order to understand this better see [paragraph about advices].

Thanks to the feedback received from the questions asked to the municipalities, it is possible to obtain what the users expect from the software and therefore advance towards the core of this USE project.

Raw data

1. What is the current method used by the town hall to handle traffic congestion? Is there an adaptive system or is it rule-based?

City	Answer
Utrecht	PJ: Adaptive Traffic lights connected to a traffic light centre and to a regional Network Management System. A Parking Route Information System for the commercial indoor Parking Garages
Enschede	There is an adaptive traffic light system on some corridors
Zaanstad	Control centre in north holland, and the overview the whole system. Adaptive system
's-Hertogenbosch	We have our traffic lights to control the traffic. These traffic lights are demand driven (adaptive). At this moment there is no global network management system that controls all the traffic lights. They function as single installations.
Zoetermeer	In Zoetermeer we offer both systems. The focus is on adaptive systems. The traffic regulation installation offers a free flow (groene golf) on main roads during peak hours. The aim of this free flow is to create an optimized situation to guide traffic from and to the highway (A12). The installations run independently most of the time, except for the free flow systems, those traffic lights are connected. Currently we are implementing iVRI to connect the installations to the cloud. Also we connected our traffic lights to central operations at Provincie Zuid-Holland. They can operate our traffic lights when there is an incident on the highway and after closing hours of town hall.
Arnhem	door middel van eigen waarneming en eventuele inzet van scenario's of wijzigen van VRI-programma's

2. Are you satisfied with the current management of traffic?

City	Answer
Utrecht	PJ: Yes, although we innovate constantly
Enschede	It should be more automatic adaptive to handle events, bad weather and other ‘non normal’ conditions.
Zaanstad	Satisfied with the current system, but it could be better. Constant innovations and keep evolving. Smart mobility: (Amsterdam, Amsterdam region, minister of infrastructure) with intelligent control system
's-Hertogenbosch	Yes, in the current situation the traffic in the city can be managed with our traffic light. When there are traffic congestions on the highways (A2 and A59) along ’s-Hertogenbosch, we see that reflected in the city.
Zoetermeer	We are satisfied with the current management of traffic. Our installations are up-to-date and are adaptable to new standard. We’re replacing 14 installations between 2019 and 2022. In time all installations will be replaced with iVRI’s which will make our traffic installations ready for automated driving and other technologies.
Arnhem	Ja

3. In case of an accident how do you deal with the traffic? How about road construction?

City	Answer
Utrecht	PJ: depends on the location of the accident/incident. In the city we work with the usual Police/Fire department/Ambulance drills. On the outer roads we work together with the regional and national authorities and several chosen tow companies. Road constructions and detours are painstakingly prepared to give as little disturbance as possible.
Enschede	Accidents are dealt with by the police, road constructions are planned and measures taken like detours
Zaanstad	Control system, police
's-Hertogenbosch	Traffic incidents are handled by the police and when necessary a towing company. The municipality of 's-Hertogenbosch has no task in the current situation. For planned road constructions we make traffic plans in advance to divert the traffic.
Zoetermeer	When necessary we can run a customized program. This use of this possibility depends on the predicted time of the accident and construction. If an accident influences a road from Rijkswaterstaat or Provincie Zuid-Holland we’ll contact them and set up plans together to keep traffic flowing.
Arnhem	eventuele inzet van scenario's of wijzigen van VRI-programma's

4. Do you apply any traffic limitation based on the level of pollution of an area?

City	Answer
Utrecht	PJ: Yes, we have so called Milieu Zones (= Environment Zones) where older diesel cars are prohibited
Enschede	No
Zaanstad	No, but they are talking about it
's-Hertogenbosch	Yes, environmental zones are established to exclude certain polluting traffic categories in parts of the city.
Zoetermeer	In the current situation we don’t have a traffic limitation based on the level of pollution.
Arnhem	Nee

5. Is there a dedicated team for the traffic control? How does it work?

City	Answer
Utrecht	PJ: Yes. They work very hard.
Enschede	No, just one person.
Zaanstad	Team of people working monitoring the traffic monitoring the area, with cameras and traffic lights
's-Hertogenbosch	There is one colleague dedicated for the correct functioning of the traffic light in the city. Furthermore, a traffic policy team (5 persons) has been appointed for the traffic policy of the entire city, of which traffic management is a part.
Zoetermeer	Technical traffic control is done by Martin Haaring. He is asset holder for all traffic regulation installations. To maintain the installations we have signed contracts with companies. The policy aspect of traffic regulation installations is shared between a couple of colleagues.
Arnhem	een externe partij voert dit uit samen met de verkeerscentrale van RWS

6. Would you be open to use a computerized system to improve the traffic situation?

City	Answer
Utrecht	PJ: as you can see in the answers above, we already do
Enschede	Yes, because of the fact that there is no 24/7 service for our traffic management we would like an automated system.
Zaanstad	Yes, they would be open to apply such solution
's-Hertogenbosch	We are currently working on a network-wide project to manage traffic in the city and nearby areas. So yes, we are allready doing it.
Zoetermeer	N.A.
Arnhem	verbeteringen zijn altijd welkom

7. To what level would you apply the solutions provided by the software?

City	Answer
Utrecht	PJ: to any level if they are 100% reliable and save and noticeably improve the situation according to our standards and policies
Enschede	As long as they are proven and do not cause safety issues
Zaanstad	They are open to external suggestions, but they would still have their own study about it
's-Hertogenbosch	It always must be able tob e overruled by manual operation.
Zoetermeer	N.A.
Arnhem	advies ontvangen

8. With the advancement of technology, cars and traffic are evolving. What kind of plans do you have for the future?

City	Answer
Utrecht	PJ: partially connected and cooperative systems, intelligent TLC’s, dedicated area network management, partially autonomous vehicles, etc.etc.
Enschede	We invest in programs like talking traffic and digital government. Also are looking in the possibility the get “Doorstoming” as a service.
Zaanstad	Following all the developments of the region, and participate when it is possible. The city is growing and therefore there is the need of new and complex solution.Intelligent traffic systems and making pilot projects.
's-Hertogenbosch	In the nearby future we are busy, among other things, providing the city with intelligent traffic lights, pilots for shared cars and MaaS (Mobility as a Service).
Zoetermeer	N.A.
Arnhem	Incar informatievoorziening, nemen zelf geen initiatieven

Driver Survey

In order to gain more insight to how the indirect users or the ones specifically affected by this software will feel and the magnitude that this software would affect them, a survey was created for road drivers. The survey consisted of a range of questions from their length of driving and the acceptance of road pricing. More specifically, the questions that formed the survey are as follows:

1. Do you drive a car regularly?

2. How many hours do you drive each week?

3. How many hours do you drive each week for what you consider “strictly necessary”?

4. How much would you drive if you have to pay a fee every time you drive on roads?

5. Where do you stand on a scale of 1-5 with “I only drive in my neighborhood” as 1 and “I drive across the country regularly” as 5?

6. From a scale of 1-5, how acceptable do you think the idea of road pricing (Dutch: Rekeningrijden) is? (where 1 is very unacceptable and 5 is very acceptable)

Result Analysis

In total, there are 13 responses, however only 12 have filled in every question, while one person has only filled in question 1. So the effective sample size is 12 people. From question 1, 61.5% from the responses have said that they believe that they themselves drive regularly, meaning that they feel they participate active enough in traffic that changed towards the road system whether through infrastructure or pricing does have a significant impact to them.

Questions 2 and 3 were used to determine the percentage of the times a driver drives when strictly necessary. To calculate this, the input from question 3 was divided by the input from question 2 and then multiplied by 100 to make it a percentage for each survey response. After sorting the data, it yields the following set of percentages: [0, 0, 0, 33, 50, 57, 67, 75, 90, 100, 100, 100].

From this data, it can be seen that around 25% of the drivers only drive when that person believes it is strictly necessary, and 25% of the drivers are “leisure drivers” who don’t drive for necessary matters. However, 58% of the people indicate that when they drive most of the times, it is strictly necessary (i.e strictly necessary driving rate higher than 50%). This might suggest that people might not drive that much less even if a price has to be paid to access some roads. This hypothesis is further strengthened in the results of questions 3 where 83.3% of the responses said that they would still drive as much.

Result of question 3

Regarding question 4, the results are as shown in the figure question 4.

Result of question 4

This suggests that most people drive throughout their city or region but that there is also a significant number of people who drive across the country. This indicates that in the future it is beneficial if this software is implemented throughout the national level to reduce traffic congestion on intercity routes. Finally regarding question 5, the results are as shown in the figure question 5.

Result of question 5

For this question, the answer is more varied, but there is a skew towards the side that road pricing is acceptable. In fact, 33% of the responses has said that road pricing is a very acceptable concept. This indicates that most people will not have a problem with road pricing.

Conclusion

In conclusion, this survey yielded interesting responses. The question 2, 3 and 4 from the survey has shown that most people drive when it is necessary and that most people will drive anyways even if road pricing is introduced. This means that road pricing may not have a very big impact on the reduction of total cars on the road in the Netherlands. However, this does not show that road pricing is ineffective for solving congestion as people still may drive as much but may take different routes. Furthermore, in question 4 it also shows that most people drive further than their own neighborhood or city. Therefore, to estimate the value of time of the average person driving a road, a city-wide or nation-wide income or GDP is more accurate. This is because the drivers of the road does not represent the people of that neighborhood, meaning it would be unfair to value of time higher in rich neighborhoods to calculate the road price as many who use that road might not be rich anyways. Finally and most importantly, question 5 shows that most people are not unaccepting of road pricing and therefore, that sufficient public support is able to be gained on road pricing. This is important as then municipalities will be more likely to be willing to use this software. Furthermore, it illustrates a point that even if positive feedback system would be realistically implementable, it would still not be needed as enough support for a negative feedback system already exists anyways.

Solution Research and USE Aspect Analysis

Altering the speed limit

There are many ways to reduce the traffic in a certain road network. One of these is to increase or decrease the maximum speed on a road in that network. The reason we did not choose to elaborate on this, is because it will cause some problems with the surroundings. If you increase the speed too much, the people in that area that are not using cars, will be less likely to get on the road. Increasing the speed from 50 to for instance 80 km/h will create more problems as well, as people get more prone to accidents happening. The area is also not currently suited to handle an increase in speed. Some roads are well maintained, and can thus handle higher speeds, but urban roads often do not support this. It would simply be too dangerous to go at high speeds over these roads. Renovating the roads would cost too much money, so in order to allow higher speeds for better traffic control, a lot of money needs to be put in. This is not feasible, and thus would not be a good recommendation in our opinion.

Similarly, reducing the speed will cause problems too, simply because people will get to their destinations slower. Yes, you can reduce the amount of traffic incidents happening this way, but it will be doubtful if it helps with increasing the flow.

Road Pricing with positive rewards

We focus on the aspect of road pricing to force people to take alternative roads. This can be using positive or negative feedback. Positive feedback would be paying a user to use a certain road, while negative feedback means that a user needs to pay to make use of a road(think of paying toll at toll gates).

Positive feedback is an interesting aspect to make people choose to use a certain road over another. This can apply to cars or cyclists. From an experiment using an App, if people took a bike instead of a car, they would get paid for doing so. This is a nice concept that could also be applied to a car-only network. But would it work if the government did it, is the price worthy for the government to spend, or will it cost too much?

First of, would it work if the government did it. To answer this, we need to know if people are willing to take different roads. This can only be done by going around asking questions to drivers, as there is no data available online that shows what we need. Then secondly, is the price worth it or does it cost too much? If the government wants to pay people to take certain roads, they have to take into account some of the costs. For instance, some roads will need more or less maintenance, because they will be driven over in different amounts. In the Netherlands, road maintenance differs per province, with North Brabant and South Holland having the most cost for maintenance per kilometer. Considering provinces, there is about 7900 km of roads to maintain.[3] This makes the cost of for instance South Holland, which is approximately € 277.000,- be about € 35,- per kilometer. This is very important to take into account when redirecting people over side roads, as this cost can be increased if you push people to utilize previously lesser used roads. This will only add up to the amount of kilometers of roads needed to be added to maintenance, which means more money needs to be spent.

Giving people money to take certain lesser used roads would then shift the balance around. You needed more maintenance on road A before, and little for road B, but now road A needs less maintenance, as it has fewer cars driving on it, while road B needs more maintenance because it has more cars on it. The amount of money given by the government would need to cover costs in such a way that they do not spend even more money per year. Giving money to drive different roads sounds like a way to get people to choose a different road, but is not feasible in terms of costs, as shown above.

Another downside of using positive feedback to try to make people use a different road, is that it can turn out opposite to what you want. If you give people money to take a sideroad, a lot of people would just take that sideroad over the mainroad. Getting paid for doing a slight detour is worth it compared to not getting money for it, making the mainroad not used anymore, causing congestion in this side road. This could also mean that people would just continuously drive circles to get onto the side road that gives money, to earn some quick money. That can be countered by putting it on a timer, but that could also be abused by people just driving larger circles over other roads. This is a relevant problem that is difficult to avoid when giving monetary rewards.

A different way to give a reward could be to instead reduce the taxes or other kinds of costs that are essential to driving on the road. However, this has the same problem. People could abuse this reward to have to pay no taxes, or get until the max reduction every time, and then just not use the reward roads at all, because it does not provide any benefit. At that point, people will not follow the guidelines that we want to enforce, of taking a different road.

Combining these points, we can see that, although positive rewards sound attractive, and might work until a certain extent, their drawbacks are more prevalent, and are difficult to work around. Therefore, using positive feedback is not a good choice to implement to enforce people to use the flow network that is given by the algorithm we designed.

Direct Effects of Road Pricing

The effects of charging cars to use certain parts of the road network, depends on the methodology of road pricing used, where the pricing is applied to, the importance of the reason why the drivers are driving and on how much value the drivers give to their time. In general however, if a specific area or road is priced, there will be a decrease of overall drivers in the road network and increase of traffic in alternate routes the driver could take. The decrease of overall drivers is due to the fact that some people do not want to pay more to use a road but also do not want to use their time to re-route, and thus will abandon traveling to their destination or use another means of transportation. For example, an individual who has to travel to the cinema might abandon this and watch a movie at home to avoid the hassle of driving longer or paying a fee. This total reduction of the number of cars in the road network are difficult to predict, as it also depends on availability of alternative forms of transportation and also on the price charged. However, to give an estimate Stockholm would reduce traffic by around 3% throughout the entire city and 19% in the inner city where traffic problems are the most rampant. . Furthermore, during daytime hours in weekdays, the traffic of the inner city will be reduced by 30%, which is a significant amount. . This reduction is predicted to be able to be achieved with a fee of around 3 euro when entering the inner city zone.

The increase of traffic in alternate routes happen because some people do not want or cannot abandon travelling to the destination and do not want or cannot use public transport. Furthermore, these people value the money which could be lost driving the road in question over the time lost taking the alternative route plus any toll charges the alternate route it has. For example, an individual who is poor but has to drive to work might wake up earlier and use more of his time to travel with the alternative route to avoid paying a larger fee. This effect is again difficult to predict as it heavily depends on the type of road pricing used. For example, if zone-based road pricing system is used, drivers will more likely travel around the zone to avoid costs and hence increase traffic in alternate routes. However with a distance based pricing system, the drivers will not want to drive around the charged road, as then the drivers will drive more and hence most likely have an increased cost. Furthermore, it heavily depends on how much the people value their time compared to the cost of the toll gate. This value of time heavily depends on how much the person makes per hour but also on factors such as but not limited to: personality or urgency of the current state. Since the value of time is too varied between every individual and also within the same individual during different times, it is better to estimate the value of time with the average wage per hour of the city. To estimate the percentage of people who will re-route, it is believed that for Stockholm, the alternate routes will have an increase of about 10% .

Figure 1: Formula to determine what the price of entering a road or road system should be

Social Costs of Zone Based Road Pricing

Although zone based road pricing is beneficial in reducing traffic congestion, the implementation of this policy has some social costs. Firstly, businesses and firms located on central locations of cities will decline as less people will go to city centers as central locations of cities are usually higher priced. Therefore, people will spread more and go to shops in outside locations. This is problematic as city centers are usually not just centers of cities but community spaces where citizens interact with each other and come together. As people go less to city centers, those centers might become less important and hence the city might lose a local hub where people can interact. This can lead to stronger segregation between different neighborhoods with each their strong identity rather than a city wide identity.

Secondly, people will also go out of their zone in general less often, as cars are charged per crossing a boundary of a zone. This again leads to neighborhoods becoming more isolated, and the notion of a city culture, if it existed at all, is likely to decline. Furthermore, this is a problem as neighborhoods are often naturally segregated by socio-economic classes. For example, rich neighborhoods do not have a ghetto inside them. This means that as less people move across neighborhoods, interaction between this socio-economic classes decreases. This can have a negative effect as more people will be in their own bubble, unaware of other parts of the society that he/she participates in.

Finally, this policy disproportionally affects the lower class. Even when people avoid road pricing, sometimes it is necessary for people to go to a certain zone. For example, many governmental or city infrastructures such as town halls are only located in one specific zone of the city. In this case, the zone based pricing will force people to either pay for their zone-fees or to take public transport. This is not a big issue if public transport is very affordable, however in this case with Rotterdam and in Netherlands in general it is not very affordable without discounts. This results in the lower class having to use higher portions of their income on these “forced fees” compared to the middle and higher classes resulting in less of their income being spend on goods and services which enable them to survive or move up their socioeconomic status.

Dynamic Pricing

Dynamic pricing is a type of road pricing which dynamically changes the price depending on how much extra cost it adds to other cars on the road if another car is added to that road. The function that determines the price to access the road is shown in figure x. τ represents the value of time for each individual. To see how this is estimated see section y. f represents the current flow of the road network, this is the variable that ultimately determines the price. t(f) is a function which determines the travel time of a car on that certain road for a given f. This function is an increasing function, as less cars means that cars can move quicker on roads and vice versa. dt(f)/df is thus the extra time it will take to traverse the road if the flow is increased by one, meaning that one more car travels per time unit. Using the dynamic pricing system, the price of the roads will constantly change according to the charge function meaning that when a road is more congested, it will be more expensive for a car to enter that road and when a road is empty, it will be cheaper for the car to enter this road.

Estimating the value of time

Estimating the value of time is an essential aspect in designing new transport systems or determine the price of charging roads systems. The research article written by Lasmini Ambarwati mentions two possible methods of estimating the value of time. These methods are the mode choice approach and the income approach. The mode choice approach estimates the value of time using user surveys, where each survey asks about the preferred mode of transport. This data is collected in as many different neighborhoods of the city as possible. This data is then quantified, and a formula is used which takes the monetary cost of a transportation and a willingness of a person to use a certain mode of transport to determine the value of time for someone who uses a certain type of vehicle. For example, in a city where only motorcycles and cars are considered, a value of time for motorcyclists and a value of time for car drivers will be estimated. Unfortunately, this method requires for a very large amount of data to be collected and to for the data to be from a diverse sample size for the estimation to be realistic, it was chosen to not use this method due to time constraint and lack of manpower. Furthermore, since this project is mainly focused on making an expert system which advises how to improve traffic for cars, the advantage of this method which differentiates the value of time between people who take different mode of transportation, is diminished.

The second approach to estimate the value of time is the income based approach. The income based approach uses a formula based on how much people work and how much people earn in a certain region. Specifically, the formula shown in figure 2. Here, λ represents the value of time per person per time unit. This time unit depends on what time unit is used for the working hours, but in this project a time unit, hour is used. Furthermore, the working hours represents the total working hours of the entire population per annum. The GDP represents the gross domestic product of the population. The problem with this method is that the more one attempts to estimate the value of time in a smaller area, the estimation becomes harder, as data such as GDP is not collected for very small areas like neighborhoods. Furthermore, the value of working hours may not be representative for all seasons as many work is seasonal, meaning that in reality the valuation of time might be higher in seasons where much more work exists than seasons where less people work. Nevertheless, this system is still the best estimation for this project due to its simplicity and usage of data that has already been collected by national institutions such as population size and GDP.

Calculation

To calculate the time value of the average person who uses the Rotterdam network, the GDP per capita (GDP/Person) of South Holland is used. This is because the road network for Rotterdam is not only used by people who live in the municipality of Rotterdam, but also many of the municipality around it as many people from those cities commute to Rotterdam for work. Unfortunately, the GDP of the exact area of Rotterdam and its commuter towns were not recorded, so the GDP per capita of South Holland is used. This value is 42956 euros(2017) which is very close to the GDP per capita of entire Netherlands which is 43020 euros Unfortunately, the amount of work a person does of South Holland was not found, so to estimate the mean work time (Work/Person), the national mean work time was used. This value is 29 hours per week. As GDP is a measurement of an entire year, the mean work time has to be converted into work per year per person. Therefore, the 29 is multiplied with 52, as one year has 52 weeks. Finally, for the value of time, the value below is calculated.

λ = 42956/(29*52) = 28.4854 euros/hour

Figure 2: Formula to estimate the value of time using the income approach

Distance Based Pricing

Distance based pricing is the most binary form of pricing, every kilometer driven on a road has to be payed. As simple as it is, there are numerous technical and social difficulties ought somebody try to implement this pricing policy. First of all it would require a massive technology investment as the entire road infrastructure needs to be able to keep track how far a particular vehicle travels. This could be achieved with a gps tracker within every vehicle however there are obvious privacy concerns with this approach. Furthermore it causes additional complications for vehicles coming from countries/cities without this system. An alternative would be to implement a system on the roads themselves which keeps track of the kilometers traveled by a vehicle. With this approach the privacy concern remains and the previously mentioned issue of not every vehicle being equipped for the system is replaced with a very large cost to fit all the infrastructure with the tracking system. In terms of social difficulties, the total amount of traffic will definitely be reduced, taking the care purely for convenience will be considered more carefully. However, every vehicle will aim to use the shortest path, which will in turn cause more traffic congestions especially in city centers. While somebody who wants to go from one end of the city to the other, would usally take the belt, will now try to go through the city center because it is shorter in terms of kilometers. This causes frustration for everybody, the ones which are stuck in traffic to save money, the ones which actually have to go through these roads and are stuck in aditional traffic of people who do not necessarily need to use these roads. It also reduces the quality of life for inhabitants of the city center, as there is increased traffic which does not have to be there but is incentivised by the dinstance based pricing.

Fairness

Fairness in Pricing

As we know from the section on dynamic pricing, the cost of driving on certain roads may be larger than the cost of driving on other, lesser used roads. The price will go up if there are more cars using a particular road, and down if there are less cars. This has a big impact on people using these roads. Lets take two factors into consideration here. We have driver A, who is very rich, and can easily pay the costs of going over this road. Then we have driver B, who earns very little, but still has to cross this busy road every day to get to his job. Now, in this case, with more cars driving on the road, the prices will go up, and driver A can just not care about it at all, even driving with an entourage and paying for them, simply because he can. But driver B will not be able to afford doing this, as he can barely pay for himself to go over this busy road. Going around could be an option to save the money, but lets assume that driver B does not have the time to do so. What would be the action that should be taken in this case? Should we lower the price per car, such that people with less money are able to take the road, or should we keep the price like this, and risk that people will complain about the system?

This is a small dilemma where you have to look at it from both sides. On one side, decreasing the price, we will keep more people happy, as they are actually able to pass the road while paying a smaller fee. The problem though, is that in that case the roads will not necessarily be emptied enough to improve the flow. On the other side, keeping the price the same, we will be able to reduce the flow to the desired level, but we will introduce an aspect where people are not able to pay for passing the road, and they will get unhappy about the situation.

It is difficult to find a good balance between the two sides. On one hand you want to keep everyone happy about the system, but on the other hand, you also want to improve the flow in the city such that there are less traffic jams occuring, or less problems arise with accidents.

Judging this problem from the direction of the software, it would be obvious to put the emphasis on improving the flow, as that is what the software and algorithm aim to do. But the government of a city is not able to choose such a direction at all times, or at least, not in full. They need to try to maximize the happiness of the people in the city, as well as try to reduce the flow to the wanted level.

As this problem is difficult to solve, and needs a lot of discussion, there is not one answer that the system can provide. In the end, the software will give an advice to the government with points that can be improved, and how they can be improved, but it is in the end still up to them to decide what to do with the given advice. The advice should not be blindly followed, as can be seen, because it can lead to negative responses from the people. The fairness of the prices should be kept, while trying to adjust the flow to the desired level. This task, is all up to the government to discuss about and try to find the ideal mid point.

Fairness in Rotterdam

Using a map from the CBS [4] and searching for the Rotterdam area, we get an indication of how the average income is distributed in the city. This can help us deduce a possible direction and possible additional advice to give.

As can be seen from the map, the zone around Ijsselmonde in the south eastern part of the city, below the Nieuwe Maas, is relatively poor, as it consist of more zone with an income of 19k or less per year. Compared to the zone slightly more to the south, Barendrecht, there is a significant decrease, namely from 25k and higher, to the aforementioned 19k or less. Layering this over our own simple road network, we can see that most of the southern roads lie in this relatively poor area. That is, until the roads of the city meet with the roads at the outer area, around Knooppunt Ridderkerk. The roads on the south east of that knooppunt are in a higher income zone of 21k to 30k.

The roads on the northern part of the Nieuwe Maas differ from the southern parts. The roads close to the river itself lie in a zone with an income that is very varied. The majority of the zone has an income of 25k or more, but there are also parts that only have an income of 17k to 21k. As this part of the network has a very diverse area with a lot of different incomes, it is difficult to put any average conclusion to this part, making it an ideal place to have an unbiased tollgate, one that is not biased towards any income group.

To the north of this area, north of Blaak and the Coolsingel, is an area that has a very low income, of 19k and less. To the right of this area, near the Kralingse Plas, there is an area with a higher income, with an income of 25k to 30k. Only one of our roads goes through this zone, that starts at lower income, and quickly grows to higher income. This means that the prices applied to this tollroad should be higher towards the entry and exit points on this side of the city, namely the exit points of the G.K.van Hogendorpweg and the A20 in the north-eastern part of the city.

Finally, the last areas are the exit points on the western part of the city. The area around the A13 and the A4 both have an income of around 25k to 30k. The area around the Beneluxtunnel has an average income of 21k to 25k. Lastly, you have the western part of the A20, which has an income of aroud 21k to 30k, and the western part of the A15, which has a surprising income of 25k or more.

Using all these points of data, we can make a conclusion of where to apply more price increase or decrease and by how much it should be altered. As can be seen from the outer zones, the bigger roads such as the A20 or A15, the income is generally on the higher side, with little mixed incomes. Therefore the price in these areas can be slightly higher than the average, but not too high, as the income usually lies between 21k and 30k. The prices in the northern part of the center of Rotterdam should not be using too many differences in pricing, as there is a large amount of varied income in these areas. The southern area has a slightly lower average income, so the prices there should be lower than the average pricing. The exiting area towards Ridderkerk is slightly higher though, so the price over there should be a bit higher than the average. Both of these zones have a fairly consistent income range, making the choice of having prices be lower or higher in these zones very easy to discern.

Plots of pricing

There are different prices for different edges after performing a calculation. Some examples of plots that have been gained from performing the calculations are listed on the side.

Pricing plot of edge/road 1

Pricing plot of edge/road 8

Pricing plot of edge/road 37

Pricing plot of edge/road 141

Pricing plot of edge/road 223

Pricing plot of edge/road 270

Some of these roads have a charge of 0. Some examples of roads that have a price of 0 for the entire duration, as in, with any number of cars, or that have 0 in most cases, but only a small amount of charge if the amount of cars is high, are edges 1 and 8 as can be found in the plots. There are many others similar to this, but they have been left out so as not to clutter the page. If we’re looking at the map that shows the roads, and compare that map, this data from plots, and the data from income zones, we can see what these roads have in common. Most of the roads with very little to no charge lie at the edges of the road network, that being the highways. There are some others that are located in the center, such as road 229/230, or roads 289 to 292, but these are very small and short roads. The plots of these roads all only need a price if the amount of cars is very high. This is very understandable, as a short road is quickly left after entering, hence a congestion will only occur with a lot of cars. Hence the pricing only applies once this limit is reached.

What can be found from the rest of the plots is two different things. First off, most roads tend to have an upwards trend. That is to be expected, as with more cars, the price naturally goes up. This is the case for edges/roads in any zone of the city, whether the income is high or low. Some plots showing this off are the plots of edges 37, 223 and 270. The other interesting point is a seemingly random cluster of points in the plot, as can be seen in the plot of edge 141. The amount of edges where this seems to be the case is very low, there are only 5 or 6 occurences of this happening. These plots are difficult to interpret, because they seem so random with the distribution. The plot looks like it has a better flow at certain amounts of traffic, as the prices get a lot lower at for these higher amounts of cars, but the price goes up again if the amount of cars increases. What we can conclude from these roads is that they lead to areas that are less used in the city, but they are the only road leading to that area. These are branching roads from the main roads, but they eventually lead back to the main road section again. Thus these roads have very varying data as they are used less frequently, and have a more specific flow control point as can be seen in the plots.

From our data, we know that roads with prices such as 141, lie in a higher income zone, while roads such as 230 lie in a lower income zone. If we compare the data we have in terms of the plots of the dynamic pricing, we can see that the prices for lower income zones are more distributed in the area with roads that are like 37, having an upward trend, in comparison to the prices for roads in the higher income zone. This can be because people with lower income live in areas with roads with smaller capacity, or with lower speed limits, thus resulting in more congestion with higher amounts of cars.

Trade-Offs of manipulation of value of time

There are several negative consequences and some positive consequences when the municipality manipulates the value of time to an artificially low level or an artificially high level. Firstly, if the variable is manipulated to an artificially low number relative to what the actual value of time should be, it leads to roads becoming cheaper for the people to access. This means that marginal private benefit of the driver entering the road is higher than the marginal cost of all drivers planning to ride that road. This will lead to people still using those roads that are prone to congestion in the status quo as the cost is so low anyways. This results in the fact that congestion will still occur even if the total capacity of the road system has not yet been satisfied. Therefore, congestion will still be a common occurrence which has negative consequences to the environment and people as highlighted throughout the wiki. The only positive aspect of this type of manipulation of price is that the roads is still affordable for the very poor in society meaning that these groups will not lose as much mobility compared to when the value of time is set according to the formula presented previously in the wiki.

In case the variable is manipulated to an artificially high number relative to the actual estimation of the value of time, mobility of not just the very poor in society but also the middle class will decrease as well. This is because if the variable of value of time is set high, the road charge will become higher too. Therefore, many people will not be able to afford to drive on roads even if it is for a purpose which is strictly necessarily. This is undesired as then people have less incentive to work for a better paying or more economically productive job further away in the city as when the cost for transportation is factored, it is not worth to these people anymore. Also, if municipalities would increase the price too much, the public support will be lost. This is problematic as firstly it is less likely that road pricing will be able to be continued in future and secondly, the direct users of the software, the municipal politicians are more likely to be antagonized by the public. This is specifically a problem for the users as in a democracy like Netherlands, these politicians have a higher probability of not getting reelected meaning that the chance of losing their jobs in few years increases. The only positive aspect this artificial inflation of the estimation of value of time may have is that the income for their municipality increases. This as most people will still be driving for necessary matters even if the price is higher as public transport is also relatively expensive. This money can be used by the direct users of the software in whatever tools that increases their public support for the next election period. However, the effect of being antagonized due to too high road prices will more likely be greater than the effect on support for re-investing the money wisely from the income gained by very high road pricing. The reason for this is that roads and transportation as a whole is a aspect of the society that great number of people have a strong opinion about as many people both the proletariat and the bourgeoisie use roads, often on a regular basis.

Feasibility

Road pricing is a system that is already used in many road networks of many countries. However, the classic road pricing system uses toll gates which is often only implemented in high ways or big intercity roads. This is because if toll gates are implemented in intra-city roads, it will cause an increase in congestion as each car has to wait in front of every toll gate that the car wants to pass. Fortunately, electronic road pricing (ERP) systems have been developed for decades. These systems do not cause any reduction in speed of the cars as it does not require the car to slow down when going through a gate. This is as these gates are just sensors located on top or next to roads which communicate with each car that passes through. This system is already used in many cities such as but not limited to Stockholm, London and Singapore. The cost of implementing ERP system had cost of around S$197 million in Singapore. This is equivalent to around 130 million euros. This seems quite expensive, however the cost is similar to a medium sized car bridge which is commonly built in Netherlands. Furthermore, annual maintenance of this system will be around 16 million euros. However this cost can be covered with the money gained from people who pay money to drive on the roads. Since the relatively low implementation costs and an easily covered maintenance costs, financially road pricing is very feasible in high income MEDC like the Netherlands. Finally, in order for the road pricing system to be actually implementable, public support by the populous is also necessary as otherwise there is insufficient political capital. Fortunately, as shown in the results of the driver survey, public support is already sufficiently high in order to have enough public support to implement this road pricing system. Therefore, in conclusion, an ERP system in Rotterdam is feasible.

Software Research and Development

Maximum Flow Research

The problem we are looking at is considered an instance of the Maximum Flow Problem. This problem is defined as follows: “Find a feasible flow through a flow network with a single source s and a single sink t, such that the flow is maximum.” A flow network is defined as: “A directed graph where all edges have a capacity, and all edges receive a flow.”

The first known algorithm to solve this Maximum Flow Problem was created by Lester R. Ford Jr. and Delbert R. Fulkerson, and is called the Ford-Fulkerson algorithm. Over the years there have been many improved solutions for the Maximum Flow Problem besides the Ford-Fulkerson algorithm. Some of the more notable ones are:

• Edmonds-Karp
• Dinic’s blocking flow algorithm
• push-relabel maximum flow algorithm
• Binary blocking flow algorithm
• Orlin's + KRT’s algorithm

All of the algorithms listed here will be explained below, and compared to each other to see which one fits best to our instance of the Maximum Flow Problem.

Ford-Fulkerson

A greedy algorithm to compute the max flow in a flow network. The idea for Ford-Fulkerson is that, as long as there exists a path from source to sink, with capacities available on the edges in between, we can send flow along one of the paths. This is repeated until there exist no more available capacities. The paths that still have a capacity available are called augmenting paths. When no more augmenting paths can be found in the graph, the maximum flow can be found by adding the flow augmenting path and the flow already established in the graph together. There is no guarantee for this to happen though, therefore the only certain aspect is that it reaches a correct answer when the algorithm terminates. The runtime for this algorithm is O(E*max|f|), with E the number of edges in the graph and f the maximum flow in the graph.

Edmonds-Karp

An implementation of the Ford-Fulkerson algorithm, which is largely the same as the other. The only difference is that in Edmonds-Karp the search order for the augmenting path is defined. The way this augmenting path is chosen, is by choosing the shortest path with the available capacity. This path is found by applying a breadth-first search with a weight of 1 per edge. The runtime for this algorithm is O(V*E²).

Dinic’s (blocking flow) algorithm

A variation on Edmonds-Karp, also applying the breadth-first search method, but instead of using it to find an augmenting path and sending the flow directly over it, we check if more flow is possible and construct a level graph out of it. We use BFS in a loop to construct this level graph. In a level graph we assign levels to all nodes, with the level being the shortest distance(read: smallest number of edges) of this node to the source. With this level graph, we can send multiple flows. This is the reason why Dinic’s algorithm performs better, as instead of only sending flow over one path, we send it over multiple at once. The runtime of this algorithm is O(V²*E).

A core concept of this is to make use of blocking flow, which means that an edge can not send more flow using the level graph, that is, there exist no more paths from s to t such that the vertices on the path have levels 0,1,2,... in this exact order. Blocking flow can be seen as maximum flow in greedy algorithms. One additional optimization that can be applied is the use of the dynamic trees data structure, which speeds up the computation of the maximum flow to O(V*E*log(V)) by making finding blocking flow in each iteration faster to be O(E*log(V)).

General push-relabel maximum flow algorithm

This algorithm is similar to the Ford-Fulkerson algorithm, but changed up to improve the flow. Similar to the other algorithms, push-relabel also uses the residual graph to check additional possible flow in a network. It differs in the fact that it is checking the augmenting path for one vertex at a time only, instead of examining the entire residual network. As the name suggests, this algorithm computes maximum flows using two basic operations to perform its tasks.

If you consider the source to be the highest level, all following nodes will be a level below that, until you reach the bottom, the sink node. The “push” operation pushes the flow to the next vertex which needs to have a small height once the vertex that is currently being looked at has reached its capacity. If the flow gets trapped at some point in the graph, the vertex at which this happens will be “relabeled”, which means their height will be increased in the graph. The runtime of this algorithm is O(V²*E), but can be improved if certain conditions are met, or the algorithm is changed slightly. It can be O(V³) if the most recently active vertex is chosen to be looked at(using a FIFO selection rule), or O(V*E*log(V²/E)) if the algorithm builds limited size trees to calculate the height.

Binary blocking flow algorithm

The algorithm uses an augmenting path and blocking flows, similar to Dinic’s algorithm, but it is applied differently. Goldberg believes this creates a fundamental improvement to calculate the maximum flow of a graph. However, from practical experience, we can derive that the push-relabel method is in fact more practical than using blocking flows.

Whereas Dinic's algorithm uses only the concept of blocking flows, Goldberg's algorithm extends this concept to more general length functions, as that is what blocking flow is based on. The length function that is used in Goldberg's algorithm is more specifically a binary length function, which assigns arcs(edges) to be zero length if their capacity is large, and gives the arc unit length(which is defined to be 1) to small capacity arcs. This makes the binary length function adaptive, which is a crucial feature to improve the time bounds.

The runtime of this algorithm is O(E*min(V^(2/3), sqrt(E))*log(V²/E)*log(U)). The U here is the maximum capacity of the network. Other than that it’s fairly similar to the push-relabel algorithm with dynamic trees. They take the minimum of V^(2/3) and sqrt(E) because it is a proven runtime from Dinic's algorithm as long as there are unit arcs. You apply that on all edges, hence the *E part. The multiplication by log(V²/E)*log(U) is to find the blocking flows in the network, as can be found in the paper of Goldberg.

Orlin’s + KRT’s algorithm

In a paper made by Orlin ways are described to improve and solve the max-flow problem in O(V*E), as long as the requirement is met, being E <= O(V^(16/15-e)). Similarly through the combined effort of King, Rao and Tarjan, KRT’s algorithm solves the max-flow problem in O(V*E) if E > O(V^(1+e)). Both of these runtimes have a value e in it, which denotes a positive constant integer value.

Orlin's algorithm solves the max flow problem in improvement phases. They then create an abundance graph, and use contraction to speed up the algorithm. This abundance graph is then used along with some of the arcs to contract it into a smaller max flow problem. This smaller max flow problem is then compacted by removing all nodes in the network that have either all incident arcs being abundant, or a very small capacity. Using all of this together, we can run the algorithm in an improvement phase for the max flow problem on this compact network to reduce the runtime to O(V*E+E^(31/16)*log²(V)), which, when using the special bound on the edges, can be reduced to O(V*E). There is a bottleneck in the algorithm, which is the time it takes to maintain the transative closure of the abundance graph, as can be found in Orlin's paper.

KRT’s algorithm is based on the randomized algorithm created by Cheriyan and Hagerup, which computes the maximum flow in a a graph to efficiently play a certain combinatorial game that arises during computation of the maximum flow. The algorithm of KRT is similar, but uses a more general version of the game described by Cheriyan and Hagerup. The strategy of KRT yields a deterministic algorithm for computing the maximum flow that runs in O(E*V*(log_((E/V)log(n))(n))). This can then be reduced to O(V*E) if the constraint is met that states that E > O(V^(1+e)).

Combining the knowledge of both improvements can allow for maximum flow problems to be solvable in O(V*E) time, if the conditions are met in terms of its edges. Whether it is useful for our problem will be discussed in the next section.

Which algorithm should we choose

We will choose which algorithm to use based on their runtimes and method of implementation. Basing our software model on an algorithm with a faster runtime, will result in the model being easier to use for larger datasets in comparison to other algorithms with a higher runtime, which is what we are making use of in our instance of the maximum flow problem. If two or more algorithms have the same runtime, ease of implementation will be deemed more important, as it is less time consuming to fix errors or bugs in a simple software model when compared to an elaborate or complex one.

Based on the runtimes of the algorithms, the best one to pick would be Orlin’s + KRT’s algorithm, as O(V*E) is by far the best. However, it has some requirements that are not easily satisfiable by us in our project. The algorithm itself is mostly theoretical, which means it has not been implemented in software at all. Hence this algorithm is more difficult to implement and will probably not be chosen. Another reason for not choosing it, would be because it has strict requirements on the number of edges, which does not always happen in our instance of the Maximum Flow Problem. The more basic methods of Ford-Fulkerson and Edmonds-Karp are the general cases of how to implement maximum flow problems, but they are still on the slower side. Dinic’s and Goldberg’s blocking flow algorithms are already a lot faster, as the runtime is O(V*E*log(V)) instead of O(V²*E). As the number of vertices is always lower than the number of edges in a flow network, having the runtime depend more on the number of vertices than on the number of edges will make for a significant improvement, hence why Dinic’s algorithm would be prefered over Edmonds-Karp. Goldberg's binary blocking flow seems even better, but it has a major downside, namely that it is only having such a good runtime if all edges have a unit capacity of 1. As this is not the case in any real world scenario, this makes the algorithm unusable in our instance of the Maximum Flow Problem. The last algorithm, the general push-relabel algorithm, also has the same runtime as Dinic’s algorithm, can be sped up even more if the right data structure is being applied.

Therefore, the choice of what algorithm to pick, should be based on the implementation of either of them. If it is a feasible choice to utilize these data structures in our software model, then using the push-relabel algorithm should be the right way to go. If, however, it turns out to be difficult to implement, then it might be better to choose for Dinic’s algorithm, as it is a more simple model to implement than the push-relabel algorithm, while also having the same runtime.

SUMO and YatSim

In order to calculate the flow of the cars, we have to simulate the movement in a road network. There are already some simulation networks for this, out in the open. Two of which are SUMO and YatSim. Both will be described below, and compared to find their good and bad parts. This is all such that we can simulate the car movement itself in our own network. We will be looking at things such as the input and output of cars, as well as general data regarding the traffic.

SUMO

Simulation of Urban Mobility. This is a simulation of traffic, as an open-source project. As it is very difficult to create an exact model of traffic itself, researchers have tried to make predictions based on simulations of the traffic. SUMO aims to be a simulation that can be applied in different ways because of its open-source nature, allowing for different models to be created using SUMO as its basis.

How does it work

The simulation shows the path per single human, on his or her way through the traffic. All car movements, as well as public transport systems within one city are modelled within this simulation. What is described in the simulation is the departure time and the route the person takes, which can consist of multiple subroutes that describe the entire traffic situation. A person may then follow a route consisting of both car and public transport, as well as walking. The walking part is not part of the simulation directly, as it is given as an estimate of the time spend to reach the destination.

In SUMO, every vehicle has a place and speed within the simulation. Every step the simulation takes, which takes one second per step, the values are updated corresponding to the vehicle in such a way to simulate the movement. The simulation itself is time-discrete and space-continuous, because the majority of the car-driver models are also continuous. Of course, all the traffic rules, such as traffic lights, maximum speed, right of way, etc. are taken into account and followed by the simulation.

The car-driver model that SUMO uses is based on the Gipps-model extension, and is capable of displaying main features of traffic like free and congested flow. In each step of the simulation, the vehicle’s speed is adjusted with respects to the vehicle in front of it to avoid congestion as much as possible.

The input for SUMO is based on XML files, containing edge types, nodes and edges. This can be made using different sorts of data, such as XML files themselves, CSV files, Cell-input files or VISUM networks. Using SUMO-NETCONVERT you can then create the needed input data. Nothing specific is mentioned regarding the data of the cars themselves.

There are two outputs available after running SUMO’s algorithm. The first being the raw output, which contains all edges of the network with the vehicles driving on them for every step. The vehicles are denoted by name, position and speed. This raw output is a complete output, meaning it can be used as an input to other processing tools for evaluation. As this gives a large amount of data if a large simulation has been done, it is often not the best choice. As such, other outputs have been made to cope with this issue. One of these is a log-file made by simulated detectors which can be positioned on a certain edge of the network, and can compute the flow, average velocity and other values. Every such detector has their own output, which is written to a csv file.

YatSim

Yet Another Traffic Simulation. An open-source software framework, which is able to simulate and validate CBAA-M, an algorithm which enables multi-agent cooperation within autonomous traffic to safely and efficiently pass intersections, within a realistic urban scenario.

How does it work

YatSim uses the CBAA-M algorithm, which consists of two phases. The first phase is the auction moment, which builds upon a market-based selection strategy, where each vehicle computes a bid. This bid is build on a linear combination of the distance to a common collision point between the future path of two vehicles, based on their speed. This is done for all vehicles in the list of known vehicles to the system in the second phase, the consensus process, for every future point on their paths. These bids are then sorted in descending order to determine a priority list, which indicates what vehicle is allowed to pass what intersection first.

In YatSim, you have Generators, which are able to introduce new vehicles to the network given a certain probability. These vehicles are able to move on the roads and intersections, with roads being edges in the network, and intersections being points where two of these roads overlap. The map over which vehicles will be generated is given in graph representation, which is build by the system. All paths that are calculated for the vehicles are made using Dijkstra’s algorithm.

To do the actual traffic simulation, YatSim uses a time-discrete process, which uses tick-events. Every tick, YatSim iterates through the scenario’s generators and vehicles to forward the tick-trigger, making it execute. Newly generated vehicles need appropriate values, which means they will always be triggered after the already existing vehicles in the network. The generation of vehicles is done based on probability “p”, which you give to the generators. Every execution of the generator, a random number “r” is computed. If 1-r >= p, a new vehicle is added to the system. A vehicle is removed from the system if the new position that is calculated for a vehicle is still valid. If it is valid, then we know it can continue to move in the next phase. Otherwise, it will be removed from the simulation, as it has reached its final destination at the end of its path.

The simulation itself does not give a single output, but instead multiple graphs per intersection. The graph representation of the vehicles on an intersection are given in multiple tabs, namely Speed, Speed Ratio, Acceleration and Distance, in order to analyze what is happening to each car. As it is not specifically stated in the paper how exactly this output works, or behaves, no other information can be gained about the use of the output, how much data there is, or what to do with it.

Comparison

Both of these simulation softwares have their uses. SUMO has a more elaborate output that can be used to analyze data more thoroughly, while YatSim’s output is more vague, and can be more random. The input of cars in YatSim is based on random number generation, which means tests have to be done multiple times in order to get proper results. The input of SUMO on the other hand is only the XML files with edge types, edges and nodes. Nothing specific is mentioned on how it handles the usage of cars, and how it distributes them with their paths, speeds, etc.

The system that YatSim uses seems more complicated, as you will need to create all intersections by hand. SUMO uses the direct input of the roadmap instead. This seems like a better plan, especially when compared to what we had in mind ourselves. Besides that, YatSim also is more computation heavy than SUMO, especially on larger data sets. This means that on a bigger city, with more data points, SUMO would be a better alternative.

Therefore we think that to simulate our car movement, we will use a similar method as SUMO does. It is easier to use with our implementation, is faster in running the data, and is a better application to our specific problem. Of course, as it is an open source software model, we are free to alter certain aspects to make sure it fits exactly to what we need it to be.

Database analysis

From when we decided our project and the simulation that comes with it, we were looking for traffic data sources which would allow us to supply our simulation with real life data. No member of our group had special connections to traffic data sources so our best chance was Google and the local municipality. The latter was not particularly helpful, so after some extensive google searches we found NDW. The NDW provides real-time, as well as historical traffic information. [5] [6] [7] The traffic data came in the DATEX II format, the European standard for traffic information. [8]

Raw data in the DATEX II format

After studying and understanding the essentials of the DATEX II scheme, it was possible to filter the data for the region around Eindhoven, the results were not what we expected. OpenStreetMap provides map data that we can use for visualization. [9] [10] [11] [12] Using this tool, a map of Eindhoven and all locations where traffic information is being collected was created.

Measurement site locations in Eindhoven

While the data was very detailed and updated every minute, it did not cover non-highways and was therefore not very useful for our project which aims at optimizing traffic flow within urban areas with tight roads, traffic lights and intersections. The alternative was obviously to generate the traffic data using educated guesses and random number generators, but we felt that would not show our product was doing any optimization since a real traffic situation is much more structured and complex than what a random number generator gives. The idea of manually collecting traffic information came up briefly, but was dropped due to how inefficient such an approach would be.

Trying to find a new way of gaining realistic traffic data, we realized that some cities had more collection points than others, Rotterdam was by far the city with the highest density of collection points. Another advantage of Rotterdam is the way it is surrounded by highways, meaning that most vehicles leaving or entering the city center would cross at least one collection station and hence be registered in the data. This means that while we could not directly use data for every single road in Rotterdam, we could approximate how much traffic was entering and leaving the city and hence predict the traffic density within the city.

Measurement site locations in Rotterdam

The final image shows a map of the roads we are going to implement in the simulation, either because their endpoints or the roads themselves have a measuring station. This approach will put a higher strain on the simulation because it now has to plot the path of individual vehicles with a pseudo-random destination and path to that destination. In the end, the chosen destination and path of each individual car should be such that together the traffic matches with the data from the observation points.

Selected roads and measurement points in Rotterdam

From Data to Input

As can be seen from the figures posted above, we have a lot of data with different points of measurements. These data points can be used to create an input for our model. The software model itself can not use the data directly, as it has to be transformed to do anything meaningful with it. So what we have to do, is to transform the map of datapoints we have currently, into a flow network, such that we can run our algorithm on it. To transform the data we have to a usable flow network, we have to follow a few steps.

• create edges
  • add edge capacities
  • add flows to start with(if needed)
  • create directions for the edges
• create vertices
• create a single source and sink

We start out with just a map of the area, Rotterdam, which has roads planned out with the data points that have the collected data of how many cars passed by during a certain time period. The map itself has all the edges already, namely the roads themselves. All the data points of the roads determine the capacity a road may have. If a road has data that shows congestion starts to form at for instance 20 cars over a period of 30 seconds, then that specific edge will get a congestion value of 20 per 30 seconds. Not every road will have the same type of measurements, meaning that not every road will have an amount of cars over 30 seconds. Instead what we need to do first, is map out all these capacities, and set them to be of the same type, such as "X amount of cars per minute". Having done this for all the roads, we then also have the capacity for all edges.

We also know the direction of the roads themselves, as some of them are one way streets, or they allow traffic in either direction. Hence we can set all these edges to already have a direction. For every edge that allows traffic in both directions, we create a second edge, with the same capacity, and make both edges have opposite direction. This is done because a flow network that we need as input, does not allow for a bidirectional edge. Creating two edges as described would allow for the structure to be kept as shown on the map, while also following the rules of a flow network.

Next up the vertices. These are very simple to choose. We can simply determine the vertices by looking at all the points in the roadmap that have an intersection between two or more roads. The vertex would then be the connection point between the different incoming and outgoing edges. As described above, we have two different edges if a road in the roadmap allows for traffic in two directions. Both of these edges will have the same two vertices that they are connected to as start and end points. This will ensure that traffic flow will be able to be directed properly, while also keeping the amount of vertices used minimum.

Lastly, we will need to have a single source and a single sink vertex. These points are crucial in creating a proper flow network. This is also the most difficult part of creating the network from the roadmap, as, judging from the roadmap, there is no single destination or source that each car is going to or coming from. As the map shows, there are multiple highways going into and leading away from Rotterdam. What we will do as add so called sub-sources and sub-sinks to these incoming/outgoing edges at the edge of the roadmap. For every road at the edge of the roadmap, there exists a sub-source and a sub-sink, as a car can drive into the city, or leave the city, from that specific highway. These highways still have measurements of data, hence their capacities have already been calculated before. Therefore, each entry/exit to the network, will get two edges going out of, or into the network, connected to the specific sub-source, for incoming, or sub-sink, for outgoing edges. Next up is creating the actual Source and Sink vertices. This is done by adding these vertices to the graph, and adding an edge from the Source vertex to every sub-source in the graph. The same is done for the Sink to all the sub-sinks. As it is undetermined how many cars will actually be in the system, we set the capacity of both the edges from Source to all sub-sources and Sink to all sub-sinks to be infinity. That way, we can always direct as much traffic as needed into the graph.

With this method of adding a source and sink, we will run into an issue, namely: would the network not just push all the incoming cars from sub-source A to the sub-sink of that same vertex A? As this would allow for the flow to be maximimzed in every case, as infinite cars will be coming in and going out of the system. This is however not a problem. There is an infinite capacity of the source to the sub-source. But then, to go from that sub-source to the sub-sink, you will have to first go through the edge of the sub-source to a different vertex. This edge will have a "normal" capacity, which is not infinite, before it can be send back to the sub-sink of the sub-source, and then to the actual sink. This means that we can never have the situation where there is a stream of infinite capacity and flow in the network, as the sub-source and sub-sink are two distinct vertices.

Application of the Algorithm

Having an input network created from the data means we can use the algorithm itself. As explain in section Maximum Flow Research, there are only two different algorithms that are worth looking into. First off we have Dinic's Blocking flow algorithm, which works by looping a BFS over a level graph to check multiple flows at once. The other one is the general Push-Relabel flow algorithm, which pushes flow to the next vertex, and relabels the level graph. As we have not decided which to use, we will just refer to it as "the algorithm". Their runtimes are very similar, which is why it does not really matter which one to pick.

With the input, and using the algorithm, we will get a resulting flow network. This network will have, over all the edges in the network, a number denoting the flow over that edge. We assume that the algorithm performs the calculations correctly, and is able to create a maximum flow network properly, such that we can use it.

With this output we will be able to optimize a road network. We already have the network of how the roads are planned out, and we also have data showing what roads are congested, or more empty. From our output from the algorithm, we get how many cars are able to pass over a trajectory every hour. With that knowledge, and the pre-knowledge of the congestion on the roads, we can give a recommendation to the government. This recommendation will include ways to go from this current situation(the pre-knowledge) to our optimized situation.

To reduce traffic congestion, there exist several methods. Unfortunately, many of these methods are only temporary solutions which is not useful in the long term. One of those "solutions" is increasing lanes. As roads get more lanes, more cars will drive those roads as people think there is less congestion. This in turn leads to as much congestion or in many cases even more congestion. This phenomena is called induced demand. Furthermore, many of the long term solutions such as improving public transport concerns modification of the transportation system as a whole rather than just road networks, hence this will not be in the scope of the project.

This could be advice in the form of, but not limited to:

• closing/opening a lane of traffic
• lower/raise the speed limit
• close of a road for a certain time of day.
• add tollgates/ERP booths to the roads, thus pricing them
  • this can be permanently
  • or at specific time intervals

Closing/opening a lane can make the traffic more spread out, increasing the flow of the lanes. Lowering/raising the speed limit allows for a better flow of traffic, depending on the situation. Closing a road for a part of the day will make people drive around that road, taking other paths instead to get to their destination, which improves flow on other lanes too. Adding tollgates/ERP booths will make people choose more carefully about the path they will take to get to their destination, redirecting some of the traffic to improve the flow over the entire network.

These are just a few ways that we can apply the algorithm's output, and give advice to the users of the software product. Of course, there are other alternative advices to be given, but these are some of the simple ones that can be derived directly from the model, as the current situation does not need to be altered much to match the output in all cases.

Prediction

Currently, experts themselves do not agree on which methods to use when. Therefore, the best method of prediction would be to brute-force each advice into another simulation and see which one of these methods will result into the least congested road network. Another option is to focus on one output only, and then advice on which roads the output (for example road pricing) should be applied to. We will show some different approaches, but focus on one specific instance.

Levels of the software

Every city is different and with varying needs. By this it is not only meant that the city is constructed in nonidentical ways, but that they are managed by people with ideas and priorities that may change. For this reason ConSol is divided in three different levels of simulation in order to better satisfy the expectations of the accounts.

Level 1

ConSol will detect, analyze and simulate congestion points and their impact. A list of ranked options of roads that are most likely to reduce the amount of congestion will be provided. These can then be used as a starting point for an independent study of the available options to reduce the congestion on these roads.

Level 1 works as follows:

• A 24-hour simulation is made
• From this simulation, for each road the percentage of the time the road is priced is calculated
• The sensitivity determines the threshold, if the sensitivity is 70%, a road needs to be priced at least 70% of the time for the road to be marked as congested
• These roads are then displayed on the map

Level 2

ConSol will detect and analyze congestion points and give an advice on which roads should be designated as toll roads, along with a static pricing and times at which to apply the toll. Moreover, this could be subject of a survey about the support among citizens for reducing congestion by applying toll roads and provide an insight into how they could be priced.

Level 2 works very similar to level 1, with a few differences. Instead of marking a road as congested, a price is given to each road. This price is based on the percentage of the time the road is priced multiplied by the base price (€1 by default). These are then placed on the map and a price is displayed.

Level 3

ConSol will detect and analyze congestion points, and show a simulation of dynamic pricing applied to detect congested roads. This is achieved by taking into account the level of congestion and the average income for the complete city. For every hour of the day, a different price will be applied to allow roads to be used to their full capacity.

For level 3, the dynamic pricing algorithm is used. It is based on the formula shown earlier and the simulation is based on the data for a single day. In the final data, this data is from 20-03-2019.

Level 4

ConSol will detect and analyze congestion points, and show a simulation of dynamic pricing applied to detect congested roads. This is achieved by taking into account not only the level of congestion and the average income for the complete city, but also inter-neighborhood travel times and income per neighborhood for a fair and impactful pricing.

Level 4 is level 3 with a modifier based on the neighbourhoods the road passes through. The average of all roads it passes through is taken and a modifier is derived from the income level compared to the average income level for the municipality of Rotterdam.

Software Problems

We have encountered several problems during the development of the software, which we will describe below.

Mesaurement sites locations

Measurement site locations problem: these cannot be matched automatically

The first problem we encountered is that the measurement site locations are only given as a coordinate and a direction, but do not directly correspond to a road. Therefore, we have taken data from OpenStreetMap to match to the measurement sites. However, when doing so we discovered that some of the measurement sites are located at one side of the ride, while it measures the other direction. See the image to the right for an example. The red point represents two measurement sites, but one of them is South-East bound, while the other is North-West bound. By using an automatic matching algorithm, both would be matched to road 3685. It is also not feasible to implement an algorithm to include the direction, since the directions are not very accurate. Therefore, we have manually matched all 250+ of these sites to the correct road.

Disconnected road network

The disconnected road network at one point in the network

After fixing the above problem, we started looking into the actual road network. However, we discovered not all roads were connected, which is a problem because that means we are not able to use this road network for our simulation. Therefore, this required manual intervention to fix the road network.

The road network showing nodes which are not connected to the main network in red. Green nodes are nodes that are connected to the main road network.

After further investigation, the problem is much more severe and requires much more manual work than first thought. As can be seen in the image to the right, a lot of the road network is disconnected.

Incomplete data

The blue roads represent all road for which there is data (i.e. a sensor on the road), while the black roads are roads without a sensor

There is one other problem with the dataset: not all roads include measurement points so some of the roads need to be interpolated based on other roads.

New road network

Due to the problems mentioned above, we have created a simple road network that represents Rotterdam, which can be seen to the right. The green markers represent entry and exit points, which are points at which cars enter or leave the network. We assume cars do not leave or enter the network at other points. The red lines on the map are road segments where no measurement points are located. For these road segments, we have manually set the measurement points which are used for the calculations.

The created simple road network. The green markers represent entry and exit points, which are points at which cars enter or leave the network. The red lines on the map are road segments where no measurement points are located.

This road network allows us to iterate much quicker due to the smaller size and better defined structure.

Algorithm problems

As discussed above, we worked on implementing flow control using MaxFlow algorithms. After implementing the algorithm and running it, we found that it was not very usable. The algorithm could not return the edges that we wanted, but only the critical edges. These were usable, but ended up being not interesting enough, as the roads returned were only on the outer edges, namely the roads leading into and out of the network. These edges were obviously going to be critical, as they had the most capacity that allowed for flow to be sent through them. As this was not exactly what we wanted, we looked for other ways around this, to still get a flow control measure. One of the alternatives was the dynamic pricing formula, which prices roads more strictly depending on the amount of cars that drive on the road. While implementing this, and running it on a simulation of cars driving the network, we found that it showed results that we were interested in. It shows the congestion of a road, and can adept the prices of that road depending on how busy it is. As this is better than what we got from the MaxFlow algorithm, we decided to swap to this dynamic pricing system.

Software

One of our deliverables is the software which implements all above requirements and incorporates all aspects that we identified are important to our stakeholders. This means that there are four levels implemented by the software, each of which shows different information or is based on a different algorithm.

The following shows the homepage of the software, which allows a level selection and shows a map of the road network.

Level 1 shows just the detected congestion areas, based on the number of times the road is congested. The sensitivity can be modified, which is used like a threshold. If it is higher, there will be less congested roads detected, while if it is lower, more congested roads are congested:

In level 2, this is extended with a static price, based on the number of times the road is congested. The base price is the price that the road gets if it was congested 100% of the time:

The next image shows level 3 of the software, which includes a simulation and shows the relative pricing of toll roads on the map.

From the same page, the actual prices can also be reviewed:

Level 4 also takes into account fairness aspects. For example, the income level of various neighbourhoods can be shown on the map to evaluate impact per neighbourhood:

Final data and software download

[13]

Presentation: [14]