Looking around using OSMinspector I find many routes are invalid.
Green ones are good, the black/grey ones are bad. You can zoom out (but need to zoom back to get the result) and pan around to your bit of the world.
Why are they invalid? And how to ‘fix’ them?
In my part of the world they look to be simply taken from V1 to V2 with no processing. And many of them are not ordered sequentially. It is simplest to do the minimum required to obtain a valid V2 route, but what is the minimum? Well .. from my understanding and experimentation the following looks to be required.
Bus stops at the top in sequential order from the start to the finish.
You don’t absolutely require all the stops but need the start and finish as a minimum, hopefully you’ll have a few more. These need each to be tagged as a node with the minimum of
to show the roads taken, again these must be in sequential order from start to finish. There must be no gaps. No need for roles here, forwards/backwards are not used in V2. The ‘role’ in the relation is left blank.
These are not essential, add them if you want.
The route relation can have tags for
As members all the relevant bus stops, or at least most of them. The stops too may have name=, ref= .. too much time required to gather these for me.
Use OSMinspector to check your route works to some degree.
Some Australian samples; relation 3550083 and relation 7258397.
If you really need more details then OSM bus routes .. I find it too long and tedious. The minimum works in the vast majority of cases, if you need more then you ‘ll have to read the long detailed text.
Train stops at the top of the relation in sequential order from the start to the finish.
You don’t absolutely require all the stops but need the start and finish as a minimum, hopefully you’ll have a few more. These need to be tagged as a node on the way with the minimum of
Some say these should be at the front of the train, similar to bus stops. Others say these should be in the middle of the train – the average of where passengers get on. I don’t care, neither does the software so it is your choice. I put mine at the front, as that is what was in the OSM wiki when I looked.
to show the tracks taken, again these must be in sequential order from start to finish. There must be no gaps. No need for a ‘role’ in the relation.
As members, all the relevant train stops, or at least most of them.The stops too may have name=, ref=.
Some Australian samples relation 3780904 (Newcastle to Sydney) and India Pacific, Perth to Sydney
If you really need more details then OSM Train Routes .. I find it too long and tedious. The minimum works in the vast majority of cases, if you need more then you ‘ll have to read the long detailed text.
The tag highway=bus_stop predates the public transport version 2 system, it is rendered in a nice way. The public transport version 2 system bus stop tags do not render but are required fore V2. Maybe v3 will make do with only the tag highway=bus_stop, that would make things easier for mappers.
Comment from Polyglot on 7 October 2018 at 11:48
Your link to OSM Inspector lands on verification of areas. I think this link works better for public transport itineraries:
Public transport issues around Melbourne
Apparently copy/pasting from the address bar doesn’t work, but there is a permalink option.
Comment from Warin61 on 7 October 2018 at 22:32
I have changed it .. so it now links to London where these are a lot of corrections to be made. :) That is where I intended it to go, just did not do the permalink thing.
Trust there are no obvious other errors?
Comment from Nakaner on 8 October 2018 at 14:12
Just a comment by the developer of the OSMI Public Transport (me):
The green colour is no guarantee that the route relation is 100% valid. OSMI does not check everything. For example, OSMI does not check if all stop positions are member of the roads/tracks used by the route and it does not check the order of stop positions and platforms.
Comment from Sam Wilson on 12 October 2018 at 00:35
Thanks for this Warin, it’s very useful.
Comment from TheEditor101 on 14 October 2018 at 10:10
I don’t think the bus route "platform" members actually need the highway=bus_stop tag, people just commonly double tag that because public_transport=platform is not yet rendered in the standard OSM map layer.
You may want to make this clear as technically it’s tagging for the renderer.
Comment from Warin61 on 14 October 2018 at 11:35
Yes it is ‘tagging for the render’ and ‘we’ all do it. A selection is made that is ‘recognized’ so that the result of the entry will render - hopefully with something that matches what is not the ground. The only reason why I’d use ‘landuse=grass’ is because it renders, I alway try to tag grass as what it truly is - ‘landcover=grass’!
I’ll make some change tomorrow.
Comment from Warin61 on 14 October 2018 at 11:37
Sorry … I’m tired. The above should read..
Yes it is ‘tagging for the render’ and ‘we’ all do it. A selection is made that is ‘recognized’ so that the result of the entry will render - hopefully with something that matches what is on the ground. The only reason why I’d use ‘landuse=grass’ is because it renders, I alway try to tag grass as what it truly is - ‘landcover=grass’!
Comment from TheEditor101 on 14 October 2018 at 13:38
I should have said in my original comment:
This is a great post! I’ve recently become interested in updating and fixing the bus routes in my area and also found that the wiki pages were not very succinct. My understanding matches yours and it seems much more approachable presented like it is here.
I’m also “guilty” of double tagging bus stops and areas of grass for the renderer as I don’t think it’s a big deal for these specific cases because both tags do reflect what is on the ground. It’s just good for newer editors to be aware of why they’re adding tags (i.e. the highway=bus_stop tag isn’t actually needed for PTv2, it’s just generally added because it renders).
Comment from Polyglot on 3 August 2019 at 07:21
In the mean time it became obvious (after about 7 or 8 long years) that public_transport=platform will never render, whether accompanied by bus=yes, or not. So highway=bus_stop IS necessary and will remain necessary. This, of course, begs the question whether public_transport tags are actually useful. Maybe we can simply drop them.
But if we do that, does it still make sense that the stops get a platform role in the route relations and the stop_area relations?
So many questions. I don’t have the answers. Back when PT v2 was “voted”, I came up with double tagging, but that was with the expectation that highway=bus_stop would one day become unnecessary. It won’t.
Comment from Warin61 on 2 April 2021 at 07:41
I have ‘done’ a number of train routes now. My thinking in the position of ‘public_transport=stop_position’ has changed to make it the centre of the train, not where the driver stops. Reason: Train lengths vary and with that the driver stop position changes, but the train center does not. The only exception to this are short platforms where the stop position is adjacent the centre of the platform.
This would be useful for passengers as an indication of where to gather for catching the train, there should be more of them than drivers and so of more use to most map users.
I think a similar thing goes for ferries … should be the entry position for the passengers or the center of them.
Buses however have the passenger entry near the driver, with a few exceptions.