In 2012, the ‘new’ public_transport scheme was voted. What seemed like a good idea at first, has not led to unification though. I was not smart enough at the time to see how this would develop, but today with the benefit of 20/20 hindsight it it’s apparent that we are on the wrong track.
The way the wiki formulates it at present, even though I have tried over the years to keep it in check, we should supposedly map 2 objects for each and every stop and then add both of these to the route relations.
I’m sorry, but that is unacceptable! For one thing, I need a SINGLE object, preferably a node where all the details of the stop go. That has always been the way we do things in OpenStreetMap. The node that gets the stop_position tag is NOT suitable for that purpose, as it is not immediately apparent on what side of the street the stop is.
So, over the years I have tried to work with public_transport=platform and stop_position tags on the stop nodes I’ve been mapping. The idea was that, in time, highway=bus_stop would be replaced by those tags. Only that is not possible, for one thing, those nodes we’re mapping to represent the stops, were not supposed to have a mode of transport on them. So it is utterly impossible to drop highway=bus_stop from those nodes.
OK, let’s step back for a moment: highway=bus_stop is here to stay, wait for it… it’s coming… the conclusion: public_transport=platform tags are NOT ADDING any information. highway=bus_stop says it all. Sorry that it took me a few years to figure that out!
Of course, now the epiphany dawned on me, I decided to revisit all 70000 bus stops around Belgium. So since yesterday I started to remove public_transport=platform/bus=yes tags from all those stops, in packages of about 100-150. Obviously that’s not all I’m doing, some stops have moved, we have better imagery now than we did 5 years ago, there is a new bus_bay tag since last summer. It will take 6 to 12 months to complete this mission, but soon those tags that don’t add actual information will disappear from sight.
It’s time we came up with a scheme to map public transport that is:
* easy to work with
* easy to maintain
* easy to visualise
* does not duplicate information
* does not force mappers to add 2 objects to route relations
I have a clear vision of how we can accomplish that.
Comment from Wynndale on 19 July 2018 at 20:03
You need to think very long and very carefully whether undiscussed mass edits help your cause. Perhaps you need to think whether you really want to be editing OSM at all right now.
Comment from Polyglot on 19 July 2018 at 20:26
Believe me, I have been thinking this over for several months, even years by now. It’s only recently that I start speaking out about it. If mass edits take months to complete, they are actually regular mapping. Most of those bus stops have been added by yours truly, by the way. Like a fool I have been adding public_transport=platform/bus=yes, in addition to highway=bus_stop to them.
Hopefully it can serve as a wake up call that there is something fundamentally wrong with the public transport scheme as it is described at present on the wiki.
Comment from gileri on 19 July 2018 at 20:32
Removing a wildly used and growing valid tag, which has been properly voted on, is silly. But bragging about removing it without concern is dumb, Using terms like crusade, mission, epiphany sounds burlesque and doesn’t help your point of view.
I am a simple contributor, but I ask you to please stop immediately removing removing without discern ‘public_transport’ tags, as I and many other see value in those.
Also, please split removal of public_transport tags and data input/update into different changesets. When doing very controversial edits, mixing such edits puts “good” data at risk of removal if people (DWG or otherwise) reverts your changesets. Even if I don’t agree at all with your methods and choices, it would be sad to lose the value addded in those changesets because it is hard to separate the “good” from the “bad”.
Comment from Polyglot on 19 July 2018 at 20:52
I’m in big part responsible for the growing use of said public_transport tag.
Something I want to apologise for.
Anyway, as soon as a node has the highway=bus_stop tag, it’s a bus stop for all intents and purposes.
The initial plan was to remove those highway=bus_stop tags some day in a very distant future. It’s either one or the other. But I won’t cooperate in the madness of adding tags that don’t add information anymore.
I’m all for standardising, but we’re moving in the wrong direction.
Comment from RobJN on 19 July 2018 at 23:48
Yeah I never understood the two node public_transport scheme. It always felt like “tagging for the routing engine” to me. Map what is there - i.e. a bus stop sign or shelter by the side of the road. If you want to mark that it is associated with other stops nearby then do this via a relation.
Anyway, I barely have time to map bus stops with one node. Let alone two!
Comment from Warin61 on 20 July 2018 at 08:00
If data consumers need to have bus=yes and public_transport=platform to highway=bus_stop then let them add it as part of there filtering. Yes you can argue that ‘bus platforms’ exist .. but I’d simply don’t map them .. there is far too much to do without that. Fail to see why you need the platform when you have the stop, that is close enough for people to use.
Comment from Polyglot on 20 July 2018 at 09:15
If there are platforms, I don’t mind adding them, lately I switched to tagging them with just highway=platform/railway=platform though.
Those are not the central objects representing the stops though. And no, the stop_position nodes on the way are not suitable for representing the stops either. Just in case someone is going to propose to do that.
What I’m trying to say is, stops can be mapped in as much detail as the mapper has time for, but the basic principle of tagging stops should be to keep it as simple as possible and I think it’s important that stops tagged in the middle of nowhere without even a pole and stops in a busy metropolitan with all possible amenities like bench, shelter, electronic display, wheelchair enabled platform and tactile_paving, should be mapped in exactly the same way. i.e. on a node next to the highway and all the other amenities mapped as separate objects.
When I look around, I see there is a lot of confusion. People who use stop_position, because they understand it as the position of the stop, instead of the position where the vehicle stops.
Others who map platforms as ways, even if there are no platforms in reality, just for ‘consistency’.
This is just one of the misunderstandings. The conclusion is that the whole scheme is confusing.
Adding 2 objects for a single stop (sometimes, not always) also makes it hard to determine how many stops there really are in the route relation that represents that variation of the itinerary.
Anyway, for a long time I’ve been trying to accomodate the public_transport tags, but lately I don’t see the point anymore. I don’t really care if we add them or not. What is needed however is a discussion on how we can map stops and bus lines in a way that makes sense and is accessible to all.
Comment from Glenn Plas on 20 July 2018 at 13:01
I agree, it’s a mess. You’re an authority when it comes to PT, the Belgian community knows you are very knowledgeable and have been working for a very long time on PT. Notice that the people here leaving DWG threats under the guise of a comment do not add any value to the discussion in the form of well formulated arguments.
Wyndalle for example suggests you stop editing all together, why I ask? Does he even realize how much this schema has been from your hand to begin with ? That would be a big NO.
Then we have Gileri, who at the same time states he’s a simple contributor that sees value in this tag among so many others but fails to state exactly which ones. If he wasn’t so concerned about the way and form you’re venting your frustration on - nota-bene - your OWN diary could have used the time to -type up a shallow comment- actually offer arguments and facts and show us where the value is but fails to do so. Next to being rude and besides the point he treats you like a beginner making sure DWG doesn’t have a too hard time undoing what he views is an error, and yet again fails to state why he things so.
The voting system is not a good argument, some proposals are used widespread while stil in the draft phase or even voted down, still we use it. when 10 people vote it’s accepted and it gives a false sense of acceptance and a delusional feeling that this somehow validates doing something wrong.
What we need is a discussion at the core of the problem. To address the pitfalls and to align all heads in the same directions. I’m appalled at the level of vitriol you’re receiving here, all that energy would be put to much better use to really think about this ugly data-duplicating tagging scheme and come up with proposals and perhaps even a solution.
Comment from Zverik on 20 July 2018 at 13:54
You might be glad to know I’ve finished my proposal for PTv3 which addresses most of your concerns. Thanks for discussing it while in draft stage.
Comment from gileri on 20 July 2018 at 22:32
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 think I have enough credentials to have an opinion on the subject.
Comment from Polyglot on 21 July 2018 at 08:34
The reason why I’m editing quite a bit, is in part because I’m beta testing the new functionality in PT_Assistant.
What I’m seeing in some parts is an overly engineered scheme and in other parts a lot of confusion and misunderstandings.
The reason for posting my concerns about the whole scheme as diary posts, is because I really want to see some discussion on the topic. Preferably including the long tail of mappers who have mostly given up on trying to map public transport. Developing PT_Assistant is an attempt to include all mappers and to make it easier to maintain continuity in those route relations, of course.
For several years I have been trying very hard to adopt those parts of the public transport scheme that made sense to me. The result is that I often get the remark, that I’m supposedly not doing it right. Well, I don’t see value in stop_position nodes on the highway for bus_stops. I don’t see why we would duplicate details like name/ref/operator/network/etc. to more than 1 object and I don’t see why some mappers insist on adding 2 objects to all the route relations.
At present we have quite an absurd situation:
Comment from Snusmumriken on 21 July 2018 at 09:09
You might want to take a look at how bus routes are mapped in Stockholm. Since 2013 they been mapped according to a simplified version of PTv2. The documentation is only in Swedish, I’m afraid, but an example should give an idea:
All lines (1-898) follow this scheme although the coverage is not yet complete. The public transportation authority in Stockholm region also uses OSM in their webpage.
And at least one of the three companies that actually drives the buses have been in contact with the community on our mailing list to ask to update a route in OSM as it had changed IRL. I believe they use OSM routes internally.
Comment from Polyglot on 21 July 2018 at 11:27
That is just wonderful! Clean and simple. I might be tempted to create a screencast to show you how JOSM’s PT_Assistant plugin can help you to get those stops sorted automatically and check for continuity of the ways in the route relations. It would involve putting public_transport=2 on the route relations though. PT_Assistant ignores routes which don’t have that tag set, or have it set to 1.
Comment from Zverik on 21 July 2018 at 11:52
Jo, why do you insist on using “public_transport:version” tag? It’s not like there is software that requires the first one, or that there are two schemas in operation simultaneously. A route is either correct or not. To me (and my validators), a version tag with value of 1 is always an error, one of many, that needs to be fixed. Not a reason to ingore a route.
I think the decision to introduce the version tag was wrong, and I hope it will go away the same as stop positions and public_transport=platform. It does not add any information to a route, but provokes data consumers to make ill-adviced decisions, like ignoring routes or treating them differently — like the proposal for v2 wasn’t approved.
Comment from Polyglot on 21 July 2018 at 12:26
If the route relation has public_transport:version=2 PT_Assistant will start from the assumption there should be a continuous string of ways in them. If there isn’t, it can report a gap, or that while following the ways in that particular order, the bus travels against oneway restrictions. The plugin can then also suggest fixes.
When the ways for both directions are in the route relations, the plugin can’t do anything useful with the route relation, except ignore it. Those are the route relations that I would either tag as public_transport:version=1. So I can disregard them at that point in time and possibly come back to them later to deduplicate and convert them.
Comment from Zverik on 21 July 2018 at 14:25
Why disregard relations? Is “public_transport:version=1” basically a flag that means “this object has no meaning, please ignore but not delete it”? OSM is no place for such objects, imo. Or is it a note like “fixme=*”? In that case, a simple fixme would do, without any special tags.
Comment from Polyglot on 21 July 2018 at 15:06
I use public_transport:version=2 as a flag to say: this relation can be validated on the assumption there is a single continuous string of connected ways in it.
I use public_transport:version=1 as a flag to indicate this relation is not ready for such validation, as there is no logic in the collection of ways it contains. All we can safely say about these relations is that those ways have a higher probability of buses of that specific line passing over them. That’s not an absolute statement though, as such routes are most likely not maintained by anyone. So there might be too many ways in them, or ones that are not split where the bus turns off in reality.
Those relations are not candidates for removal though. If a dedicated mapper encounters them, it is possible to use them as a starting point for properly mapping what the vehicles do.
PT_Assistant can help with that too, but it involves a lot of manual work. I created some screencasts about the process: