5. Transit accessibility – database construction and service area maps

To compute transit accessibility, one must translate the data on roads, buildings, and public transport routes and timetables into a database. Then, the service area for the set of facilities or accessibility of the entire region can be computed. This section explains the construction of the transit routing database and service area maps (Figure 1).

Figure 1. Transit accessibility, database construction, and service area maps sections menu

5.1. Building database for transit accessibility computations

To allow fast accessibility computations, the data on roads, buildings, and public transport routes and timetables are translated into databases. During this transformation, the buildings that are not connected to the road network are related to the nearest road link of the cleaned layer of roads. The shortest distance to these links is calculated, stored, and employed for establishing the network path between the building and bus stops. The result of this operation is stored in the database and the clean layers of roads and buildings are not changed. To build the database for transit routing choose the Transit routing database (Figure 2):

Figure 2. Transit routing database construction dialog

Layer of roads - the clean layer of the road links. Must be a part of the current GIS project.
Layer of buildings - the clean layer of buildings. Must be a part of the current GIS project.
id - the unique identifier of a building in a table of buildings’ attributes.
GTFS folder - the path to the folder that contains GTFS files: stops.txt, stop_times.txt, routes.txt, trips.txt, calendar.txt. The default path is the GTFS subfolder within the folder of the current QGIS project.
Folder to store transit database- the folder to store the constructed transit routing database. The system’s suggestion is a subfolder in the folder where the project is stored with the name that is a concatenation of the name of a project (TAMA) and “_pkl.”

Note

If you construct several transit routing databases, e.g., for several versions of the transit network arrangements, use different folders for each of them because the database tables have constant names. It is worth constructing the dataset for a large area (of up to a million buildings) that covers all potentially interesting locations and regions.

Click Run to start. The Progress bar will show the progress of the computations. If something went wrong, you could break the process by pressing Break. The Log tab contains information about the parameters and the process of construction. For a detailed example of building a transit routing database for TAMA see section 10.2. In this tutorial, we limit our examples to the Tel Aviv Metropolitan Area (TAMA), with its 250K buildings. Yet, the GTFS datasets are provided for the entire Israel, and the databases for transit routing are constructed for the whole country. The examples of this tutorial consider two versions of the GTFS databases, one for June 2018, reflecting the state of the transit system before the Red LRT line was established in the Tel Aviv Metropolitan area, and one for June 2024, after the Red LRT line started to function.

5.2. Transit accessibility – Service area

This section explains the Transit accessibility → Service Area maps part of the Accessibility Calculator menu (Figure 1). We present in detail the From service locations – Fixed-time departure option and then, the differences between this and three other options. See Sections Sections 2.7, 2.8 and 2.9 for definitions of the Service Area and related computations. To compute a service area, two datasets must be ready for use

The transit routing database must be constructed, see section 5.1.
The clean layer of buildings must be a part of the current QGIS project.

5.3. Accessibility from the services, fixed-time departure

The travel time in this case is estimated for the PT journey with the earliest arrival to the destination. Choose From service locations – fixed-time departure (Figure 3):

Figure 3. Service area maps → From service locations – Fixed-time departure dialog

Parameters of the computations: Transit routing database folder — the folder that contains the transit routing database. Must contain the following files: stops.pkl, stoptimes.pkl, transfers_dict.pkl, idx_by_route_stop.pkl, routes_by_stop.pkl
Output folder — the folder for storing the results of the computation. The system’s suggestion is a subfolder in the folder where the QGIS project is stored with the name that is a concatenation of the name of a project (TAMA) and “_output.”
Output alias — the alias for the files of results.
Layer of facilities — the layer of the facility buildings, may be a selection set of the layer of buildings. In the case of the selection set, the chosen buildings are stored in the output folder in the geojson format.
id — the unique identifier of the facility buildings.
Visualization layer — the layer that will be used for visualization of accessibility maps, must be a part of the current QGIS project.
id — the unique identifier of the visualization polygons, must be the subset of buildings’ identifiers. More information here.
Minimum number of transfers — the minimum number of transfers of the transit trip, typically 0.
Maximum number of transfers — the maximum number of transfers of the transit trip, may be 0, 1, or 2.
Maximum walk distance to the initial PT stop, m — the maximum acceptable walking distance between the trip origin and the first bus stop. The default value is 400 m.
Maximum walk distance at the transfer, m — the maximum acceptable walking distance between two stops at the transfer. The default value is 150 m.
Maximum walk distance from the last PT stop, m — the maximum acceptable walking distance between the last stop of a trip and destination. The default value is 400 m.
Start at (hh:mm:ss) — trip start time.
Walking speed (km/h) — walking speed.
Maximum waiting time at the initial stop, min — the maximum waiting time at the initial stop of the trip.
Maximum waiting time at the transfer stop, min — the maximum waiting time at the transfer stop.
Maximum travel time, min — the maximum total trip time.

Click Run to start. The Progress bar shows the progress of the computations. You can break the process of the computations by pressing Break.The Log tab presents the run metadata. The results of the computations are stored as two CSV report files in the Output folder. The first depicts the service area - all buildings that can be reached from at least one of the facilities in Maximum travel time or faster. Each of these accessible buildings is represented by the record that contains the id of the facility that served it, and all details of the trip between the facility and the building. The service area is visualized based on the Visualization layer. For the example of the From service locations – Fixed-time departure computations and maps for the road network and buildings layer of TAMA see section 10.4.1 and section 10.5.1. The service area file does not contain information on whether a building can be served by more than one facility. This information can be retrieved from the second output file, where for each facility, all buildings that can be served by it are listed. This second file can be used for deeper analysis of the accessibility, for example for recognizing buildings that can be reached from half or more of the facilities. In both output files, the details of every leg for every trip are described in detail, see the next section.

5.3.1. Service area computations - the log file and the structure of the report

The log file (Figure 4) in the results folder stores all settings of the run and the computation time and is also presented in a log tab.

Figure 4. Log file of the From service locations – fixed-time departure transit computations

The CSV file of results contains all the details of a trip to each accessible building (Figure 5):

Attribute	Meaning
Origin_ID	The ID of the facility building
Start_time	Time of the trip start
Walk_time₁	Walk time to the initial stop
BStop_ID₁	The ID of the initial stop
Wait_time₁	Waiting time at the initial stop
Bus_start_time₁	Start time of the first motorized leg of a trip
Line_ID₁	ID of the line used for the first motorized leg of a trip
Ride_time₁	Duration of the first motorized leg of a trip
AStop_ID₁	Alighting stop of the first motorized leg of a trip
Bus_finish_time₁	Finish time of the first leg of a trip
Walk_time₂	Walking time to the first transfer stop
BStop_ID₂	ID of the first transfer stop
Wait_time₂	Waiting time for a bus at the first transfer stop
Next motorized legs and transfers	…If more transfers are performed
DestWalk_time	Walking time from the last stop to a destination
Destination_ID	The ID of the destination building
Destination_time	Time of arrival to destination for the journey with the earliest arrival to the destination
Duration	Total trip duration for the journey with the earliest arrival

Figure 5. The structure of the From service locations – fixed-time departure option output.

The example of the From service locations – fixed-time departure computations see here.

5.4. Accessibility to services, fixed-time arrival

The travel time in this case is estimated for the PT journey with the latest departure from the origin. Run To service locations – fixed-time arrival. Most of the parameters of the to-accessibility computations are the same as for the from-accessibility. The major difference is in establishing facilities and buildings to serve: For the to-accessibility, facilities are destinations and not origins, as in the case of the from-accessibility (Figure 6).

Figure 6. The Facilities/Origins part of the To service locations - fixed time arrival dialog

In addition, the trip’s start time is substituted by the arrival time (Figure 7).

Figure 7. The Arrival time part of the To service locations - fixed time arrival dialog

The Log and Result files for the to-accessibility have the same format as for the from-accessibility, with minor changes that reflect the changes in the direction of trips. The output table includes an additional attribute: “Latest time at destination”, that contains Arrive before time. The example of the To service locations – fixed-time departure computations see here.

5.5. Service area for schedule-based departure or arrival

The modern users of public transport are aware of the time the bus arrives at the stop they plan to start from or at the final stop of the trip. These travelers start their trip and walk to the initial stop to be there just before the bus arrival or choose the bus that arrives at the destination just before they want to be there. Having several travel options during the appropriate time interval, they choose the option that takes minimal time. As an example of the “from” schedule-based accessibility computation, let us consider a traveler who is willing to start her PT trip to work between 8:00 and 8:30, and travel up to 45 minutes. Let us also assume that there is only one stop nearby at a 3-minute walk, two lines that take her to a destination and the buses of these lines arrive at this stop at 8:05 (Line 1) and 8:25 (Line 2), respectively. With the first line the total travel time is 30 minutes, and the arrival time will be 8:35. The second is an express line, the total travel time is 20 minutes and the traveler will be at the destination at 8:45. The standard RAPTOR algorithm will choose the trip with the Line 1 and the earliest arrival to the destination, the second trip would not be considered at all. The schedule-informed traveler can also choose the second trip because it’s the fastest and the start time is still within the acceptable time interval. Note that in both cases, the time between the earliest start time and the actual start of the trip with the earliest arrival (8:02) or the fastest trip (8:22) is not included in the total travel time. In a Schedule-Based regime, the Accessibility Calculator considers both options and constructs two accessibility maps – one based on the earliest arrival and another based on the fastest trip. The user can choose any of them for accessibility assessment, as well as compare accessibility estimates for these two views of the travelers’ behavior. In the case of the schedule-based to-accessibility computations, the latest arrival time is also substituted by the arrival interval. A traveler is allowed to arrive at the destination between the “Earliest arrival time” and the “Latest arrival time” that must be the same or later. As above, two maps are constructed and stored – one based on the trips with the latest start time and another based on the fastest trip. The “residual” time between the actual arrival and the latest possible arrival is not included in the travel time. To compute accessibility for schedule-informed travelers we have modified the RAPTOR algorithm and organized these computations as separate items in the Accessibility Calculator menu. The difference between the accessibility computations for travelers behaving according to the fixed time start or finish of the trip, and for the travelers whose behavior is schedule-defined as conceptual, and we will be happy to know your experience in employing these two approaches and comparing the results. The parameters of the From locations – schedule-based departure computations are almost the same as for the fixed-time from-accessibility. The difference is in the description of the start of the trip which is defined by two parameters:

Earliest start time — the earliest start time of a trip,
Latest start time is T minutes later, T = … the latest start time of a trip.

For the To locations – schedule-based arrival accessibility, the description of arrival to the destination is defined by:

Earliest arrival time — the time of the earliest arrival to a destination,
Latest arrival time is T minutes later, T = … the latest arrival time of a trip.

The examples of schedule-based accessibility are here.

The example section 10.6.2 contains the comparison between the estimates of the time-fixed and schedule-dependent accessibility.