Public Transport

Public Transport#

The public transport module currently available on this library allow users to import GTFS feeds into supply models, including map-matching to the road network.

It does not, however, allow for traditional editing of transit networks, such as definition of new routes/services, changes to transit stops or stopping patterns.

Editing triggers#

The transit route system does not have the same level of editing capabilities as the roadway layer, but a series of triggers have been implemented to greatly reduce the amount of unecessary data leftover when deleting transit routes/patterns.

These triggers are the following:

When deleting a route:

Delete all patterns for that route
Delete all transit fare rules specific to that route

When deleting a pattern:

Delete all data from Transit_Pattern_Mapping regarding that pattern
Delete all trips from Transit_Trips for that pattern
Delete all links from Transit_Links for that pattern
Delete the sequence of links from Transit_Pattern_Links for that pattern

When deleting a trip:

Delete all scheduled arrivals and departures for that trip from Transit_Trips_Schedule

GTFS IMPORTER#

Since the main purpose of this model is to import GTFS feeds, key software operations are done on a class capable of reading a GTFS feed and querying it in memory.

You can also read a detailed explanation of the Transit Map-Matching algorithm

This class is designed to read standard GTFS feeds and might not work with poorly formatted feeds. For more information on GTFS, please refer to GTFS reference documentation.

Import process#

Although bus-on-traffic is not used by default on most of Polaris models, map-matching is still used by default for all routes (not only bus) whenever the GTFS feed being imported lacks route shapes. This is done in order to obtain route and transit_link shapes for display, as the old straight lines are less intuitive to some of those looking at model results.

Since the map-matching process is rather time-consuming, it is possible to turn it off and force the creation of straight-lines in the absence of route shapes with a single line of code

feed.set_allow_map_match(False)

Preventing excess speed#

During the development of multiple Polaris models, we have detected unusually high speeds for a number of route segments. As some of these segment speeds were in excess of 200 mph, a procedure to limit these speeds was put in place.

The process consists of delaying the arrival at a stop (and consequently at all subsequent stops in that trip) any time the segment speed is below a certain threshold.

The use of posted speeds is, however, impossible at that stage of the import process, as the route is yet to be map-matched to the network. For this reason, data analysis was conducted for all networks currently in existence to determine the threshold speeds to be used.

In time, these threshold speeds are mode-specific and vary according to the length of the route segment as to account for express routes.

As the distribution of segment lengths is likely to change significantly across modes and urban areas, the analysis was made for 20 bins with equal number of elements for each model/mode, rounded to the nearest 5m. We understand that this approach may cut off a possibly long tail for the segment length distribution, but we do not believe that this will have substantial effect on the GTFS processing outcome.

Chicago#

Chicago has routes for 3 GTFS modes, as follows:

GTFS mode 1 (Subway/metro)#

There are no clearly absurd route speeds, but some substantially higher speeds for the 99.5% percentile suggest that imposing some lower limits might be necessary.

Looking at the charts we have established that the appropriate speed limits to be imposed on import were approximate the following.

From Length	to length	Percentile	Speed (mph)
0	365	0.975	~21.9
365	480	0.975	~18.5
480	705	0.975	~23.3
705	785	0.975	~29.0
785	855	0.975	~31.3
855	1,020	0.985	~32.0
1,020	1,285	0.975	~31.9
1,285	1,600	0.980	~36.5
1,600	1,755	0.985	~39.5
1,755	MAX	0.975	~55.5

There is a somewhat constant low maximum speed for segments shorter than 705m and another plateau of speed between 700 and 1,775m, so we simplify the table as follows:

From Length	to length	Percentile	Speed (mph)	Speed (m/s)
0	700	0.970	22.9	10.2
700	1,285	0.970	31.3	14.0
1,285	MAX	0.985	36.4	16.3

GTFS mode 2 (Suburban rail)#

From Length	to length	Percentile	Speed (mph)
0	815	0.975	~30.3
815	935	0.975	~33.2
935	1,430	0.975	~42.5
1,430	1,955	0.975	~37.0
1,955	2,405	0.975	~37.0
2,405	2,965	0.975	~37.0
2,965	3,885	0.970	~43.5
3,885	5,070	0.975	~53.0
5,070	8,500	0.975	~49.0
8,500	MAX	0.975	~53.5

The variability for these modes is a little more extreme than for the other two, but we can establish a difference in general pattern for segments under 935m between 935 and 3,885 and over 3,885m. The resulting simplified limit table is:

From Length	to length	Percentile	Speed (mph)	Speed (m/s)
0	1,000	0.975	31.6	14.1
1,000	4,000	0.975	42.5	19.0
4,000	MAX	0.975	52.6	23.5

GTFS mode 3 (Bus)#

From Length	to length	Percentile	Speed
0	120	0.975	~23.0
120	155	0.970	~23.0
155	180	0.975	~23.0
180	195	0.975	~23.0
195	205	0.985	~23.0
205	210	0.985	~23.5
210	235	0.985	~26.0
235	270	0.970	~27.5
270	370	0.955	~31.0
370	MAX	0.985	~49.0

As there is a clear constant pattern for maximum speed for the segments up to 210m, we have simplified the table and retrieved the precise values for the percentiles above.

From Length	to length	Percentile	Speed (mph)	Speed (m/s)
0	210	0.975	22.7	10.2
210	270	0.975	26.9	12.0
270	370	0.955	30.4	13.6
370	MAX	0.975	49.0	21.9

Atlanta#

Atlanta also has routes for 3 GTFS modes, as follows:

GTFS mode 0 (Tram/Light rail)#

The maximum speeds for light rail segments for Atlanta are incredibly well behaved, so we will use the maximum available speed (12.8 mph) as the threshold across all distance brackets:

From Length	to length	Percentile	Speed (mph)	Speed (m/s)
0	MAX	1.000	12.9	5.8