Visualization of travel times with OTP and QGis
Using open source products and open data to create a stunning visualization of public transport travel times in the Netherlands
One of the greatest developments in Dutch public transport, is the ongoing growth of publicly available data. Combined with OpenStreetMap this results in sufficient information for multi modal travelplanners. The OpenTripPlanner is an example of a very complete tripplanner implementation. This article will show you how to use the OTP and QGis to visualize travel times to all regions in the Netherlands from one start point.
Times are changing, working from home is becoming the new standard and most likely here to stay. 2 or 3 days to the office will become the standard, reducing the days traveling from home to work. Over the last decades commute time has stayed the same, roughly an hour a day for a single trip, as a maximum for most people. The oncoming decades I expect the weekly commute time to stay stable, increasing the acceptable traveltime per day, which will allow for people to move out of the cities and into the backlands (‘beyond Utrecht’).
This will raise the question: What areas of the country are reachable within a certain amount of travel time? This article will show you the travel times from a fictive work location in the center of Utrecht to all postal codes in The Netherlands. All travels are made with public transport.
The data sources for this project are OpenStreetMap from the GeoFabrik and OVapi for time schedule in GTFS format. Traveltime calculation is perfomed with the OpenTripPlanner 2.0 and the visualizations are made with QGis 3 based upon GeoJSON files.
The complete code of this article can be found on Github.
Calculating travel times
The first step is calculating the travel time. From our start point to a series of locations in the country. As mentioned before, calculations are performed with OTP. OTP requires a OpenStreetMap PBF file of you region of interest for streets and walking times and the GTFS for the public transport timetable. The OTP jar is downloaded from Maven . The -shaded version is used for simplicity as it includes all dependencies. The OSM PBF is obtained from the GeoFabrik and is named ‘netherlands-latest-osm.pbf’. The GTFS is downloaded from OVapi and downloaded as zip (‘gtfs-nl.zip’). All three files are stored in the same location.
OTP is started from the command-line:
It will locate the OSM and GTFS files in the current directory and start building the network graph. Due to the size (we are creating a map for a whole country, not a single city) this will take some time but finally the OTP server is started. The 12G heap size is required to able to load the network graph in memory. To test the server, try the URL http://localhost:8080.
Besides the webinterface, there is a REST API for using the OTP-server. Older versions of OTP provided a REST-API for requesting isochrone maps with travel times from a single location but unfortunately this API is no longer available in the latest version.
The GTFS stops specification is a good entry point to define the set of destinations for the travel time calculation. For all defined public transport stops we take the LatLon coordinate and round it to three numbers behind the dot. 1 degree is approx. 111 kilometer, so xx.xxx gives a resolution of 100 metres. After removing duplicate locations the set is obtained that will be used. By rounding the LatLon locations duplicate calculations are prevented, e.g. two bus stops at the opposite side of the same road.
This example shows the creation of the input set where a location in the city center of Utrecht is used and travel will take place om March 17th 2021 at 16:00. The same file format can be used for calculating a set of origin-destinations with different origins at different times and dates, but for now, the start location and datetime of travel are constant.
OTP supports planner requests through its REST API. A request has the following form:
http://localhost:8080/otp/routers/2015/plan?<param>
The parameters specify, among others, the date, time, origin, destination and modalities to use. By calling this endpoint for every origin/destination line in the created file an overview is created of travel times to all locations, reachable by public transport, in the country:
The resulting dataset:
Visualizing travel times
Adding these points to a map in QGis gives a reasonable overview of travel times. First install QGis 3 from https://qgis.org and add the base map for the country from https://www.openbasiskaart.nl/qgis.html by following the toturial on this page. We add the ESP-28992 map als basemap for the visualization.
On top of the basemap a layer is added with the travel times by adding a ‘’text delimeted layer” and specifying the output file from are script as source. Make sure to use the EndLon, EndLat as location columns (otherwise only the start point is drawn). It now shows all calculated travel times as dots on the map:
Since the public transport points are the base of the destination locations, the distribution of the dots gives a good overview of the public transport density. We can add a color to the dots that indicates the travel time by specifying it as ‘graduated’’:
Dark green dots are within 30 minutes, light green within 60 minutes, yellow within 2 hours, orange within 4 hours and red more than 4 hours:
Although it is a good start, the map does not give a complete, easy to follow overview of the travel time. It is a big mess of dots. To improve the map, we want to make a isochrone like overview. We need to divide the map in areas covering the total country and colorize these based on travel time. The source for these areas will be the postal code map. The shapes of all postal ode areas can be obtainend from ArcGIS Hub. The travel time to a postal code is calculated as the average travel time to all the available points from the map above:
The GeoPandas package has good support for geographical calculations, including the selection of points within a given area (gdf.within(…)). For all postal codes a column is added with the travel time (‘Traveltime’).
Looking at the map above, one can suspect that not all postal codes are covered. Over 10% of the postal codes have no travel time after executing the code above. These postal codes are given the average travel time to the surrounding (touching) postal codes with 15 minutes added to the required time (for commuting from postal coode to postal code). If this still does not result in a time, maximum time from the complete set is used (to keep the coloring in band later on).
And finally save the GeoPanda dataframe as GeoJSON file:
After exporting this dataframe it can be added as a layer to QGis (e.g drag and drop the geojson file to the layer window of QGis):
The postal code areas cover the complete country and have sufficient detail for our purpose. If more detail is required, the PC6 dataset can be used.
Last step is adding color to the shapes:
The colors increase with 15 minutes and gradualy go from green to red, resulting in a nation wide overview of the travel time to the center of Utrecht:
If the acceptable travel time is given, e.g. 90 minutes, the color scheme can be adapted to:
· Green: 0 to 60 minutes
· Lightgreen 60 to 90 minutes
· Yellow: 90 to 120 minutes
· Red: 120 minutes and more
Final remarks
The Open Trip Planner 2 is a fully fledged open source multi-model trip planner. With its API it is easy to integrate into any script or application. With the support for geographic calculations by GeoPandas it is relative easy to create geo-coded datasets. QGis is an open source geographic information system that can be used from the interface, as done in this example, but is also equipped with a Python interface making it easier to integrate in scripting and applications. Creating visuals is easy and helpful since a graphical overview makes data interpretation easier.
Disclaimer: The views and opinions included in this article belong only to the author.
