4. Data preprocessing for fast routing
Accessibility computations are based on repeating routing over the road, which must be topologically correct, and transit networks. To save computation time, the layers of buildings and roads and the GTFS datasets are stored in a special format, as two databases, one for transit and one for the car network routing. These databases must be constructed at the beginning of the accessibility study, based on the topologically correct road network. It is worth constructing these databases for a large area (of up to a million buildings) that covers all potentially interesting locations and regions. Each version of the transit or road network demands its database that is stored in a dedicated folder and the path to it is a parameter of the accessibility algorithms. If you use the externally built database, create the folder and copy the database to this folder. The menu for building databases consists of three items (Figure 1)
Figure 1. Data processing section of the Accessibility Calculator menu
In this tutorial, we construct a topologically correct version of the road network and then exploit it to construct three databases – the one for car accessibility is limited to the Tel Aviv Metropolitan Area (TAMA), with its 250K buildings; two for transit accessibility, cover the entire Israel. We will use them for accessing TAMA accessibility in different scenarios. Specifically, we use
GTFS folder is the path to the folder that contains all necessary GTFS files:
stops.txt,stop_times.txt,routes.txt,trips.txtandcalendar.txt.The
gis_osm_roads_freeOSM TAMA road layer, August 2024.The
gis_osm_buildings_a_freeOSM buildings layers for TAMA, August 2024.
The layers of buildings and roads must be a part of the opened QGIS project. The path to the GTFS dataset must be provided as a parameter of the preprocessing procedure.
4.1. Topological cleaning of the road layer
The road network can be topologically inconsistent. There are many types of topological errors and the most frequent is the lack of a junction at an intersection of two visually overlapping links. Topologically inconsistent road layers cannot be used for accessibility computations. That is why, the Accessibility Calculator performs the basic topological cleaning of the road network that consists of breaking overlapping links at the intersection and deleting duplicated links. The user can apply more cleaning operations applying the v.clean operation of QGIS, see https://grass.osgeo.org/grass85/manuals/v.clean.html. Run the Accessibility Calculator and choose the Data preprocessing → Build road database option. In the dialog (Figure 2), enter the parameters:
Figure 2. Build road database dialog
Initial road network - the initial layer of roads. Must be opened in the current QGIS project.
Folder for the cleaned road network - the folder that contains the constructed layer. This layer will be added to the current GIS project.
Click Run to start. The Progress bar will show the progress of the computations. If something went wrong, you could break the process of dictionary construction by pressing Break. The Log tab contains information about the parameters, information on the edits, and the process of construction. For a detailed example of building a road database for TAMA see section 10.2.
4.2. Building database for transit accessibility
Run the Accessibility Calculator and choose the Data preprocessing → Transit routing database option. In the dictionary construction dialog (Figure 3), enter the parameters:
Figure 3. The Transit routing database construction dialog
Roads database folder - the folder of the roads database.
Layer of buildings - the layer of buildings. Must be open in a current GIS project.
id - the unique identifier of a building.
GTFS folder - the path to the folder that must contain all necessary GTFS files:
stops.txt,stop_times.txt,routes.txt,trips.txt,calendar.txtfiles.Folder to store transit database- the folder to store the transit routing database.
Click Run to start. The Progressbar will show the progress of the computations. If something went wrong, you could break the process of dictionary construction by pressing Break. The Log tab contains information about the process of construction and a dictionary. For a detailed example of building a transit routing database see section 10.2.
4.3. Building database for car routing
Run the Accessibility Calculator and choose the Data preprocessing → Car routing. Note that the database construction demands two tables (the right part of the dialog). Their meaning is explained in the next section 4.4. In the dictionary construction dialog (Figure 4), enter the parameters:
Figure 4: Car routing database construction dialog
Roads database folder — the folder of the roads database.
link type — the field of the link’s type in the layer of roads.
speed — the field of the link’s speed in the layer of roads.
direction — the field of traffic direction in the layer of roads.
Currently, we presume that the direction field contains the OSM traffic direction codes:
B: Two-way link,
F: One-way link, the driving is allowed along the direction the link is drawn,
T: One-way link, driving is allowed against the direction the link is drawn.
Layer of buildings - the layer of buildings, must be opened in a current GIS project.
id - the unique identifier of a building.
Default speed (km/h)- the link’s speed in case the link’s type is missing in the table of links’ speeds.
Folder to store car database - the folder to store the database for car routing.
Click Run to start. The Progress bar will show the progress of the computations. If something went wrong, you could break the process of dictionary construction by pressing Break. The Log tab contains information about the constructed dictionary. For a detailed example of building a database for car routing in TAMA see section 10.2.
4.4. Car Speed and Congestion Delay Index
To compute car accessibility,
one must know traffic speed along the route.
In the current version of the plugin, the traffic speed is defined by the type of road - a highway, major city street, neighborhood secondary street, etc., and the hour of the day.
The necessary parameters are stored in two tables that are located in the plugin folder and can be edited.
The free-flow traffic speed Vp, by the road link types p, is given in the car_speed_by_link_type.csv table (Figure 3, left). This table contains three fields.
seq — the sequential number of the row,
link_type — the OSM type of a link, and
speed — the car speed on the link of this type.
The OSM road layer may contain links whose type is missing in the car_speed_by_link_type.csv table. For these links, the Default speed (km/h) will be used.
The hour of the day is reflected by the Congestion Delay Index (CDI) - a ratio of the average, for the hour of a day, speed, to the free flow speed. The CDI values, by hours, are given in the cdi_index.csv table (Figure 5, right).
The speed Vp(t) on the link of a type p at the hour t is calculated as Vp(t) = Vp*CDIt
| link type | speed (km/h) |
|---|---|
| busway | 18 |
| cycleway | 15 |
| footway | 3 |
| motorway_link | 40 |
| track | 40 |
| residential | 30 |
| service | 40 |
| secondary | 50 |
| living_street | 30 |
| tertiary_link | 50 |
| hour | CDI |
|---|---|
| 0 | 1.0 |
| 1 | 1.0 |
| 2 | 1.0 |
| 3 | 1.0 |
| 4 | 1.0 |
| 5 | 0.9 |
| 6 | 0.75 |
| 7 | 0.6 |
| 8 | 0.6 |
| 9 | 0.65 |
Figure 5. Several first rows of the free flow speeds table (left) and the CDI table (right). The values of the free flow speed and CDI can be changed by the user.