The walking & cycling distances to all the transit stops in Helsinki — an isochrone calculation on QGIS
The Helsinki metropolitan area is, in global comparison, very well served by public transport. The means of public transport in the region include:
- trams, which mostly serve the downtown area
- buses, which mostly serve more sparsely populated areas and suburbs
- metro, which serves the downtown and the coastal suburbs on both sides in west-east-direction
- commuter rail, which connects downtown to inland suburbs, the airport and all the small town centers built along the railway to the north and west of Helsinki.
Several light rail routes are also being built at the moment, but currently the tram network does not extend far from downtown.
A central question, then, is, which areas do these modes of transport serve, and how many people have access to transit? One way to study this would be to look at actual transit lines, their timetables, schedules etc. and calculate the accessibility of various areas with transit. However, this process is very complex and the resulting accessibility is dependent on changing timetables, the time (morning, day, afternoon, evening, night) under study and many other factors.
What do we want to know?
A necessary first step to do that, however, is to first consider the more static physical accessibility of transit stops, and how many people are served e.g. within 500 meters or 5 minutes of a transit platform. Obviously, the distance needed to travel to a bus stop, tram stop, or an underground station is not the same as the distance from the origin to the station point on the map. We need to take into account the walking network in the neighborhood, the locations of entrances to the stations and, if the station is underground or over the ground, the time taken to walk from the entrances to the actual train platforms.
HSY, the Helsinki Region Environmental Services alliance, is the instance responsible for managing environmental data for the whole of the metropolitan region, not limited to a single city or municipality. Therefore, regional access to transit is one of their datasets that sees heavy usage when doing e.g. regional or local planning decisions and reports. The general aim in the Helsinki region is to only zone homes, businesses and services within easy reach of public transit.
Bus stops are scattered all around the region, and they do not really tell much about the quality of service, as a stop may be served from anything from one to hundreds or thousands of departures per day. Tram stops are at the moment only the concern of the City of Helsinki, used in downtown planning. Then, the most important modes of transit on the regional level at the moment are the metro and commuter rail.
In Helsinki, they can be used almost interchangeably; the Helsinki Metro is built on the same wide gauge as the Finnish railway network. The metro stops are in general closer to each other than the railway stations, and thus the average metro speed is low (and limited to 80 km/h at any rate), but the metro and commuter rail offer similar capacity. The level of service of trunk commuter rail routes is the same as the metro routes, although commuter rail stations further from the city are served much less frequently. Still, metro and railway stations represent the existing infrastructure that can be used to focus local planning around transit hubs. (In the future, light rail routes will definitely warrant a similar analysis, though.)
How will we do the routing?
If our task is to find out the walking distances to all the metro and train platforms in the region, this is once again the good old isochrone calculation problem tackled recently in the case of schools around the world. That blog post is recommended reading; it details how isochrones, i.e. polygons of constant time, can be calculated around a point with QGIS, when the network around the point is known. Here, we will use the same calculation method and our QGIS plugin already employed for school accessibility, and perhaps tweak it for a whole new purpose!
Therefore, the data needed to do the calculation are 1) the locations of all the transit platforms and 2) all the walking routes to all these platforms, i.e. the whole walking network of the metropolitan area. In addition, metro and rail stations are often reached by bike. Therefore, we will also need all the bike routes to all these platforms.
Here, again, we are in luck! The good people of HSL, Helsinki Region Transport, have their excellent Journey Planner service right at their front page (and their excellent mobile app) that does exactly that. The whole Helsinki region Journey Planner is based on OpenStreetMap (shortened OSM) data, and the OSM data in the area has been studiously updated and improved on for years by HSL support staff. Therefore, we have all the data we could ever dream of having, ready in OpenStreetMap. They keep all the station entrances, stairs etc. in OSM up do date, and offer foot and bike routing from any point A to B in the Helsinki region.
HSL do offer a routing GraphQL API to the data, as well as lots of other open datasets, but as we want to calculate isochrones ourselves, we may just download the OpenStreetMap extract for Finland (e.g. from GeoFabrik) and start up our GraphHopper like done in the school case. (Of course, there are a few technical details on how to do this, which you may read in our step-to-step instructions.)
There were, of course, some issues with the OSM data. Some station platforms were not properly connected to the OSM walking network. In addition, some squares around major stations (Rautatientori, Kamppi, Itäkeskus, Kivistö, Sörnäinen) did not have walking routes marked through them; they had to be added in OpenStreetMap for routing to succeed in all directions. Details on these problems are found in our instructions too.
How will we find the platform points?
The best thing with OpenStreetMap is that we may extirpate two avians with the same stone, so to speak. In addition to all the walking routes and biking routes, we will get all the platforms we want to route to with a single clever query to the OpenStreetMap Overpass API. The Overpass API is meant for fetching a limited number of interesting features within a bounding box, as opposed to downloading the whole extract.
Since HSL uses OSM for routing, all the train platforms are found in OSM, and in most cases they were connected to nodes making up the walking network. This includes cases such as underground station platforms, i.e. most of the metro and the railway airport branch. In some cases, connections had to be added or fixed.
Platform polygons are located in the right location underground, and the walkways, elevators and escalators underground across different levels, all the way to the building exits, are similarly found and routable. All we need to find are the final points themselves (underground or above the ground, it does not matter) we want to reach.
OpenStreetMap offers a separate tag "railway"="platform" that we will use. With a bit of Overpass Query Language, detailed in our instructions, we may take 1) points at platform edges, 2) points at walkways, escalators, elevators, steps etc. and 3) find those points that are both platform edge points and connect to a walkway, elevator, steps, etc. This gives us a surefire way of finding all the ways a platform can be accessed from the outside. You can run the ready-made query yourself at the excellent Overpass Turbo web service.
Let’s put this together
Then, like in the school case before, we just run GraphHopper that contains Finnish data with our QGIS Catchment Plugin, using as a point layer all the points from above. A few features were added to the newest version of the Catchment plugin to make this use case easier:
- the user may combine multiple isochrones into one. This is done so that a single isochrone is obtained for all the dozens of entrances to the same station. In essence, then, the isochrone tells us how long it takes to reach *any* platform at the specified station. This is not necessarily the specific platform the transit user may need to reach at the moment, though. To group isochrones, we need to know which points belong to which station, details on how to find out the station name for each entrance are found in instructions.
- the user may add a specified distance of meters to the isochrone. This is needed for an edge case not mentioned before: also approximate distances to the future Länsimetro Metro western extension, due to open in 2023, were needed. This is of course impossible with only OpenStreetMap data, as the walkways do not exist yet. Approximate underground walking distances and approximate future entrance points were obtained from Länsimetro documents and plotted manually in QGIS. Instructions detail how this was done.
What do we get?
We get a lot. As an example, let’s check the 15 minute biking distance to a representative suburban railway station, Pukinmäki:
The fun thing about the bike routing is that in Graphhopper, it is rather advanced. While walking routing assumes a constant walking speed, bike routing depends on the quality of the route, surface material and lots of other factors. Highest speed is reached on dedicated bike lanes. To get results similar to old HSY defaults, a maximum bike speed of 15 km/h was set in graphhopper; the details of the settings are found, again, in the instructions. The minimum speed will be 5, 4 or even 3 km/h, because the bike is pushed on stations, on stairs, paths etc.
The underground stations will result in some quite funny looking isochrones at small distances. This is because in some cases, the transit user will have to walk over 200 meters to even get above the ground in the first place. Also, with very small isochrones, there are not a lot of roads to go by, so we might just get a triangular sliver around a single path. Cases in point are some future Länsimetro stations (Finnoo), Airport as well as downtown stations (Sörnäinen):
What does “isochrone” mean? What are the use cases for the polygon?
The main problem, as in the previous school isochrone study, are areas where there is no road network. In the case of schools, this meant unmapped countryside, which will get funny results. In the case of Helsinki, the road network is very well mapped.
Therefore, the only areas with spurious polygons are those which have *no* network and access. The most obvious example of these, of course, are the sea and bays Helsinki is known for. Essentially, we would need extra layers (where are the seas? where are other unaccessible areas?) to cut the resulting isochrones with to get results that look more sensible. The airport, similarly, is out of bounds, but the polygons may extend there due to lack of data. The instructions contain more details on this behavior; essentially, GraphHopper triangulates the whole surface based on the path network.
Unlike some methods that are based on the walked paths and assume areas outside the networks may not be accessed, GraphHopper assumes the area between the paths can be accessed. Which assumption is more correct really depends on the case.
This is really a question of what an isochrone polygon means, i.e. what does it mean to have access to a place next to a path? How far from the path can be accessed? The only results an isochrone calculation ever returns are the graph edges that have been reached. Building the surrounding polygon from those points is always pure guesswork, based on what is required from the results. Some cases might require a path be within 50 meters; in this case, larger blocks may contain population that is outside the isochrone. Some cases might require a path to be much closer or much farther away, and still should be contained within the isochrone.
It all depends on how dense the path network is, which are the areas outside the path network we want to be able to access, and which areas outside the path network we don’t want access to. That will have to be defined first, to get isochrones with the desired properties. No single isochrone calculation method is ever the absolute truth, because physical reality is not a graph of paths. More data may always be added to improve the accuracy for each desired purpose.
The future
Personally, the most interesting study for me would be to extend this methodology to all existing and future tram and light rail platforms in the Helsinki region. The data is already there for the taking.
Such a study would nicely complement the heavy rail platforms considered here; the regional and also City of Helsinki goal is to zone next to light or heavy rail as much as possible, so the heavy rail access detailed here is only a part of the equation. Even large areas of downtown, including many of the most populated neighborhoods in the city, lie outside the heavy rail network, and the light rail network in Helsinki is rapidly extending to meet the demands of the growing city.
