Cooperative Route Guidance - A Simulation Study for Stockholm

(1)

Delft University of Technology

Cooperative Route Guidance - A Simulation Study for Stockholm

Taale, Henk

Publication date

2020

Document Version

Final published version

Citation (APA)

Taale, H. (2020). Cooperative Route Guidance - A Simulation Study for Stockholm. Delft University of

Technology.

Important note

To cite this publication, please use the final published version (if applicable).

Please check the document version above.

Copyright

Other than for strictly personal use, it is not permitted to download, forward or distribute the text or part of it, without the consent of the author(s) and/or copyright holder(s), unless the work is under an open content license such as Creative Commons. Takedown policy

Please contact us and provide details if you believe this document breaches copyrights. We will remove access to the work immediately and investigate your claim.

This work is downloaded from Delft University of Technology.

(2)

Cooperative Route

Guidance

A Simulation Study

for Stockholm

Henk Taale

Final Report

January 31st, 2020

(3)

(4)

1

Introduction

Due to a recovering economic situation, the last couple of years showed a continuous growth in traffic de-mand in most European countries and the accompanying problems such as congestion, decreasing safety and worsening environmental conditions, especially in urban areas. In the past decades, traffic control and management have been successful in improving traffic conditions and reducing travel time variability. Never-theless, due to increasing travel demands the current system is running against its performance boundaries, and innovative approaches are needed to improve the situation. Much is expected from connectivity between vehicles (V2V) and between vehicles and the infrastructure (V2I). This is supposed to enable drivers to look further ahead and provide them with information tailored to their needs. It is assumed that if this kind of information, and the way it is presented, is adjusted to the needs of individual drivers, they will use this infor-mation to make better decisions and thus making the effects of (traffic management) measures on e.g. travel time, safety and emissions larger (Wilmink et al., 2014).

However, it is still not very clear what the effects will be if drivers are provided with information tuned for their situation. Will drivers use this information and under what circumstances? How will they react to the information and will they follow the advice given or will they make their own choice? What happens if dif-ferent service providers give difdif-ferent travel details to the same user? And what is the role of the government in providing information? And how to make sure that government policy goals are met, given the fact that driver information will come from the private sector? These are all relevant questions for which answers are not readily available.

1.1. SOCRATES

The European project SOCRATES2.0 aims at bringing together road authorities, service providers and car manufacturers, with the purpose to discuss and set standards for sharing and integrating traffic informa-tion. The project is based on an initiative to agree on a set of common interfaces, principles and business models to facilitate the exchange of data between vehicles and traffic management centers. They call it Traf-fic Management 2.0 (SOCRATES2.0, 2019c). Traditional traffic management (the 1.0 version) does not have a connection with vehicles on the road and does not address individual vehicles or road users. And there is a separation between traffic information provided by the traffic management centres and private service providers. The TM2.0 concept aims to merge these separated worlds (SOCRATES2.0, 2018a). And this goal is to be reached by specifying interfaces and exchanging data between TMC’s and service providers. The idea is that this will be beneficial for all stakeholders involved. Traffic managers are better able to reach policy goals, road users have a more faster and reliable journey and service providers are a reliable source for travellers, giving the best advice possible.

To test this principle a number of different use case was defined (SOCRATES2.0, 2018a). In these cases the cooperation between stakeholders should lead to an improved situation. The first use case is smart routing. The idea is that road authorities and private companies should work together to provide road users not with a route that is good for the individual user or fleet owner only, but also good for the network as a whole in terms of reduction of congestion or emissions and improvement of safety. Another use case deals with speed and lane advice. Advice for speed or lane could be given by road-side (road authority) or in-car equipment (service providers) and these two sources should be aligned. The third use case is about warning road users on local

(7)

2 1. Introduction

and potentially dangerous situations, such as road works, road condition and environmental restrictions. For the testing of the TM2.0 concept for the different use case, four pilot sites were selected: Amsterdam, Copenhagen, Munich and Antwerp (SOCRATES2.0, 2018b). For example, in Munich the ’smart destination’ service is tested. Road users who visit events in the city’s large event locations (Allianz Arena and the Munich Trade Fair) receive route guidance to the event location and the best parking location (SOCRATES2.0, 2019a). And in Antwerp a ’smart tunnel service’ will be tested on the Antwerp ring road, aiming at a better distribution of traffic among the two tunnels (the Kennedy and Liefkenshoek tunnel), in order to reduce traffic jams near the Kennedy Tunnel (SOCRATES2.0, 2019b).

In the Amsterdam pilot the concept of ’smart routing’ is tested. The idea is to get a better distribution of traffic across the roads in in urban network. When congestion is about to happen, road users are offered an al-ternative route. At this moment route advice is based on avoiding existing queues (reactive), but a pro-active approach should lead to a better use of the total network. However, this requires a prediction of the onset and duration of congestion, something which is not easy to obtain. It also requires cooperation between the traffic management centres and services providers. In Amsterdam this cooperation is organised in a strategic partnership (Vlemmings et al., 2019).

1.2. Route guidance Stockholm

The Swedish Transport Administration (STA) is interested to explore if collaborative traffic management and services such as smart routing could be implemented in a Swedish setting. Especially, they are interested in the impact on the network of the integration between traffic management and traffic information and the impact of coordination between the different stakeholders. This is very relevant in case of tunnel closures. Currently, tunnel entrances are closed regularly during peak hours, because of congestion in the tunnel, and drivers are rerouted. This happens 1 to 2 times a week. At this moment information is provided with variable message signs (VMS), traffic information on the radio and through traffic information services. Sometimes this leads to contradictory information, as shown in figure 1.1.

3

Snapshots

Figure 1.1: Information provided after a tunnel closure

In the top left corner the situation is shown as presented by the website trafiken.nu. In the sub-figure it is shown that two tunnel entrances are closed and that drivers are warned with VMS’s. The other sub-figures show the information shown by service providers. They are unaware of the closures and still direct traffic through the closed tunnel. This kind of situation is undesirable and can be avoided if traffic management and traffic information services are more integrated. To investigate the possibilities of this integration, RISE

(8)

1.3. Research approach 3

Viktoria (with STA as the sponsor) asked Delft University of Technology to carry out a simulation study on the impact of different levels of route guidance on the network performance.

1.3. Research approach

The impact of different levels of integration of route guidance and traffic management for the road users and network performance in the Stockholm area is investigated with a dynamic traffic assignment and simulation model. In general, a traffic simulation study contains a number of general steps, which are the same for every study. Normally, the following steps can be distinguished:

• Choose a suitable traffic model, • Prepare the input for the model,

• Calibrate the model for the situation at hand, • Define and develop the scenarios to be simulated, • Implement the scenarios in the traffic model, • Simulate the scenarios and analyse the results, • Report the study.

1.4. This report

This report contains a description of the steps taken in this study. It starts with with a description of the model used and how the input data for the model was processed. The following chapters deal with calibration of the model, the description and simulation of scenarios and the results and conclusions.

(9)

(10)

2

Model choice and data processing

In this chapter the choice of a model is underpinned, a description of the model used is given and the steps taken to prepare the input data are explained.

2.1. Choose the model

For this study the dynamic traffic assignment model MARPLE is chosen, because of its applicability for this study and its availability at Delft University of Technology. The model is suitable for the study at hand and if needed adjustments in functionality can be made fast and easily. This makes the process more efficient and the organisation of the project less complicated. In the following a description of the MARPLE model is given.

2.2. MARPLE

MARPLE stands for Model for Assignment and Regional Policy Evaluation and is a so-called dynamic traffic assignment model. This type of model calculates the distribution of traffic in the network and the resulting traffic flows and accompanying indicators, such as travel times, total distance travelled, total time spent, etc. The structure of the assignment approach and its separate parts is shown in Figure 2.1.

Rijkswaterstaat

Modelstructure

Route set generation model Dynamic route choice model Dynamic network loading model

route flows travel times routes

travel demand transportation

network

Dienst Verkeer en Scheepvaart 15 november 2011

Figure 2.1: Structure of a dynamic traffic assignment model

MARPLE works with a fixed set of routes for every OD pair, which are generated at the start of the simu-lation using a Monte Carlo approach. In this approach the link travel times are varied randomly, but within a certain bandwidth. Dijkstra’s algorithm (Dijkstra, 1959) is used to calculate the shortest paths for every ran-dom variation. The resulting paths are compared with the existing paths in the set and if sufficiently different, they are added to the set.

To distribute the traffic demand over the available routes for all modelled periods, a dynamic route choice model is needed. For this, the stochastic assignment approach is used. It is assumed that the travel costs have an error term that is independently and identically distributed and with a certain distribution it leads to the multinomial logit (MNL) model (Sheffi, 1985). This model calculates the probability that a certain route is

(11)

6 2. Model choice and data processing

chosen, dependent on the time periode. The MNL-model has a problem with overlapping routes and several solutions have been proposed to overcome this. In MARPLE, the C-logit model (Cascetta et al., 1996) is used in the stochastic dynamic traffic assignment assignment procedure. Eventually, this results in route flows, which are used to calculate the route travel times using a dynamic network loading model.

In the dynamic network loading (DNL) model traffic demand is put on the network at the origins using a demand profile, which can be step-wise or more fluent. Traffic is propagated through the network using travel time functions. These functions are standard functions derived from literature and different functions are used for different link types: normal links (Akçelik, 1991, 2003), controlled links (TRANSPORTATION RE-SEARCH BOARD, 2000), roundabout link (Wu, 2001) and priority links (Wu, 2001). At decision nodes, the traffic is distributed among the outgoing links according to the splitting rates determined by the route flows and taking into account the travel time needed to reach this node. Before traffic enters a link, it is checked if this link has enough space. If this is not the case traffic is held back on the upstream link, so blocking back is modelled. If there are more than one upstream links, the queue is divided over these links according to the number of lanes. The link travel times are used to calculate the route travel times, which on their turn are again input for the dynamic route choice model.

Every traffic assignment model assumes that traffic is in some sort of equilibrium and that can be a deter-ministic or a stochastic one. Both types of equilibria are found using an iterative solution procedure for the process shown in Figure 2.1. For an assignment to come to an equilibrium, the solution for a certain iteration is combined with the solution from the previous iteration using a smoothing factor. For the assignment in MARPLE, a dynamic adjusted smoothing factor gives the best convergence properties (Taale and Pel, 2015). To determine if equilibrium is reached a convergence criterion is used. MARPLE uses the maximum differ-ence (over OD-pairs and time periods) between the route flows of two iterations. This error can be considered as the maximum shift in flow from one route to another. More details on the model and the steps taken, can be found in Taale (2008).

2.3. Prepare input data

For the MARPLE model, input data is needed. The input consists of a network with links and nodes and their characteristics, an origin-destination matrix (OD-matrix) with the (dynamic) traffic demand and more general input, such as the length of the simulation period, etc. For this study the data comes from an existing model, a TransModeler application of the Stockholm region. TransModeler is a traffic simulation package from the Caliper Cooperation (CALIPER COOPERATION, 2020) and it can simulate all kinds of road networks. It has a good integration with GIS and is most used for prioritising projects for transportation improvement programs. For the Stockholm region a TransModeler implementation was available (see figure 2.2a). From this implementation a part of the network was exported in CSV and GIS files to use in the study and as a basis for MARPLE (see figure 2.2b).

2.3.1. Network conversion

A TransModeler network is quite different from a MARPLE network. It has a different structure, consisting of nodes, links, segments, lanes, lane connectors, centroids and centroid connectors (Larek, 2019). Nodes and links are also part of a MARPLE network, but other aspects are different. TransModeler uses the concept of zones (centroids) to define areas where traffic originates from and were it travels to. In MARPLE zones are split into origins and destinations, which are nodes of a certain type. Also, in a TransModeler network links with two directions are possible, which is not the case in MARPLE. And, instead of lanes as a separate entity, in MARPLE lanes are an attribute of a link, just as the length of the link, the saturation flow (capacity), the maximum speed and the link type (normal, controlled, roundabout or priority).

The difference in network structure of the TransModeler network compared with MARPLE demanded a conversion. For this a special script was written in MATLAB. The first part of this script is shown in appendix A. After reading the input files, the script passes through the following steps:

• Determine the number of nodes and read the node information. This information consists of the node number, the number of incoming and outgoing links, the ID’s of these links and the node type (normal, signal controlled, roundabout, etc.

• Determine the number of centroids and read the centroid information. Split the centroids into origins and destinations and give them new numbers. Due to the network selection some normal nodes were converted into centroids. So they also needed to be split into an origin and destination.

(12)

2.3. Prepare input data 7

(a) Original TransModeler network (b) Network part used for MARPLE

Figure 2.2: The Stockholm network

• Determine the number of links and read the link information. Determine the number of two-way links and split them into two links. For all links determine the link type, the number of lanes, the saturation flow and free speed.

• Read the segment information and if needed correct the number of lanes and saturation flow for the links these segments belong to.

• Connect the centroids to nodes instead of links and give the connecting links certain properties. • Check for looping links, double links, obsolete links and obsolete nodes and remove them from the set. • Detect and change the link type based on the node type for signal controlled intersections and

round-abouts. And determine default signal plans for the signal controller intersections. • Read and process the demand information from the OD matrices.

• Write the link, node, origin and destination and demand information in the MARPLE network input file.

The output of the script is a network file for the MARPLE model and a log file with information on the steps taken. Appendix B gives an example of such a log file. Important results of the conversion script are that the number of links, after splitting two-way links and connecting centroids, increases from 12,667 to 25,081. Due to the cleaning steps the number of links decreases to 24,666. In the original model there were 10,177 nodes and 867 centroids. Splitting centroids into origin and destination nodes led to 11,931 nodes. Discarding 1 node without connection left 11,930 nodes in the MARPLE network. Between these almost 12,000 nodes there are 122 signalled controlled intersections and 789 roundabout nodes.

The way roundabouts were coded in the original network gave some problems, because in a MARPLE net-work a roundabout is one node and incoming arms give priority to other arms. In the TransModeler netnet-work most roundabouts have several nodes and small links in between, as shown in figure 2.3. To prevent that traffic on the roundabout also has to give priority, some links on the roundabout are defined as normal links, others as links that get priority and links entering the roundabout are the links that have to give priority (see the arrows in figure 2.3.

2.3.2. Traffic demand

Fortunately, the information contained in the files with the OD matrices had almost the same structure as used in the MARPLE input files. For the TransModeler network two OD matrices were available: one for person cars and one for trucks. Although MARPLE can handle both car types, to make the study not too

(13)

8 2. Model choice and data processing

Figure 2.3: Giving priority on a roundabout

complex and to keep calculation time manageable, it was decided to merge these matrices into one. For this a PCU value of 1.5 for trucks was used.

The original OD matrix contained demand data for the period from 04.00 to 11.00 hrs. for every quarter of an hour. In total there were 110,656 OD pairs with a demand and 479 obsolete OD pairs. The total number of trips in the matrix was 467,261. To focus on the peak period, the period for the converted OD matrix was taken from 06.00 to 10.00 hrs., which gives 16 periods of 15 minutes. In this period there are 372,678 trips, which is about 80% of the original demand.

2.3.3. Network issues

The first runs of the converted model revealed some issues with the network. The route generation process could not be completed and it appeared that a small part of the network was not connected. This is shown in figure 2.4. The problem was solved with adding to links to make the network connected again.

Figure 2.4: The disconnected part of the network

Another issue involved congestion in a zone. The connecting downstream links were congested and traffic was not able to leave the origin indicated with the blue arrow in figure 2.5. The issue was solved by checking the bottlenecks. It was found that the roundabout, indicated with the red arrow, had not enough lanes in the model. After fixing this, there was still a little bit of congestion in the zone, but much less than before and it also dissolves during the simulation, which was not the case originally.

(14)

2.3. Prepare input data 9

(15)

(16)

3

Calibration

For the calibration of the model use could be made of measurement data provided by RISE Viktoria. The data consisted of flows and speeds, measured with loop detectors. The location of the loops is shown in figure 3.1. The figure does not display all locations with measurements, because the study focusses on the Södra Länken, the southern link, running from east to west in the figure. This part of the Stockholm ring road is the urban motorway 75 and it is about 6 kilometres long. It includes a tunnel with a length of 4.5 kilometres.

For the calibration the measurement data was processed and simulations were run to compare output with measurements and to adjust network and simulation parameters.

Figure 3.1: Measuring locations in the network

3.1. Processing of the measured data

The data was supplied for two months: November 2018 and May 2019. After inspection, the data of May 2019 was used, because for some locations the data of November 2018 was missing. A MATLAB routine was written to process the data and calculate average profiles for flow and speed for every measuring location and for working days and weekend days (see appendix C). Because the data was in a 1-minute format it was aggregated to 15 minutes and a selection for the morning peak (06.00 tot 10.00 hrs.) was made. Now the data could be used to calibrate the demand.

3.2. Calibration of the demand

For the calibration of the demand only the traffic on Södra Länken westbound (75W) and three major con-necting roads (73, 226 and E4.25) was considered. The reason is that this is the direction for which in the morning peak tunnel entrances are closed. A first run revealed that the urban motorway was not congested enough, as becomes visible in the speed contour plots in figure 3.2. On the left the measurements and on the right the result of the simulation are shown.

(17)

12 3. Calibration

Figure 3.2: Measured and simulated (first run) speed contour plot for May 2019

Therefore, we started with the most downstream bottleneck location of the measurements, and checked if this location had no additional lanes due to diverging or merging traffic, so only of the main carriageway (lo-cation 1 in figure 3.3). The simulated total flow (summed for the whole period) on that link was analysed and compared with the measured total flow. With a selected link analysis the difference was corrected by increas-ing or decreasincreas-ing the OD pairs that use this link, with a percentage of the total flow. As a consequence the flow profile over the simulated period was not changed. This would require a far more detailed OD estimation procedure, which was not feasible for this study.

After the correction, the other locations shown in figure 3.3 were checked to see if they fitted the mea-surements. Then the location with the largest difference was selected and corrected using the same method (selected link analysis and increasing or decreasing the OD pairs involved).

Figure 3.3: Measuring locations for the calibration

In the end only the locations with the red square were selected to be corrected. For the other ones the differences were smaller or they were strongly related to the others. The result for the total flows after 14 iterations of this procedure is given in table 3.1. The only locations that showed no improved are location 3 and to a lesser extent location 4. However, attempts to correct these location and decrease the difference failed due to the influence on other locations. Location 8 is a deviating one, because the direction is not towards road 75, northbound, but southbound. For the northbound direction the measurements were not complete, therefore the southbound direction was chosen.

As mentioned before only the total flow was corrected and not the flow profile. How this works out, is shown in figure 3.4, which gives the flow and speed profile for locations 1, 3 and 7. For location 1 the calibrated flows and speeds resemble the measurements sufficiently. For location 3 the calibrated flows are still larger than the measured ones, but the speed profile gives a good similarity. The same holds for location 7, although

(18)

3.2. Calibration of the demand 13

Table 3.1: Calibration of total flows

Location Detection Measured Simulated Perc. Simulated Perc. number loop ID flow flow before before flow after after 1 E75W 1.270 10268.5 7173.6 70% 9649.3 94% 2 E75W 1.960 12369,7 10855,4 88% 13178,4 107% 3 E75W 3.270 10116,7 12632,0 125% 15015,7 148% 4 E75W 3.935 6221,7 4157,0 67% 6592,3 106% 5 E75W 4.795 7408,1 6197,1 84% 8883,6 120% 6 E75W 5.720 9622,7 7059,6 73% 9771,4 102% 7 E75W 6.025 6461,5 4269,3 66% 5677,5 88% 8 E226Z 22.915 3178,8 2230,3 70% 2660,0 84% 9 E73G 53.400 3997,2 5970,3 149% 5124,0 128% 10 E73N 52.050 11578,1 10254,3 89% 10193,0 88% 11 E425Z 53.725 3651,8 7505,0 206% 4585,1 126%

(19)

14 3. Calibration

the flow profile is quite different. The graphs for the other locations are included in appendix D.

During the process it was found that also some changes had to be made to the network. This consisted of adjustments to the saturation flow of some links and the number of lanes and speed of another one.

3.3. Result of the calibration

The speed contour plots for the measurements and the output of the final calibration iteration are shown in figure 3.5. As can be seen the amount of congestion in the simulation has increased a lot and is almost similar to the measurements, although it is more spread in time and less in space.

Figure 3.5: Measured and simulated (final run) speed contour plot for May 2019

It can be concluded that the results of the calibration are acceptable and useful for the purpose of the study. Of course it can still be improved a lot, but the goal is not to represent the current situation as close as possible, but to come to a situation in which route guidance could play a significant role.

(20)

4

Scenarios and results

In this chapter the scenarios are defined and the assumptions to implement these scenarios into the model are described. After that the results of the simulations are presented.

4.1. Scenarios

The study investigates the impact of route guidance on traffic flows on the network if entrances to the tunnel in the Södra Länken are closed due to congestion in the tunnel. The most common situation is that about 07.15 hrs. the entrances are closed for half an hour on average. In most of the occurrences two entrances are closed and the corresponding links are marked red in figure 4.1.

Figure 4.1: Closed entrances to the tunnel

For this situation the following scenarios were analysed: 1. Current situation, normal information level,

2. Scenario with tunnel closure, no change in route choice, 3. Scenario with tunnel closure, no information,

4. Scenario with tunnel closure and road-side information available (no advice),

5. Scenario with tunnel closure and road-side information available (advice on detours), 6. Scenario with tunnel closure and better in-car information available separately, 7. Scenario with complete information for users with navigation tools,

8. Scenario with complete information for all users. 15

(21)

16 4. Scenarios and results

Scenario 1 represents the current situation with normal traffic, no tunnel closure and no extra informa-tion. In scenario 2 the tunnel is closed, but traffic behaves as usual. This is a kind of worst case scenario. In scenario 3 traffic reacts in the normal way to the tunnel closure, but without external information. So, ev-erybody makes his/her own choice. VMS’s are used in scenario 4, but they only give information about the situation. This represents the current situation if the tunnel is closed. Scenario 5 is the same as 4, but now the VMS’s give routing advice. In scenario 6 part of the road users receive extra information and a personal route advice via an in-car information service. For scenario 7 this information is improved for users with mobile devices and in scenario 8 all users receive the best information possible.

In a number of scenarios VMS’s are used to provide road users with information. Stockholm has various VMS’s available (see www.trafiken.nu/stockholm), but only 4 of them are relevant for the study and used in the simulations. They are shown in figure 4.2 with a blue circle.

Figure 4.2: VMS’s used for the simulations

4.2. Assumptions

MARPLE distinguishes between several user classes, which have a different level of user information. The first class does not use any route information. They are the habitual drivers who always take the same route whatever happens. The second user class uses route information on the radio, which comes at certain time slots, but also directly if urgent situations occur. The third user class uses the information from removable or on-board navigation systems, which give them individual route advice. And the fourth class also gets individual route advice, but now from a mobile device (e.g. smartphone). The distribution over the types of users is not known for Stockholm. Therefore, information from a recent study from the Netherlands is used (Haaier et al., 2019). This study concludes that 26% of the road users are habitual drivers, 14% uses radio information only, 33% uses navigation devices and 27% uses smartphones to navigate. These percentages are used for all scenarios, except for scenario 8 in which all drivers use a navigation device or smartphone.

The level of information is controlled by theθ parameter in MARPLE. This parameter influences route choice behaviour. The default value of this parameter is 1.0 (Taale, 2008), but changes for different situations and different user classes.

The closure of the tunnel entrances is simulated with a so-called ’event’. During this event the saturation flow and the number of lanes of the corresponding links are set to zero. So, no traffic can enter this link. To simulate the impact of this event and route guidance, MARPLE deals with this in the following way. First an equilibrium assignment is done (representing the normal situation), then an extra simulation with the event is run to determine the effect of the closure and after that an extra assignment is done for the traffic which uses information on the VMS’s or other information sources. This assignment can have 1 or more iterations, which is varied in the scenarios. Also the VMS’s can give extra information, for example route advice instead

(22)

4.3. Simulation results 17

of route information. This is simulated with an increase of the information parameterθ.

An overview of the relevant simulation parameters for the different scenarios is given in table 4.1. The scenarios have an increase in information availability, in quality of information and in a stronger response to this information.

Table 4.1: Parameters used in the different scenarios

User class parameters Event parameters VMS parameters Percentage θ

Scenario 1 2 3 4 1 2 3 4 present assignment # iterations present extra info

1 26 14 33 27 0 1 1 1 no no 0 no no

2 26 14 33 27 0 1 1 1 yes no 0 no no

3 26 14 33 27 0 1 1 1 yes yes 0 no no

4 26 14 33 27 0 1 1 1 yes yes 1 yes no

5 26 14 33 27 0 1 1 1 yes yes 1 yes yes

6 26 14 33 27 0 1 2 2 yes yes 10 yes yes

7 26 14 33 27 0 1 10 10 yes yes 10 yes yes

8 0 0 50 50 0 1 10 10 yes yes 10 yes yes

To run the simulations, first a set of routes is generated. It is assumed that the maximum number of routes per OD pair is 5 (Taale and Pel, 2019). Then an equilibrium assignment is run, for which the convergence error is set to 5%. This means that for all OD pairs no more than 5% of the traffic shifts from one route to another in the equilibrium situation. For all scenarios this led to 10 to 14 iterations. Dependent on the parameters given in 4.1, an extra simulation is run and 0 to 10 extra iterations with different information parameters are calculated.

4.3. Simulation results

To show the impact of the incident on the congestion pattern on Södra Länken, a speed contour plot was generated for scenario 2, shown in figure 4.3. The closure of the tunnel entrances is clearly visible from 07.15 hrs. onwards and somewhat later downstream (traffic is travelling from bottom to top).

Figure 4.3: Speed contour plot for scenario 2

The MARPLE model produces results in terms of flows on links, travel times on routes and network indi-cators, such as the total distance travelled and the total time spent. For this study the network indicators total distance travelled and total delay are chosen. The total distance travelled is the number of vehicle kilometres in the network and route information influences this indicator. Total delay is the delay all users experience in the network, relative to the maximum speed. We present these indicators for the whole network and for Södra Länken (both directions) in table 4.2 and figure 4.4. For the comparison of the results we take scenario 3 as the base scenario, because we want to estimate the impact of route information. And in scenario 3, if the tunnel entrances are closed, drivers will try to find their own and choose the route which they think is best for them, based on their experience.

(23)

18 4. Scenarios and results

Table 4.2: Results for the scenarios

Network Södra Länken

Distance Travelled Total Delay Distance Travelled Total Delay (veh.kms) (veh.hrs) (veh.kms) veh.hrs 1 4418918 100.3% 25905 95.5% 107675 98.7% 684 108.3% 2 4374809 99.3% 26417 97.4% 102523 94.0% 416 65.9% 3 4405133 100.0% 27112 100.0% 109103 100.0% 631 100.0% 4 4373540 99.3% 25103 92.6% 105963 97.1% 664 105.2% 5 4373944 99.3% 25255 93.2% 106798 97.9% 682 108.0% 6 4388971 99.6% 23872 88.0% 104386 95.7% 570 90.3% 7 4366726 99.1% 22440 82.8% 104617 95.9% 524 82.9% 8 4340200 98.5% 22261 82.1% 104014 95.3% 556 88.1% 0% 20% 40% 60% 80% 100% 120% 1 2 3 4 5 6 7 8 Network Södra Länken

Figure 4.4: Results for the total delay, relative to scenario 3

From the table and the figure it is clear that the closure of the tunnel entrances causes extra delay in the network. The increase for the whole network is about 500 veh.hrs (2%), while on the Södra Länken less delay is experienced (39%), because less traffic enters the motorway. It is remarkable that in scenario 3 the delay is even larger: about 1,200 veh.hrs extra delay (5%), compared to scenario 1. That is due to the fact that the traffic changes route and finds its own way, probably shifting to already busy roads.

There are not much changes to the total distance travelled in the whole network. The differences remain within 1%, except for scenario 8, where it is 1.5%. Differences are larger for the Södra Länken, but that is due to the closure. However, there is an effect of giving route information on the use of this urban motorway (about 3%-5%).

Giving route information with VMS’s has impact. Compared with scenario 3, the total delay in the network decreases with about 2,000 veh.hrs (7%). For Södra Länken the delay increases a bit and this is also due to the route information. Traffic chooses the old route again based on the information given. Given a route advice (scenario 5) does not make a large difference. Delays are a little bit higher, but not much (1%).

In scenario 6 the quality of the information for the users of navigation systems and mobile devices is better and this leads to less delay in the network (about 3,250 veh.hrs, 12%) and on Södra Länken (about 60 veh.hrs, 10%) compared with scenario 3. Compared with the current situation (scenario 4) the total delay in the network decreases with about 1,200 veh.hrs (5%).

With the best information for users of navigation tools (scenario 7), the delay decreases even more. For the whole network that is about 4,700 veh.hrs (17%) and for Södra Länken about 100 veh.hrs (17%), com-pared with the no information scenario. Comcom-pared with the current situation the improvement is about 2,700 veh.hrs (11%) less delay.

If all road users get personal information and the best route advice for the system, the delay is about 4,850 veh.hrs smaller (18%) than in scenario 3, where everybody choose his/her own route, and 2,850 veh.hrs (11%)

(24)

4.4. Some remarks 19

smaller than in scenario 4(the current situation). For Södra Länken the delay increases somewhat, but it is still less than in scenario 3 (75 veh.hrs, 12%) or scenario 4 (100 veh.hrs, 16%).

4.4. Some remarks

The results presented in paragraph 4.3 are based on a number of assumptions, discussed in paragraph 4.2. One of the assumptions is the duration of the closure. If this duration is increased from 30 minutes to 45 and 60 minutes, the results and the conclusions do not change.

Other assumptions and values for corresponding parameters are based on literature or set to the author’s best knowledge. An important parameter is the information parameterθ for which the values are presented in table 4.1. The general value of this parameter and the impact of route information is estimated by the author, only marginally supported by the literature (Van der Mede and Van Berkum, 1993).

(25)

(26)

5

Conclusions and recommendations

5.1. Conclusions

It can be concluded that route guidance is very important in case of the closure of a tunnel or other incidents. In this study we investigated the closure of two entrances to the Södra Länken (southern link) urban motor-way in Stockholm, which includes a tunnel stretch. The tunnel is temporarily closed due to congestion and if that is the case traffic is redirected.

If no information is given, drivers will try to find their own way and this is not the best option for the network as a whole. More still, it is worse than the impact of the tunnel closure itself (3% extra delay). Giving information with variable message signs already improves the situation a lot (7% less delay), but informing road user personally and giving them a good route advice using navigation systems or mobile devices is even better. The total delay decreases with an extra 5% (12% in total). Improving the information also helps a lot. The best information for the group of users with navigation devices (about 60%) of the traffic) gives in total 17% less delay than the situation without giving information and 11% less delay compared with the situation with information on VMS’s. And giving this information to all users, instead of a certain group, improves the performance of the network with another 1% less delay.

So the conclusion is that giving information is always better than no information and personalised infor-mation is even better. The best situation appears when everybody gets advice based on the traffic conditions in the whole network.

5.2. Recommendations

As stated in the conclusions, in this study a lot of assumptions has been made, both in the modelling part as in the specification of the scenarios. It would be interesting to see what the sensitivity of all these assumptions is on the outcome of the study. For example, we assumed equal quality of information for different services. Also the improvement in information quality we assumed to be equal. Would the conclusions become different if we assume that the quality of information is different for the different service providers? Will the situation become worse as we expect?

Also the sensitivity of the information parameter could be investigated. The results depend a lot on its value, but how this will affect the outcome is not clear.

A final topic to study further would be the locations of the closure. Now, two entrances have been closed, based on what happens in reality. But what would happen if other entrances are closed and what would be the impact of route information under those circumstances?

Because these topics are relevant for our knowledge on the impact of route guidance, it is recommended to start a follow-up study, including further research on scenario parameters and running simulations to determine the sensitivity of the outcome to important model and scenario parameters.

(27)

(28)

Bibliography

Akçelik, R. (1991). Travel Time Functions for Transport Planning Purposes: Davidson’s Function, its Time-Dependent Form and an Alternative Travel Time Function. Australian Road Research, Vol. 21, No. 3, pp. 49–59. Minor revisions: December 2000.

Akçelik, R. (2003). Speed-Flow Models for Uninterrupted Traffic Facilities. Technical Report, Akcelik and As-sociates Pty Ltd, Melbourne, Australia.

CALIPER COOPERATION (2020). TransModeler Traffic Simulation Software. URL: https://www.caliper.com/ transmodeler/default.htm. Accessed on January 13th, 2020.

Cascetta, E., A. Nuzzolo, F. Russo and A. Vitetta (1996). A Modified Logit Route Choice Model Overcoming Path Overlapping Problems: Specification and some Calibration Results for Interurban Networks. Proceedings

of the 13th International Symposium on Transportation and Traffic Theory, pp. 697–711. Lyon, France.

Dijkstra, E. W. (1959). A note on two problems in connexion with graphs. Numerische Mathematik, Vol. 1, pp. 269–271.

Haaier, M.E., W. Quite and A.J. Maaskant (2019). Monitoring Road Traffic Related Information Services and

Advanced Driver Assistance Systems 2018. Report for Rijkswaterstaat, MuConsult. (in Dutch).

Larek, P. (2019). Stockholm TransModeler Network Export. Report for RISE, WSP Advisory, Stockholm, Sweden. Sheffi, Y. (1985). Urban Transportation Networks: Equilibrium Analysis with Mathematical Programming

Methods. Prentice-Hall, Englewood Cliffs, N.J., U.S.A.

SOCRATES2.0(2018a). Proposed Cooperation Framework and Bottlenecks. Technical Report, SOCRATES2.0 Deliverable Activity 2.

SOCRATES2.0(2018b). Setting the Stage for Deployment of Interactive Traffic Management. Technical Report, SOCRATES2.0Deliverable Acitvity 3.

SOCRATES2.0(2019a). Munich: smooth journey experience in case of events. URL: https://socrates2.org/ news-agenda/news/close-munich-smooth-journey-experience-case-events. Accessed on December 4th, 2019.

SOCRATES2.0(2019b). Test with smart traffic flows on the Antwerp ring road. URL: https://socrates2.org/ news-agenda/news/test-smart-traffic-flows-antwerp-ring-road. Accessed on December 4th, 2019. SOCRATES2.0(2019c). Traffic Management 2.0. URL: http://tm20.org/. Accessed on February 20th, 2019. Taale, H. (2008). Integrated Anticipatory Control of Road Networks: A Game Theoretical Approach. Phd thesis,

Delft University of Technology, Delft, The Netherlands.

Taale, H. and A. Pel (2015). Better Convergence for Dynamic Traffic Assignment Methods. Transportation

Research Procedia, Vol. 10, pp. 197–206.

Taale, H. and A. Pel (2019). Route Set Generation for Quick Scan Applications of Dynamic Traffic Assignment.

Proceedings of the 6th International Conference on Models and Technologies for Intelligent Transportation Systems (MT-ITS). IEEE, Cracow, Poland.

TRANSPORTATION RESEARCH BOARD (2000). Highway Capacity Manual. Technical Report, National Re-search Council, Washington D.C., USA.

Van der Mede, P.H.J. and E.C. van Berkum (1993). The Impact of Traffic Information: Dynamics in Route and

Departure Time Choice. PhD Thesis, Delft University of Technology, Delft.

(29)

24 Bibliography

Vlemmings, T., G. Huisken and P. Deknudt (2019). SOCRATES2.0: Public-Private Cooperation in Traffic Man-agement. NM Magazine, Vol. 14, No. 3, pp. 30–31. (in Dutch).

Wilmink, I., K. Malone, A. Soekroella and H. Schuurman (2014). Coöperatieve Systemen en Automatisch Rijden

- State-of-the-Art achtergronddocument. State-of-the-Art report, TrafficQuest. (in Dutch).

Wu, N. (2001). A Universal Procedure for Capacity Determination at Unsignalized (Priority-Controlled) Inter-sections. Transportation Research Part B, Vol. 35, No. 6, pp. 593–623.

(30)

A

Conversion Script

% ---%

% Module to convert TransModeler input files into MARPLE input %

% last update : 25 -07 -2019

% ---% 2019 -05 -01: programming the module

% 2019 -07 -17: sorting links and nodes on number

% 2019 -07 -17: sorting demand on origin and destination % 2019 -07 -24: including truck demand

% 2019 -07 -25: inlcuding possibility to select part of the OD matrix %

---function [T, Perc ]= ConvertTransModeler ( filestring1 , filestring2 ,...

filestring3 , filestring4 ,...

filestring5 , filestring6 ,...

filestring7 , filestring8 , ConvPar )

% description input variables

% filestring1 : ASCII file with links % filestring2 : ASCII file with segments % filestring3 : ASCII file with nodes

% filestring4 : ASCII file with centroids ( zones )

% filestring5 : ASCII file with centroid connector information % filestring6 : ASCII file with person car OD matrix

% filestring7 : ASCII file with truck OD matrix

% filestring8 : ASCII outputfile with MARPLE network file % ConvPar : a set of parameters , consisting of

% DemandThresHold = 1.0; threshold for OD demand % PCUvalue = 1.5; person car unit for trucks % StartTimeData = '04:00 ' start time of input OD; % EndTimeData = '11:00 ' end time for input OD; % StartTimeSim = '06:30 ' start time for output OD; % EndTimeSim = '10:30 ' end time for output OD;

(31)

26 A. Conversion Script % initialisation version = '1.0 '; maxInLinks = 9; maxOutLinks = 9; DemandThresHold = ConvPar {1}; PCUvalue = ConvPar {2}; StartTimeData = ConvPar {3}; EndTimeData = ConvPar {4}; StartTimeSim = ConvPar {5}; EndTimeSim = ConvPar {6};

set (0,' DefaultFigureVisible ','off ')

Title =' TransModeler Stockholm project ';

Helpstring1 = sprintf ([' TransModeler conversion program ',version ,...

' \ nCopyright ',char (169) ,' 2019 Henk Taale \n\n',Title ]);

fprintf (1,' ---\n');

fprintf (1,' Conversion program for TransModeler to MARPLE \n');

fprintf (1,' The version used is: %s\n',version );

fprintf (1,' Delft University of Technology \n');

fprintf (1,' ---\n');

fprintf (1,'\n');

fprintf (1,'The threshold for the demand is : %6.3 f \n',

DemandThresHold )

fprintf (1,'The value for the person car unit is : %6.3 f \n',PCUvalue

)

% open input file with links

InputFile1 = fopen ( filestring1 ,'r');

if InputFile1 == -1

errorh = errordlg ('The TransModeler input file with links does not

exist !','Error Message '); uiwait ( errorh );

return;

end

% open input file with nodes

if InputFile7 == -1

errorh = errordlg ('The TransModeler input file with segments does not

return;

end

% open input file with nodes

if InputFile2 == -1

errorh = errordlg ('The TransModeler input file with nodes does not

return;

(32)

27

% open input file with centroids

if InputFile3 == -1

errorh = errordlg ('The TransModeler input file with centroids does

not exist !','Error Message '); uiwait ( errorh );

return;

end

% open input file with centroid connectors

if InputFile4 == -1

errorh = errordlg ('The TransModeler input file with centroid

connectors does not exist !','Error Message '); uiwait ( errorh );

return;

end

% opening input file with car OD demand

if InputFile5 == -1

errorh = errordlg ('The TransModeler input file with the car OD matrix

does not exist !','Error Message '); uiwait ( errorh );

return;

end

% opening input file with truck OD demand

if InputFile6 == -1

errorh = errordlg ('The TransModeler input file with the truck OD

matrix does not exist !','Error Message '); uiwait ( errorh );

return;

end

% determining number of nodes

status = fseek ( InputFile2 ,0,'bof ');

frewind ( InputFile2 ) nrNodes =0;

while 1

line = fgetl ( InputFile2 ); nrNodes = nrNodes +1;

eofstat1 = feof ( InputFile2 );

if eofstat1 ==1 , break, end;

end

fprintf (1,'\ nNumber of original model nodes : %6.0 f\n',nrNodes

)

% initialisation of time parameters

LTimePeriod =900; nrTimePeriods =28; LTimeStep =10;

(33)

28 A. Conversion Script

% determining start and end period for simulation

StartDataPeriod = datenum ( StartTimeData ,15) ;

EndDataPeriod = datenum ( EndTimeData ,15) ;

StartSimPeriod = datenum ( StartTimeSim ,15) ;

EndSimPeriod = datenum ( EndTimeSim ,15) ;

if StartSimPeriod > StartDataPeriod

nrStartPeriods = floor (( StartSimPeriod - StartDataPeriod ) *1440/ nrMinutes );

else

nrStartPeriods = 0;

end

if EndSimPeriod < EndDataPeriod

nrEndPeriods = floor (( EndDataPeriod - EndSimPeriod ) *1440/ nrMinutes );

else

nrEndPeriods = 0;

end

StartPeriod = 1+ nrStartPeriods ;

EndPeriod = nrTimePeriods - nrEndPeriods ;

% initialisation node data

NodeNr = zeros ( nrNodes ,1) ;

NodeType = zeros ( nrNodes ,1) ;

nrOut = zeros ( nrNodes ,1) ;

nrIn = zeros ( nrNodes ,1) ;

% reading node information

Help1 = TimebarUK ( Helpstring1 ,'Reading nodes ');

nodetext = textscan ( InputFile2 ,'%f % u32 % u32 % u32 % u32 % u32 %s %s %s %s

%f %s %s','Delimiter ',';',' EmptyValue ',-Inf );

% determining node information for MARPLE

NodeNr = nodetext {1}; NodeX = nodetext {2}; NodeY = nodetext {3}; nrIn = nodetext {4}; nrOut = nodetext {5}; for i =1: nrNodes switch nodetext {10}{ i} case "" NodeType (i) = 0; case " Pretimed " NodeType (i) = 3; case " Actuated " NodeType (i) = 3; case " Roundabout " NodeType (i) = 6; case " Yield " NodeType (i) = 8;

case "1- Way Stop " NodeType (i) = 8;

(34)

29

case "2- Way Stop " NodeType (i) = 8; otherwise NodeType (i) = 0; end if i< nrNodes ishandle ( Help1 ); if ishandle ( Help1 ) ==0 return; else

TimebarUK (Help1 ,i/ nrNodes );

end

elseif i== nrNodes

TimebarUK (Help1 ,i/ nrNodes ) st= close ( Help1 );

end end

maxNodeNr = max ( NodeNr );

% sort nodes

NodeData = [ NodeNr NodeType nrIn nrOut NodeX NodeY ]; NodeData = sortrows ( NodeData );

NodeNr = double ( NodeData (: ,1));

NodeType = NodeData (: ,2);

nrIn = NodeData (: ,3);

nrOut = NodeData (: ,4);

NodeX = NodeData (: ,5);

NodeY = NodeData (: ,6);

% determining number of centroids

nrCentroids =0;

while 1

line = fgetl ( InputFile3 ); nrCentroids = nrCentroids +1; eofstat1 = feof ( InputFile3 );

end

fprintf (1,'Number of original model zones : %6.0 f\n',

nrCentroids )

% reading centroid information

Help1 = TimebarUK ( Helpstring1 ,'Reading centroids ');

frewind ( InputFile3 )

centroidtext = textscan ( InputFile3 ,'% u32 % u32 % u32 %u8 %u8 %u8 %u8 %s',

'Delimiter ',',',' EmptyValue ',-Inf );

CentroidNr = centroidtext {1}; CentroidX = centroidtext {2}; CentroidY = centroidtext {3}; nrOrigins = 0; nrDestinations = 0; nrNode = nrNodes ; maxCentroidNr = 750000;

(35)

30 A. Conversion Script

Destinations = zeros ( nrCentroids ,1) ;

ConvDest = zeros ( nrCentroids ,2) ;

for i =1: nrCentroids

nrNode = nrNode +1;

NodeNr ( nrNode )= CentroidNr (i); NodeX ( nrNode )= CentroidX (i); NodeY ( nrNode )= CentroidY (i); NodeType ( nrNode ) =1;

nrOrigins = nrOrigins +1;

Origins ( nrOrigins )= NodeNr ( nrNode ); nrIn ( nrNode ) =0;

nrOut ( nrNode )= centroidtext {4}( i); nrNode = nrNode +1;

NodeNr ( nrNode )= maxCentroidNr + nrOrigins ; NodeX ( nrNode )= CentroidX (i);

NodeY ( nrNode )= CentroidY (i); NodeType ( nrNode ) =2;

nrDestinations = nrDestinations +1;

Destinations ( nrDestinations )= NodeNr ( nrNode ); ConvDest (i ,:) =[ CentroidNr (i),NodeNr ( nrNode )]; nrIn ( nrNode )= centroidtext {5}( i);

nrOut ( nrNode ) =0; if i< nrCentroids ishandle ( Help1 ); if ishandle ( Help1 ) ==0 return; else

TimebarUK (Help1 ,i/ nrCentroids );

end

elseif i== nrCentroids

TimebarUK (Help1 ,i/ nrCentroids ) st= close ( Help1 );

end end

% write relation zones destination

fcod = fopen (' ZoneConversion . txt ','w');

ZoneData =[ CentroidNr Origins Destinations ]; ZoneData = sortrows ( ZoneData );

fprintf (fcod ,'Zone number Origin number Destination number \n');

for i =1: nrCentroids

fprintf (fcod ,' %8.0 f %8.0 f %8.0 f\n',ZoneData (i

,1) ,ZoneData (i ,2) ,ZoneData (i ,3) );

end

fclose ( fcod );

% increasing number of nodes

nrNodes = nrNode ;

fprintf (1,'Number of nodes after zone splitting : %6.0 f\n',nrNodes )

% determining number of links

(36)

31

while 1

line = fgetl ( InputFile1 ); nrLinks = nrLinks +1;

eofstat1 = feof ( InputFile1 );

end

fprintf (1,'Number of original model links : %6.0 f\n',nrLinks )

% reading link information

linktext = textscan ( InputFile1 ,'%f % u32 %s %s % u32 % u32 %f %f %f %u8 %s

%u8 % u32 %s %s %s %s %s %s','Delimiter ',';',' EmptyValue ',-Inf );

% reading segment information

segmenttext = textscan ( InputFile7 ,'%f % u32 %s %s % u32 % u32 %s %s %s %u8

%u %u8 ','Delimiter ',';',' EmptyValue ',-Inf );

% determining link information for MARPLE

Help1 = TimebarUK ( Helpstring1 ,'Reading links ');

% counting number of two - way links

Direction = linktext {2};

nTwoWayLinks = length ( find ( Direction ==0) );

% initialising link matrices

LinkNr = zeros ( nrLinks + nTwoWayLinks ,1) ;

Length = zeros ( nrLinks + nTwoWayLinks ,1) ;

NodeOut = zeros ( nrLinks + nTwoWayLinks ,1) ;

NodeIn = zeros ( nrLinks + nTwoWayLinks ,1) ;

NetType = zeros ( nrLinks + nTwoWayLinks ,1) ;

NrLanes = zeros ( nrLinks + nTwoWayLinks ,1) ;

SatFlow = zeros ( nrLinks + nTwoWayLinks ,1) ;

FreeSpeed = zeros ( nrLinks + nTwoWayLinks ,1) ;

RoadType = zeros ( nrLinks + nTwoWayLinks ,1) ;

LinkConv = zeros ( nTwoWayLinks ,2) ;

% initialising segment matrices

LinkSNr = segmenttext {5};

NrLanesAB = segmenttext {10};

NrLanesBA = segmenttext {11};

% filling matrices with information known

% in the first delivery length is given in miles and length in MARPLE is in

% meters with a minimum of 20

% in the second delivery length was in metres

LinkNr (1: nrLinks ) = linktext {1};

% Length (1: nrLinks ) = max (20 ,1609.34* linktext {7}) ;

Length (1: nrLinks ) = max (20 ,1000* linktext {7}) ;

NodeOut (1: nrLinks ) = linktext {5};

NodeIn (1: nrLinks ) = linktext {6};

extraLink = 0; maxLinkNr = 200000;

(37)

(38)

B

Conversion Output

---Conversion program for TransModeler to MARPLE

The version used is: 1.0

---The threshold for the demand is : 1.000

The value for the person car unit is : 1.500

Number of original model nodes : 10177

Number of original model zones : 867

Number of nodes after zone splitting : 11911

Number of original model links : 12667

Number of links after direction split : 19268

Number of links after adding connectors : 25085

Number of origins : 867

Number of destinations : 867

Number of loop links : 9

Number of double links : 408

Number of links with strange parameters : 0

Number of nodes without links : 1

Node number(s) without links : 12984

Number of original links : 25085

Number of links removed : 415

Number of links remaining : 24670

Percentage of links removed : 1.65

Number of original nodes : 11911

Number of nodes removed : 1

Number of nodes remaining : 11910

Percentage of nodes removed : 0.01

Number of type changes for controlled links : 111

Number of type changes for roundabout links : 1604

Number of controlled intersections : 122

Number of signals : 406

(39)

34 B. Conversion Output

Number of roundabouts : 789

Number of origin nodes splitted : 19

Number of nodes final : 11930

Number of internal zone trips : 0.000

Percentage internal zone demand : 0.000

Number of obsolete demand pairs : 479 , of in total: 110656 OD pairs

Number of obsolete demand trips : 0.000, of in total: 467261.000 demand trips

Percentage obsolete demand : 0.000

Number of origins after filtering demand : 893

Number of destinations after filtering demand : 894

(40)

C

Data Processing Script

% ---%

% Script to generate plots from Stockholm data %

% last update : 08 -08 -2019

% ---%

% Modifactions :

% 2019 -08 -08: programming the script % % ---% general statements clear all ; close all ; fclose all ;

% map with plot data

cd 'D:\ MeetData \ Stockholm \ data '

% general statements

Title ='TU Delft Stockholm project ';

Helpstring1 = sprintf (['Module for Stockholm data \ nCopyright ',char (169)

,' 2019 Henk Taale \n\n',Title ]);

StartTimeData = '00:00 ';

EndTimeData = '24:00 ';

StartTimeDP = '06:00 ';

EndTimeDP = '10:00 ';

LTimeStep = 900; % measurement period in seconds

AggTime = 15; % aggretation interval in minutes

nrMinutes = round (1440*( datenum ( EndTimeDP )-datenum ( StartTimeDP ))) +1; nrPeriods = fix ( nrMinutes / AggTime );

% open file with flow data for May 2019

(41)

36 C. Data Processing Script

InputFile2 = fopen (' mcs_may_2019_2 . txt ','r');

if InputFile2 == -1

errorh = errordlg ('The file with flow data for May 2019 does not

return;

end

% ---% reading flow and speed data May 2019 % ---% reading file with data

datatext = textscan ( InputFile2 ,'%s %f %s %s %s','Delimiter ','\t','

EmptyValue ',-Inf ,' treatAsEmpty ','NULL ');

% convert route IDs

linkID = datatext {3};

% linkID {1} = char ( linkID {1}(4:8) ); % correction for first item % convert route start date and time

linkTime = datatext {4};

linkTime2 = datetime ( linkTime ,' InputFormat ','yyyy -MM -dd HH:mm:ss.S');

% % convert link speed

% linkSpeed = datatext {1};

% linkSpeed {1} = char ( linkSpeed {1}(4:19) ); % correction for first item % linkSpeed2 = strrep ( linkSpeed , ',', '.');

% linkSpeed3 = str2double ( linkSpeed2 ); % convert link flows and speeds

linkFlows = datatext {2};

% linkFlows3 = 4* str2double ( linkFlows );

linkFlows3 = 4* linkFlows ;

linkSpeeds = str2double ( datatext {1}) ;

% check on missing values

An= isnan ( linkFlows3 ); Bn= isnan ( linkSpeeds );

% sort data

linkSet = unique ( linkID );

nrLinks = length ( linkSet );

LinkFlow1 = zeros ( nrLinks , nrPeriods +1) ; % week days

LinkFlow2 = zeros ( nrLinks , nrPeriods +1) ; % work days

LinkFlow3 = zeros ( nrLinks , nrPeriods +1) ; % weekend days

LinkSpeed1 = zeros ( nrLinks , nrPeriods +1) ; % week days

LinkSpeed2 = zeros ( nrLinks , nrPeriods +1) ; % work days

LinkSpeed3 = zeros ( nrLinks , nrPeriods +1) ; % weekend days

nrWeekDaysF = zeros ( nrLinks , nrPeriods +1) ;

nrWorkDaysF = zeros ( nrLinks , nrPeriods +1) ;

nrWeekendDaysF = zeros ( nrLinks , nrPeriods +1) ;

nrWeekDaysS = zeros ( nrLinks , nrPeriods +1) ;

(42)

37

nrWeekendDaysS = zeros ( nrLinks , nrPeriods +1) ; day = weekday ( linkTime2 );

% calculating variables

linkTime2 . Format = 'HH:mm:ss ';

linkTime3 = datenum ( linkTime2 );

startT = rem ( datenum ( StartTimeDP ) ,1); endT = rem ( datenum ( EndTimeDP ) ,1);

% initialising progress bar

Help1 = Timebar ( Helpstring1 ,'Link data May 2019 ');

if length ( linkID ) >20

NrPerc = floor ( length ( linkID ) /20) ;

else

NrPerc =1;

end

% calculating flows and speeds

for i =1: length ( linkID )

linkNr = find ( ismember ( linkSet , linkID (i))); time = rem ( linkTime3 (i) ,1);

periodNr = round (1440/ AggTime *( time - startT )) +1;

if time >= startT && time <= endT && An(i) ==0

LinkFlow1 ( linkNr , periodNr ) = LinkFlow1 ( linkNr , periodNr )+

linkFlows3 (i);

nrWeekDaysF ( linkNr , periodNr ) = nrWeekDaysF ( linkNr , periodNr ) +1;

if day (i) ==1 || day (i) ==7

linkFlows3 (i);

nrWeekendDaysF ( linkNr , periodNr ) = nrWeekendDaysF ( linkNr , periodNr ) +1;

else

linkFlows3 (i);

nrWorkDaysF ( linkNr , periodNr ) = nrWorkDaysF ( linkNr , periodNr ) +1;

end end

if time >= startT && time <= endT && Bn(i) ==0

LinkSpeed1 ( linkNr , periodNr ) = LinkSpeed1 ( linkNr , periodNr )+

linkSpeeds (i);

nrWeekDaysS ( linkNr , periodNr ) = nrWeekDaysS ( linkNr , periodNr ) +1;

if day (i) ==1 || day (i) ==7

linkSpeeds (i);

nrWeekendDaysS ( linkNr , periodNr ) = nrWeekendDaysS ( linkNr , periodNr ) +1;

else

linkSpeeds (i);

nrWorkDaysS ( linkNr , periodNr ) = nrWorkDaysS ( linkNr , periodNr ) +1;

end end

(43)

38 C. Data Processing Script

if rem (i, NrPerc ) ==0 && i< length ( linkID )

ishandle ( Help1 );

if ishandle ( Help1 ) ==0

return;

else

Timebar (Help1 ,i/ length ( linkID ));

end

elseif i== length ( linkID ) Timebar (Help1 ,1) st= close ( Help1 );

end end

LinkFlow1 = LinkFlow1 ./ nrWeekDaysF ;

LinkFlow2 = LinkFlow2 ./ nrWorkDaysF ;

LinkFlow3 = LinkFlow3 ./ nrWeekendDaysF ;

LinkSpeed1 = LinkSpeed1 ./ nrWeekDaysS ; LinkSpeed2 = LinkSpeed2 ./ nrWorkDaysS ; LinkSpeed3 = LinkSpeed3 ./ nrWeekendDaysS ;

FlowComplete . LinkFlow1 = LinkFlow1 ;

FlowComplete . StartTimeDP = StartTimeDP ;

FlowComplete . linkSet = linkSet ;

FlowComplete . LTimeStep = LTimeStep ;

SpeedComplete . LinkSpeed1 = LinkSpeed1 ;

SpeedComplete . StartTimeDP = StartTimeDP ;

SpeedComplete . linkSet = linkSet ;

SpeedComplete . LTimeStep = LTimeStep ;

save FlowComplete1905 FlowComplete * save SpeedComplete1905 SpeedComplete *

(44)

---D

Calibration of flows and speeds

Measurement location 1

(45)

40 D. Calibration of flows and speeds

(46)

41

(47)

42 D. Calibration of flows and speeds

Cooperative Route Guidance - A Simulation Study for Stockholm

Delft University of Technology

Cooperative Route Guidance - A Simulation Study for Stockholm

Taale, Henk

Publication date

2020

Document Version

Final published version

Citation (APA)

Taale, H. (2020). Cooperative Route Guidance - A Simulation Study for Stockholm. Delft University of

Technology.

Important note

To cite this publication, please use the final published version (if applicable).

Please check the document version above.

Cooperative Route

Guidance

A Simulation Study

for Stockholm

Henk Taale

Final Report

January 31st, 2020

Contents

1

Introduction

1.1. SOCRATES

1.2. Route guidance Stockholm

Snapshots

1.3. Research approach

1.4. This report

2

Model choice and data processing

2.1. Choose the model

2.2. MARPLE

Modelstructure

2.3. Prepare input data

2.3.1. Network conversion

2.3.2. Traffic demand

2.3.3. Network issues

3

Calibration

3.1. Processing of the measured data

3.2. Calibration of the demand

3.3. Result of the calibration

4

Scenarios and results

4.1. Scenarios

4.2. Assumptions

4.3. Simulation results

4.4. Some remarks

5

Conclusions and recommendations

5.1. Conclusions

5.2. Recommendations

Bibliography

A

Conversion Script

B

Conversion Output

C

Data Processing Script

---D

Calibration of flows and speeds