OpenStreetMap logo OpenStreetMap

Public Transport Plugin

Posted by Polyglot on 1 July 2016 in English. Last updated on 6 July 2016.

Mapping public transport routes on OpenStreetMap can be a challenge, keeping them correct and up-to-date even more so. Last year I mentored the Mapillary plugin for GSoC. Before that, I had been working on public transport a lot, and to add the stops precisely where the poles are, horizontal imagery is a big help, when it’s available. The idea to propose a GSoC project for public transport this year was a logical consequence of some Python scripting I had started on. It’s possible to run Python in JOSM, but it involves too much setup for it to be practical for general use by other mappers.

Still, automation is key. Without it, it’s next to impossible to even find all the problems with the route relations, let alone fix them.

Also the way we’re mapping public transport, at the moment (who knows one day route segments become the thing), is very repetitive and fixing all those routes for all variations of the lines gets tedious fast. This in turn results in very few people interested in doing it. And the ones that do burn out sooner or later.

I’m sure the new plugin will be a big help to solve that problem.

At the moment the plugin is very good at detecting problems with the routes:

  • going against oneway traffic
  • gaps that are caused by wrongly ordered ways (automatic fix available)
  • routes that don’t start/end on a stop_position node
  • ways that still need to be split on those terminal nodes
  • buses or trams that travel over ways unsuitable for that mode of transport

The latest addition is a dedicated extra layer. This layer highlights the route for which a relation editor window is open. You can have several relation editor windows open, but only the last one that had focus, will be shown highlighted. One thing that I was never able to achieve with plain MapCSS is to show sequence numbers for the stops and the platforms. The other was showing the refs of all the route relations serving those stops. All that becomes trivial (compared to MapCSS) if one can code it in JAVA, and Darya is doing a great job there.

So, what’s next?

The initial idea was to be able to start from a route relation containing just stops in the correct order and have the code figure out which ways to add to the relations. That will still happen, but fixing existing route relations and helping all mappers to keep the route relations ‘coherent’, when they make changes to the underlying highway/railway infrastructure is a higher priority, so we started by integrating the plugin in the validator. Thus making it very accessible for anybody who installs the plugin. It’s amazing how many problems have already been able to solved - both in the routes and in the ways they followm, as in the platforms and stop_positions -during beta testing of the code.

Want to try it yourself?

You can easily install the PT_assistant plugin in JOSM and help with testing.

User documentation can be found here

What I usually do, is File / Download from Overpass API (expert mode needs to be on for it to show that option in the menu, don’t ask me why) Then use the following query:

out meta; You can select routes for other modes of transport, of course. After downloading, I make sure nothing is selected, then press the validate button. ![Screenshot of dialog]( I usually use the last option, as I don't want all the fixes applied automatically for the time being. Implementing automatic fixes with user intervention where there is doubt, is in the pipeline. If you have the plugin installed, you'll find several categories that start with PT_ ![Screenshot of validator pane](

The easiest ones to tackle are: * Route contains a gap that can be fixed by sorting

For those you can simply press the fix button. Don’t select more than, say 5, at a time.

If your stops where not at the beginning of the route, now they will be. The order should be preserved. If they don’t have roles, select all of them, make them selected in the editor window, remove them from the Relation Editor and readd them. Now go visit the ones that still don’t have roles and fix their tagging.

Now press the upload button, which will result in a new validation Usually you’ll find there are more problems to solve at this point. For the routes that have ways going against oneway traffic, pressing the fix button will result in removal of that way. It’s better to press right mouse button Zoom to problem, select the way(s) that have a yellow casing around them, then press right mouse button edit. The relation editor will open with those ways selected in blue. Now it’s possible to remove them, or to add oneway:bus=no, if that is the proper solution. If you remove them, you probably want to readd ways from the other side of the dual carriageway or roundabout. If you notice that there are several variations, which are likely to need the same fix, keep the ‘problem ways’ selected and open all of them in relation editor windows. After all are openedm select the ways to replace them with, and do this in each editor window.

Be careful not to split ways for which you have relation editor windows open.
You'll get 'conflicted with yourself', which is something to avoid at all cost :-)
Have a look in the comments to learn how to avoid conflicts while keeping RE windows opened.

All this may seem like it’s still a lot of manual work and you’re right, it is. The intention is to automate all this further. I’ll probably write a new diary entry in a few weeks about that.

If you’re interested in a hangout about the mapping of public transport and the use of the plugin, get in touch and we’ll set one up.


Comment from dvdhoven on 1 July 2016 at 19:36

Very interesting!

From version 9979, you can split a way with the relation editor window open. There are 2 buttons in the upper left corner of the window. With the second from left you put the content of the relation window in JOSM This is what you have to do before splitting or connecting a road. With the most left button you synchronize JOSM and the relation window after splitting a road (P) or after connecting two roads (C) When you use these two buttons, the right way, you don’t get conflicts

Comment from Polyglot on 2 July 2016 at 11:33

Oh, that is very interesting indeed! Thanks for that tip. I’ll probably work it into the diary entry.


Comment from IIVQ on 8 July 2016 at 22:59

I love the plugin, but it causes frequent crashes when I work with stop_areas. I have filed a bug.

Comment from Stephen214 on 11 July 2016 at 20:21

When the stop_positions aren’t in the right order, instead of saying that, it gives an odd error that the start/end ways need to be split. Also, tells me that some (not all) of my stop_positions aren’t part of a way, but they obviously are just by looking at them (and confirmed by moving them, which drags the way). Not sure why it’s doing that–and inconsistently. Does it do anything with stop_areas or platforms? Didn’t get any errors, but I don’t know if that’s because I actually got them right or that’s just not implemented (yet).

Comment from Polyglot on 11 July 2016 at 20:44

Hi Stephen,

Are you working with version 23623? I still need to test with that one, but I also found an inconsistency, when stop_position nodes have the highway=bus_stop tag. I mentioned that this morning, so it could be solved in the latest version. It’s still work in progress.

About the first comment. For the first and last ways, I think it makes sense to split them on the stop_position node, as the part before, in case of the first stop, and the part after, in case of the terminal stop, aren’t part of the routes.

Checking whether the order of the stops is plausible, wasn’t implemented yet.


Comment from IIVQ on 13 July 2016 at 21:11

@Stephen Sprunk: I got the same message about a stop_position not being on a way. The problem was that it wasn’t on a highway=*. I laid out a nice bus station but forgot to actually tag the ways as highway=service.

Comment from pantierra on 3 August 2016 at 09:25

I’m having a similar issue with the order of stops in the (bus) route relations, as described by Stephen, the plugin throwing the misleading error messages of “start/end ways need to be split”, but instead the order of bus stops within the relation is mixed up.

Also, an automatic fix of this would be very helpful. Especially because the “Sort relation members” in the “Edit relation” window is not able to sort stops in based on the itinerary. It seems to me, it’d probably rather resort the stops without notice for unaware users. This way it’d be very easy to destroy the work which has been gone into manual sorting.

Comment from pantierra on 3 August 2016 at 09:26

And a really big THANK YOU for this plugin! It has already being so useful! o/

Comment from Polyglot on 3 August 2016 at 15:46

The reason why we didn’t emphasize this resorting of stops is that there was already a plugin for PT which does add the stops, starting from the ways itinerary in the route relation. I’m going to download Managua and see if that works as a workaround. It would involve removing all the stops and I have no idea if it would even work with the stop_position nodes. That other plugin was coded a long time ago. Let’s see if we can still include that functionality in this plugin as well.

The basic idea was to start from an ordered list of stops though, as that is what I’m usually doing, so it’s more ‘import’ geared than the other way around.


Comment from Daniel Benavides on 26 August 2016 at 21:39

HI, great work.

I want to share our work tracing our city routes.

Log in to leave a comment