Module 5b, Working with networks in a public transport setting

learning objective: How to use the GeoDMS to calculate with transport networks

Introduction

We will continue working with networks and their related impedance algorithms in this module. However, we will focus on public transport instead of using a road network. For this purpose, we will use Google's publicly available GTFS-feeds. These are downloadable from here, for example, the Netherlands: https://transitfeeds.com/p/ov/814. They have been available for up to four years, with multiple versions every month. It contains all public transport modes, including trains, buses, trams, metros, and ferries. It includes all stops and departure and arrival times. All defined transport lines. There are also exceptions to the standard roster and the transfer rules if inserted in the feed. For example, if two trains wait for each other on the opposing platform.

Possibilities

Using this data in a network model enables the modeller to perform a route planner application millions of times in a structured and efficient way and even more. Since we can start a journey from a bus stop and travel to a tram stop near the destination, but we can also include the walking route and its travel time from the true origin to the first stop, and similarly, the walking route and time from the last stop to the destination. Or travel that first leg of the journey by bike. There are many more variations and possibilities to be made with such a model.

A significant difference between a public transport model and a 'simple' road model is time. Travelling by public transport requires you to choose a departure or arrival time, and that choice will inevitably influence the outcome. The time it will take to reach your destination when you depart at 3 in the morning or depart at noon will probably be different. Moreover, departing at 12.00h will differ from departing at 12.10h. Maybe the required train only departs once per hour. So, you have to keep that in mind when configuring such a model.

The figure below shows possible routes from point A to B if we depart at exactly 7.00h in the morning. In route A, we first have to walk a bit to reach a tram stop, and a relevant tram departs at 7.11h, whereas a suitable train departs at 7.12h at the train stop. In both instances, departing at exactly 7.00h is unnecessary, so we first wait a couple of minutes and then set off (of course, in reality, we might depart earlier to get ourselves a buffer). From the four possible routes in this example, route A will be there the earliest. However, route A takes 18 minutes without the initial waiting and route B takes 15 minutes. So, while route B has the shortest travel time, the model chooses route A because that will get us there the earliest from our departure time. This is an essential factor to remember when using such a model.

Components

This model consists of several components:

• Creating a road network from the origin to a set of nearby stops and from the last stops to the destination;
• Reading and preparing the public transport timetable into a network with a time dimension;
• Performing impedance algorithms on a time-restricted subset of those networks; and
• Combining public transport OD-sets with non-public transport outcomes such as walking or biking directly from the origin to the destination.

Creating the road network

We must create road networks from the origin point to nearby public transport stops and from the last stops to the destination. These road routes are later added to the public transport network. We must also create a direct route from the origin to the destination, which can be travelled by foot or bike. For example, suppose a destination is very close to an origin. In that case, it is illogical to first walk to the first stop, get on public transport, travel back to the same or nearby stop and walk to that destination when directly walking to the destination is faster.

How we create a road is discussed at length in I: How to make a network. In this step, we also perform an impedance function on this network to determine the fastest route from the origin to the relevant nearby stops. A parameter setting determines how many stops we will consider around an origin and the maximum search distance.

Preparing the public transport timetable

The public transport timetable data (GTFS-feed) consists of several text files (descriptions from [1] https://developers.google.com/transit/gtfs/reference)):

• Stops: Stops where vehicles pick up or drop off riders. It also defines stations and station entrances.
• Routes: Transit routes. A route is a group of trips displayed to riders as a single service.
• Trips: Trips for each route. A trip is a sequence of two or more stops occurring during a specific period.
• Stop times: These are the times that a vehicle arrives at and departs from stops for each trip.
• Calendar: Service dates are specified using a weekly schedule with start and end dates. This file is required unless all service dates are defined in calendar_dates.txt.
• Calendar dates: Exceptions for the services defined in the calendar.txt. If calendar.txt is omitted, then calendar_dates.txt is required and must contain all dates of service.
• Shapes: Rules for mapping vehicle travel paths, sometimes called route alignments.
• Transfers: Rules for making connections at transfer points between routes.

These files will be read into GeoDMS and stored in the internal .fss format for faster access. Relations between the different tables will be created. Then, a set of scheduled links will be made, which are trips for a specific range of dates/times. It is defined as the departure stop, departure time, arrival stop and arrival time, and thus its consequential travel time. To be able to transfer between trips/routes, waiting times and/or transfer paths need to be created. Here, the walking network comes into play again to calculate the travel time to a set of near stops. as additional links.

At this point, it is essential to note that this is not simply a 2D geographical network anymore but has a new dimension: time. Taking a particular route choice also depends on the time since trips depart at set times at set locations, thus creating space-time paths.

Impedance algorithms

Since we now have a network, we can use the impedance algorithms described in the previous module: 5a: Working with networks over a road network. In the following example, we will calculate the case where we want the travel time from origins to destinations by first walking to the first stop, taking public transport, and then concluding the trip by foot to the destination from the last stop.

In the previous module, you learned how to use the impedance operator's different options. In this case, we indicate that it is directed or one-way. Then we will give information about the starting point. There are three terms between the brackets, meaning we must also provide three arguments. Similarly, we offer information about the endpoint. Then, to cut off the analysis for calculation speed purposes, we use the cut option to limit how long the public transport trips can maximally be. Finally, we want some information from the operator, namely the impedance between the OD-pair and the origin and destination index number to identify the OD-pair.

As you might remember, there are always three terms required in the operator: the impedance of a link (travel time or duration) and the F1 and F2, which are the beginning and endpoints of said link.

And now, the part that is different from a 'normal' road impedance function. The current network only has information from the first stop to the last stop. Nothing about the walking route/time from the origin to that first stop or from the last stop to the destination. That is what the information with the startPoint and endPoint are for. As the start point, we add the OD-pairs with their impedance (duration) from each origin to a set of first stops as created in the 'Creating the road network' step. And similarly for the endpoints. And the last argument is the cut-off value, in this case, a parameter setting called 'MaxOVDuration'.

unit<uint64> OD_traveltime_W_OV_W := 
impedance_matrix_od64('directed;startPoint(Node_rel,impedance,OrgZone_rel);endPoint(Node_rel,impedance,DstZone_rel);cut(OrgZone_max_imp);od:impedance,OrgZone_rel,DstZone_rel'
  ,StaticNet_subset/Duration[float32]
  ,StaticNet_subset/F1
  ,StaticNet_subset/F2
  //////
  ,Org2StopWalk/NodeRef_O2S, Org2StopWalk/Duration[float32], Org2StopWalk/Org_rel
  ,Stop2DestWalk/NodeRef_S2D, Stop2DestWalk/Duration[float32], Stop2DestWalk/Dest_rel
  ,MaxOVDuration
);

Combining public transport OD with non-public transport ODs

The previous section discussed impedance examples executed for each transportation type combination. For instance, walking - public transport - walking, or biking - public transport - walking. However, this method has one drawback. What if an origin is very close to a destination? This method requires you to first walk (or bike) to a nearby stop, get on public transport, and then get back there to finish the trip to the destination on foot. In such cases, it might be much faster if one were allowed to walk or bike to the destination directly. We, therefore, must also include those travel options. In order to do this, we combine the resulting OD's with their impedance (or travel time) and choose the trips with the shortest travel time.

What to use this for?

These resulting OD matrices are helpful in many ways. For example, as a full origin-destination matrix to calculate spatial weights. Or to be used to calculate the number of jobs that can be reached from each location, in combination with a distance decay function. See this next example; here, we calculate the OD-pairs for the combination walking - public transport - walking. Then, find the number of jobs present in each destination. Apply a predefined distance decay function (the coefficients are set in the parameter settings), and then per OD-pair, determine the highest amount of jobs that can be reached, and then sum that per origin point. Then you have per origin the number of decayed jobs that can be reached using public transport (or by foot or bike) at a certain departure time.

unit<uint64> OD_traveltime_W_OV_W := impedance_matrix_od64('directed;startPoint(Node_rel,impedance,OrgZone_rel);endPoint(Node_rel,impedance,DstZone_rel);cut(OrgZone_max_imp);od:impedance,OrgZone_rel,DstZone_rel'
  ,StaticNet_subset/Duration[float32]
  ,StaticNet_subset/F1
  ,StaticNet_subset/F2
  //////
  ,Org2StopWalk/NodeRef_O2S, Org2StopWalk/Duration[float32], Org2StopWalk/Org_rel
  ,Stop2DestWalk/NodeRef_S2D, Stop2DestWalk/Duration[float32], Stop2DestWalk/Dest_rel
  ,MaxOVDuration
)
{
   attribute<float32>         traveltime_min  := impedance / 60f;
   attribute<Combine_OrgDest> OD_number       := combine_data(Combine_OrgDest, OrgZone_rel, DstZone_rel);
   attribute<float32>         jobs            := dest/nr_jobs[float32][DstZone_rel];
   attribute<float32>         decay_function  := traveltime_min == 0ft ? 1fm : 1f / (1f + exp(ov_a + ov_b*log(traveltime_min) + ov_c*traveltime_min));
   attribute<float32>         jobs_decayed    := MakeDefined(jobs* decay_function,0f);
   attribute<float32>         jobs_reached_decayed (Org) := sum(UniqueOD/highest_jobs_decayed, value(UniqueOD/values / uint64(#dest), org));

   unit<uint64> UniqueOD := unique(OD_nummer)
   {
       attribute<float32> highest_jobs_decayed := max(../jobs_decayed, ../UniqueOD_rel);
   }
}

do it yourself!

Now that you roughly know how this model works, you can work with it yourself!

Before we begin, let's download the public transport model configuration: here and the source data: here.

1. The first impedance matrix is filled in, like in the example above. Now add an impedance matrix where you first bike to the first stop, and then take public transport and finish by foot again. Create it here: /NetworkSetup/Configuration/PublicTransport/PerMeasureMoment/At_07h00m00s/CreateODs
2. Next, create an impedance matrix where you only travel by bike (hint: this is similar to what is discussed in the previous module).
3. You'll see a unit called OD_traveltime_W_OV_W_with_BB in the downloaded configuration, which is commented out. Enable it, and fix all paths. This unit combines the W_OV_W output with the BB output and determines what is the optimal choice between those two options. Export the resulting output using Export_CSV_values_reached_W_OV_W_with_BB.