Relaunch of the Public Transport Views

We recently rewrote the Public Transport views of our OSM Inspector. The old views had been used rarely and were of limited use, so we went for a full rewrite. While the old views aimed to give an overview on both the infrastructure and the network, the new views are focussed on the routes and stops.

The public transport schema used today was proposed back in 2010/2011 but it was adopted rather slowly. Also, many mappers made lots of mistakes when trying to use the schema because the documentation on the wiki was confusing. To clearly distinguish public transport mapping that follows this schema from old-style public transport mapping, new schema is now called “public transport v2” – even though there really wasn’t ever a version 1.

The new views of OSM Inspector try to support good mapping according to the “public transport v2” scheme, and act as a validator.

Here’s how you can use the two new views to do some public transport mapping:

The Stops View

The Stops view shows stop positions and platforms (multipolygons are not supported yet). Go to an area you are familiar with and check if there are missing bus stops. Use this view on zoom levels 10 and 11 to spot (rural) areas where no bus stops are mapped at all. Just take your car or bicycle and visit them!

Platforms are rendered in blue, stop positions in green. Bus stops with highway=bus_stop but without a public_transport=* tag are rendered in orange. They are not errors if they are the only object that represent a bus stop (per direction).

The Routes View

The Routes view shows route relations which claim to be v2 route relations (they have the tag public_transport:version=2). The view shows whether a route is valid (green) or not (black) and highlights objects which are either the reason of invalidity or which are located next to the invalidity (orange and purple).

When is a route valid?

The tagging schema defines minimum requirements a route must comply with:

• The order of the members of the route is important. The list of members is not an unordered collection.
• One route relation represents only one variant of a line. Therefore, you need at least two route relations for most lines, one for the forward direction and one for the backward direction.
• The first member is the first stop of the route (where it starts). It either uses the role stop or stop_entry_only.
• The second member is the second stop of the route and so on.
• If a stop is mapped by both a stop position and a platform, add both to the relation but the stop first and immediately followed by the platform. Platforms use the roles platform, platform_entry_only or platform_exit_only.
• The list of the ways the vehicle uses is at the end of the relation member list (i.e. after the last stop). These ways use an empty role.

(Even though many mappers seem to think so, you do not have to map both the stop position and the platform. One is enough. Especially for vehicles where the platform and the vehicle are short, adding stop positions is overkill. But if a stop has both, both have to be added to the route relation.)

A correct route relation of a bus line would look like this (roles are given in parentheses):


- stop position of station 1 (stop)
- platform object of station 1 (platform)
- stop position of station 2 (stop)
- platform object of station 2 (platform)
- ...
- stop position of station n (stop)
- platform of station n (platform)
- first way with highway=* ()
- second way with highway=* ()
- ...
- last way with highway=* ()


That’s how it would look like in JOSM’s relation editor:

As said above, mapping both stops and platforms is not mandatory. One of the two is enough. (If you know the location of the platform and/or the bus stop sign, add it. Otherwise the stop position is a good replacement.) Therefore, the route could also look like this:

What does OSMI currently check?

To get quickly a working validator, we decided not to implement all checks. Here is the list of implemented validation tests:

• A route must have stops or platforms.
• A route must have members which are neither stops nor platforms.
• Member nodes must have one of the following roles: stop, stop_entry_only, stop_exit_only, platform, platform_entry_only, platform_exit_only.
• Member ways must have one of the following roles: stop, stop_entry_only, stop_exit_only, platform, platform_entry_only, platform_exit_only or an empty role.
• Member relations must have one of the following roles: platform, platform_entry_only, platform_exit_only.
• The member list must begin with the list of stops and platforms.
• There must not be any member with a non-empty role after the first member with an empty role.
• Train, tram and subway routes must use railway tracks. Buses and trolleybuses must use roads. Trolleybuses need trolley_wire=yes (or trolley_wire:forward/backward=yes). Roads/tracks under construction trigger errors.
• The route=* tag of a route relation must have one of the following values: train, tram, subway, bus, trolleybus, ferry, aerialway.

There are some ideas for more tests but they haven’t been implemented yet:

• Correct order of stops and platforms is not checked.
• It is not checked if all stop positions of a route are located on a member way with an empty role.
• There is no test which checks if platforms are located next to the route/stop position.
• Access tags of member ways are not checked.
• If a platform is followed by another platform, users who follow the schema exactly will read two stations. If both platforms share some nodes, it is very likely an error.

osmi_pubtrans3 is free software, and patches are welcome.