GTFS data powered by OpenTripPlanner - Part 1
Introduction to GTFS and OTP.
What is GTFS?
The General Transit Feed Specification (GTFS) has been around for quite some time. First released 15 years ago GTFS started out as a side project of Google employees.
It can be used for network topology management, studying for a new network, new lines, or new timetables. But also for visualizing the topology of several networks, accessibility, analysis and having real-time information.
A GTFS feed is a collection of at least six, and up to 13 files contained within a zip file. These static text data files are consistent in format, incorporating timetable, geographic data and general agency data into a tabulated format (feed). GTFS “feeds” let public transit agencies publish the transit data.
Table name | Description | Sample |
---|---|---|
Agency | gathers transport service information (transport companies, network name) | agency_id: SEM agency_name: Mobilitées M -Tag agency_url: https://www.mobilites-m.fr/,Europe/Paris agency_timezone:null agency_lang:FR agency_phone:0438703870 |
Routes | Transit routes. A route is a group of trips that are displayed to riders as a single service. | agency_id: SEM route_id:1 route_short_name:C1 route_long_name:GRENOBLE Cité Jean Macé / MEYLAN Maupertuis / MONTBONNOT-SAINT- MARTIN Pré de l'Eau route_type:3 route_color:FDEA00 route_text_color: 000000 |
Trips | Trips for each route. A trip is a sequence of two or more stops that occur during a specific time period. | |
Stop times | Times that a vehicle arrives at and departs from stops for each trip. | trip_id; 25485431 stop_id; 6806 arrival_time; 07:22:00,07:22:00 departure_time; 07:22:00 Stop_sequence; 1 Pickup_type; 0 |
Calendar dates | Service dates specified using a weekly schedule with start and end dates. This file is required unless all dates of service are defined in calendar_dates.txt. And so, 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. | service_id: 12345-MFHLV13c_ST0_13_HI2122 date: 20220117 exception_type : 1 |
Transfer | Shows the correspondences between several breakpoints | from_stop_id: S6 to_stop_id: S7 transfer_type: 2 min_transfer_time: 300 |
Many transit agencies have created and published GTFS data with the primary purpose being integration with Google Maps. Data can be found fairly easily, the following website lists available feeds: https://transitfeeds.com/feeds
During testing we will be using data from the Grenoble area which can be found at data.metropolegrenoble.fr
What is OTP (Open Trip Planner)?
OTP (https://www.opentripplanner.org/) is an OpenSource Software written in Java, that is designed to use open data sources OpenStreetMap (OSM) and the GTFS data. It allows users to plan a trip that can combine multiple modes of transportation, such as bicycling or walking to reach public transportation. It can deal with Interlines (transfers) between different public transportation systems. Users can specify departure or arrival times for public transportation to build isochrones.
OTP is used in production in several cities, here a few examples
Alencon (France) : https://altobus.com/mon-itineraire
Atlanta (USA) : http://itsmarta.com/planatrip.aspx
Grenoble (France) : https://www.mobilites-m.fr/
OTP is available in two major versions that are still maintained. While the second version is optimized, it does not have all the functionalities from the first version, as demonstrated in the table below
TLDR
Open Trip Planner 1
- Exists since 2009
- Widespread use
- Many options and tools
- Transit routing approach obsolete
- Experimental code
Pros of Open Trip Planner 2
- 2018
- Still in Testing
- Large or dense network
- EU-standard Netex and SIRI data
- More Efficient
Check http://docs.opentripplanner.org/en/latest/Version-Comparison/ for all differences
With no isochrones and no transfer policy with OTP 2 we opted
to use OTP 1 for the upcoming tutorial.
Use Cases
The following map (build with QGIS) shows our area of study with the list of stops from the GTFS data.
OTP provides several APIs (http://dev.opentripplanner.org/apidoc/1.5.0/index.html). We will cover a few of them.
The main feature of OpenTripPlanner is for planning trips. You can use the API to request an
itinerary from one place to another at a specific time:
http://0.0.0.0:8089/otp/routers/default/plan?fromPlace=45.16385418613824%2C5.732674598693848&toPlace=45.170117418455064%2C5.747051239013672&time=9%3A48am&date=01-28-2022&mode=TRANSIT%2CWALK&maxWalkDistance=750&arriveBy=false&wheelchair=false&locale=fr
key | value | description |
---|---|---|
fromPlace | 45.16,5.73 | the origin of the trip, in latitude, longitude |
toPlace | 45.17,5.74 | the destination of the trip |
time | 9:48am | the desired departure time |
date | 01-28-2022 | the desired departure date |
mode | TRANSIT,WALK | transport modes to consider, in this case a combination of walking and transit |
maxWalkDistance | 750 | the maximum distance in meters that you are willing to walk |
arriveBy | false | specifies that the given time is when we plan to depart rather than when we want to arrive |
wheelchair | false | If there is wheelchair access or not |
This will give you a list of possible itineraries (as shown with the builtin website):
OpenTripPlanner can also be used to calculate the area which is accessible from a point within a given travel time, also known as a travel time isochrone.
GET http://localhost:8089/otp/routers/default/isochrone\?fromPlace\=45.18831,5.713\&mode\=WALK,TRANSIT\&maxWalkDistance\=500\&\&cutoffSec\=1000\&cutoffSec\=1800\&cutoffSec\=3600\&cutoffSec\=4800
HTTP 200
{
"result": "ok",
{
"type": "FeatureCollection",
"name": "export_4",
"crs": { "type": "name", "properties": {... } },
"features": [...],
}
The cutoffSec param (1000, 3600…) tells the router that we want an isochrone ending at 1000, 1800, 3600, 4800 seconds) travel from the origin.
The previous request will result in a json file that once added to QGIS will show you the areas you can go to in 1000, 1800(seconds), ect.. .
Another powerful feature is the one-to-many travel time analysis. As an example, we want to find out how much time is needed to go to each available job using public transport.
Using the pointSet (a csv file with x, y representing jobs) and the surface API we are able to calculate the time required to go from one point (your home for example) to a potential job.
http://localhost:8089/otp/surfaces?batch=true&fromPlace=45.18831,5.713&time=5:46pm&date=01-20-2022&mode=TRANSIT,WALK&maxWalkDistance=800&arriveBy=false
Then querying http://localhost:8089/otp/surfaces/0/indicator?detail=true&targets=jobs&detail=true.
Will return the amount of time needed to get to each job. Thus enabling us to generate the following map. Where each point represents a job and the label the number of minutes to get there.
That's it for this first part!
You should now be familiar with both GTFS data and the OTP application.
The next blog will continue with Part 2 and consist of a short tutorial in order to get you started with OTP.
Get in contact with us!
If you already want to receive additional information please do not hesitate to contact us!
Top comments (0)