OpenStreetMap
It seemed like a good idea on the face of it. Stops on the highway became public_transport=stop_position, stops next to it public_transport=platform.
But then it was suddenly necessary to add both these objects to the route relations. Already the fact that more than one object became necessary to describe a single bus stop, should have raised alarm bells.
There are, of course, some positive things to say about to say about the new scheme. A route_master relation for a whole line. route relations to describe the various itineraries and stops.
But the stops, that’s where it goes seriously wrong. Why on earth is it necessary to add 2 objects to those route relations? As they describe all the variations, there are a lot of them. Lots of work to maintain them. And they break easily.
After the scheme was voted, I was trying my best to map stops according to it. I had my highway=bus_stop nodes which were all nicely positioned next to the highways, so it’s clear on which side of the road they are located.
So I asked on the mailing list: hey what public_transport to use for them? The answer was public_transport=platform. So far, so good.
Since I had 40000 stops to add for half of a small country, I was not going to bother with adding stop_position nodes as well. So I trudged along for a few years.
In the mean time in Germany and France they had a different idea, let’s convert those nodes next to the highway to platform ways (regardless of whether there was an actual platform present in some cases), oh and those stop_position nodes, let’s duplicate all the details for the stops.
So, for the sake of simplicity, I would like us all to come back to our senses. Map each bus stop, exactly once on a node next to the highways and only add these nodes to the route relations. That’s how I will continue to do it in Belgium, although unfortunately in Brussels somebody already started adding stop_position nodes everywhere and adding them to the route relations. Oh well.
So I’m not sure if it will ever happen that we all move to a more sensible scheme, but in case it doesn’t, I promise to continue moaning and bitching about this overly complex way of mapping public transport.
Polyglot
Discussion
Comment from gileri on 8 July 2018 at 19:47
Why not just map the platform as you prefer mapping only one node and let other mappers map using the complete PTv2 scheme ?
That way you can keep adding correct and PTv2-compatible data into OSM, and everyone is happy.
Comment from Polyglot on 9 July 2018 at 05:24
Because there is this perception of some that mapping the stop on a node, with the details on that node exactly once, and having just these nodes in the route relations is somehow incomplete or even incorrect.
At present the wiki is interpreted as if the end goal is to have a platform way next to the road (for some regardless of the actual presence of such platform) and stop_position node on the highway as the only solution that is PT v2 compatible.
I can’t follow every edit happening on the wiki, but I did make sure that is still says that having a single public_transport=platform/highway=bus_stop node next to the highway and having just this node in the route relations IS fully PT v2 compliant. There is no need for futher “improvement”, when mapped that way.
Now, if there are actual platforms, it’s perfectly fine to map them as ways or areas, but they don’t need details like name, ref, etc. (Those are already present on the nodes that represent the stop). This doesn’t limit the ability to map stops in ever more detail, but doing so wouldn’t affect the route relations.
And I would like to see that we move to a solution where the end goal is to have a single object that represents a stop for each stop. Call it PT v3, if you like. The way it’s interpreted now from the wiki is too complex and hard to maintain.
There should be no need to ‘convert’ from that basic node that can be used for a simple bus stop to a way/area at any point in the lifetime of the bus stop. No need to update the route relations, or ‘augment’ them by adding stop_position nodes as well.
A single object for each and every bus or tram stop on a node next to the highway/railway. That’s what I’m saying.
Comment from Warin61 on 9 July 2018 at 07:12
Keep it simple .. for stupid people like me.
I have four PT v2 routes that I keep an eye on. They have the bear minimum to satisfy OSMinspector and one other QA tool. I’m not going to add anything to them. They do get broken occasionally by well intended other mappers from time to time, but that is life.
I am yet to do a diary entry on them .. and post it off to ‘my’ local mailing list so others can see how to do it - the easy way without any unnecessary additions. There are quite a few broken PT v2 routes .. they are simply PT v1 routes with the primary tag changed and little else as far as I can see. So making a simple guide as to how to fix them will be my contribution to getting others to fix them. At least it may help reducing the number of times they get broken. :)
Comment from Polyglot on 9 July 2018 at 10:17
Mapping of public transport should be within reach of all mappers. At the moment most say: it’s too complicated, leave it to the experts. Of course the ‘experts” don’t have enough time to mend millions of route relations around the world.
Converting from the old style to the “v2” is not a trivial exercise. Some mappers tag them as public_transport:version=2 just to make the validator shut up about them. They must not have the PT_Assistant plugin installed, as that one would make a lot of noise about them. The right thing to do is to put public_transport:version=1 on them. Or convert them, of course.
I’ll do one just to show what is involved (and how PT_Assistant can help with the task, even if it can’t do it all automatically, as those v1 relations are mostly useless except for giving a rough indication of which streets the buses use.
I created 2 screencasts with a demo of how PT_Assistant can be useful for such conversions.
https://www.youtube.com/watch?v=INgzu9h9zk8
https://www.youtube.com/watch?v=3zZ88g56o30
Those Blacktown routes should be verified further though, that relation I started with was ‘almost’ v2. Usually a v1 has stops for both directions, this one didn’t.
Comment from gileri on 10 July 2018 at 19:56
I have this perception, the place where the vehicle stop on the way and the place where people wait are not the same place, and can have different attributes (light, accessibility etc.).
The end goal of OSM should be to map precisely data even if it requires a bit more complexity (the world is complex really)
Why should you care whether your way of mapping is “fully compatible with PTv2” ? As long as it doesn’t add invalid or duplicated data or makes it hard to enter more complete data later, I don’t see any problem.
See my first answer
That’s your opinion. I find it adequate to map what is on the ground.
Comment from gileri on 10 July 2018 at 20:06
Adding two points, linking them in a group and adding those two points to related routes doesn’t sound unfathomably hard. If it’s too hard, maybe entering PT data into OSM isn’t for this person ? That’s why we have software like StreetComplete where contributions can be made without any prior knowledge, with a limited scope to reduce chances of error.
Data upkeep will always be a more more heavy-duty that adding a single shop for example. I don’t see why PT overhauling task specifically must be done by anyone.
Comment from Polyglot on 10 July 2018 at 20:17
I don’t mind adding the detail. We describe the world in ever more detail and precision, that is just fine. When adding detail starts to mean that complexity increases, that’s where I disagree.
When each and every stop is represented as a node, we can add shelters as an area, platforms as ways or areas. stop_position nodes if you must. waste_baskets, benches, all you want.
But the basic premise should be and remain: map the stop on a node next to the highway/railway. That node contains details like name, ref, operator, network, route_ref, etc. And that node is added once to the route relations (or several times if the vehicle serves it more than once on the variation represented by that route relation).
This works perfectly fine, without creating the need to add more than one object to the route relations. AND without the need for duplicating details across several objects.
Polyglot
Comment from Anton Khorev on 12 July 2018 at 17:24
Tram stops were typically mapped on the tracks, so they were “stop_positions” in PTv2 terminology, unlike bus stops that were mapped on the side of the road. Stop position also makes it easy to detect if it’s no longer on a route when the ways included in the route change. If I had to redesign the schema to have only one object per stop in a route relation it would be a stop position. Then there would be an option to add a relation that would include stop position and all extra details like platforms and shelters.
Comment from LeifRasmussen on 18 July 2018 at 15:41
I map bus routes without stop position, just a node at the pole. I don’t think having stop position is really necessary, because a computer can figure it out in less than a millisecond. I just have platforms and streets in the bus relations.
Comment from gileri on 20 July 2018 at 22:29
To clarify, I do not bring DWG threats at all. I just state that the discussed edits can easily be considered controversials. DWG usually revert whole changesets, or whole series of changesets, even if there is “good” data mixed in between. I have been of the receiving end of the DWG revert hammer, and have witnessed reverts of other contributors which were a bit heavy-handed. I am not asking of DWG to intervene, and I think never did before.
OSM diaries are not “safe space”. Publications here, especially ones who call for undifferientiated mass edits, will be challenged. And challenging ideas is precisely what Polyglot and Glenn Plas are doing when they want to “align heads in the same direction”. Same direction being away from the PTv2 status-quo.
I tried to state that Polyglot is obviously a heavily implicated OSM contributor, that they bring value to OSM, just like me and a lot of contributors. But even very smart people can do dumb things (I do too regularly), and I think this blog post isn’t contributive. That doesn’t belittle him, or his achievements at all.
Regarding the voting system, I agree with the example you stated, and some proposals results may be bad because of such voting issues. PTv2 was not such a proposal; it was clearly almost unanimous, with 83 positive votes for a total of 92 votes.
I do not need to state what I think that PTv2 brings to OSM because it is already documented in the PTv2 proposal. I’ve already tried to adress my concerns in a previous diary from Polyglot, who unfortunately didn’t give answers to the points I raised.
And while I didn’t edit as much PT as Polyglot did, I have overhauled a big chunk of the OSM PT in the third largest city of France, and developped a PTv2 viewer : https://gileri.github.io/OSMTransportViewer/ (not great, but it mostly works), so I’m a bit familiar with PT/PTv2.
Comment from gileri on 20 July 2018 at 22:31
Blast! I meant to post my previous answer here
Comment from Polyglot on 23 July 2018 at 07:12
Hi Gileri,
I don’t oppose mapping public transport in great detail. I think the basic premise should be as simple as possible though and it should remain the same for a simple bus stop with nothing on the ground or one with all amenities and features.
That’s why I’m saying we should map them all on nodes next to the highway/railway. Add all the details once to these nodes and only use these nodes in the route relations.
Then one can start adding platform ways, shelters, benches, waste baskets, stop positions of the vehicles if you must, electronic displays, tactile paving and so on. There is no limit, but it can all be done in addition to the one node that represents the stop and there should be no need to change the route relations nor to ‘upgrade’ that node to a way/area.
Comment from Mateusz Konieczny on 11 May 2019 at 11:12
This is completely unreasonable because standard
highway=bus_stopis much simpler. Ptv2 made it significantly more complicated without a good reason.