-
Notifications
You must be signed in to change notification settings - Fork 0
The Simulation
In general, the simulation tries to predict the effects of congestion to bus network along one day. The produced result shows the movement of each bus from the starting location to the end stop, so it can be easily visualized the locations where the congestation effects the most to the network.
The simulation has been made having ABM approach, but as the model only contains public transport agents those lack interaction between each other (because there are no implemented rules for agent interaction and the agents most probably do not encounter each other in meaningful measures), the model has more MSM approach to the problem.
For public transport agents the data is extracted from gtfs-package hosted by HSL. One call of data fetching functions collects the needed information for one calendar day (current day by default) into two separate dataframes: routes and schedules. Routes are collected from shapes.txt file of the package. For schedules three datatables are combined:
- trips.txt for daily timetable
- calendar.txt for defining on which dates the route is operated
- routes.txt for defining which vehicle type (tram, metro...) operates this route
Processed route dataframe contains only route geometries. Schedule dataframe contains departure times and vehicle types. The data can be connected by common shape id.
The environment in this context are the external restrictions for agent's movement on its path. In our implementation these are two variables: speed limit and congestion status. These are used to calculate the actual speed of an agent along its path. No actual data structure is maintained during the simulation to hold the environment, but speed limits are read from digiroad data file, and the congestion model is implemented in the simulation as discussed in the next chapter.
The congestion model estimates the speed of congested traffic flow from time of day and traffic network density. The idea of tracking these variables is that the congestion is caused by commution traffic, and traffic must slow down in node locations where vehicles meet. The effects of different factors are multiplied together to form the overall estimate. The estimated congested speeds are basically used as a attribute of the environment.
The traffic status at different time of a day is modelled using the volume-to-capacity ratio changes along day. A problem of using time as input for modelling is the fact that time does not cause congestation but the interaction between vehicles. However, as the computation is done indirectly by estimating restricted speed from current volume to capacity status, the simulation could be changed relatively easily to take account the modelled traffic load instead of time (although this approach would still miss the direct interaction between agents). The actual mathematical functions used are represented in the figure below. The development of VC-ratio is inspired by model results described in one OECD report(pp. 59, fig. 24).
For estimating traffic network density, the number of unique elements in digiroad dataset is used. One problem of this approach is that the intersections itself do not cause congestation, but the interaction between vehicles in them. The model does not make any difference if a vehicle is leaving or arriving an area with multiple intersections (many road segments), but the speed is restricted in both cases. The effect of the number of elements is represented in the figure below.
One simulation step corresponds to constant change of time in reality. At each time tick the movement of agents is estimated as described in the subchapter below. Basically, the simulation tries to estimate how environment (speed limits, congestion) affect to the movement on the agents route.
In the initialization phase of the simulation, agent objects are created from the route and schedule data described earlier. All individual objects have
- Starting point (the beginning of their route)
- Departure time
- Assigned route
- Agent type (Only bus objects are implemented now)
During the simulation agents are stored in one dataframe, where the time tick function is called for each object one by one.
The simulation is advanced with time ticks of a certain length. At each time tick, the agent checks the speed limit at its current position, corrects its value according to congestion model and finally updates its speed property. Then the distance that the agent can travel along its assigned route during time tick with certain speed is calculated. From there a point at the specified distance along the agent’s route is computed and used to update the agent’s current location property.
If an agent reaches the endpoint of the route assigned to it, the agent is removed from the simulation.
The interaction between agents and the environment is realised during checking speed limit for agents. In the application, each agent has a speed property. A speed value is calculated at every simulation tick from speed limit at the current agent’s location and corrected by congestion level dependent on the time of day and number of road elements surrounding the agent (more detailed information in the congestion model section). Speed limit value at a location is read from road network vector dataset provided by the user to the application. In our example case, the speed limit layer from digiroad dataset is used. The dataset is preprocessed by clipping to the extent of the simulation and saved as GEOJSON file.
In the simulation, a buffer (with a default value of 100m) around the input location is calculated. Next, all road Linestrings within the buffer are read to geopandas data frame. To calculate congestion at a given location, the number of road elements in the buffer is checked. Then, the distances between the input location and each road segment in the data frame are computed. The road segment with the shortest distance is selected. Lastly, the speed limit value of this road element is read and returned together with the number of road elements in the buffer.
Processing writes the simulation result into a geopackage file. The file contains