I've been looking around and I see two main divergent "factions".
Basically the differences stem from how bus stops were mapped before v2 came along. Are the stop_position nodes the bus stop, or is it that place next to the road where the passengers wait. For those places where the latter is considered the way to go, I see nodes with highway=bus_stop (cause the rendering people never implemented the new scheme) public_transport=platform bus=yes name, ref, route_ref, operator, network I added/reviewed 70000 of those for Belgium. I didn't bother to add public_transport=stop_position bus=yes nodes for all of those. I did add them for the first and terminal stops (as I want to split the way there anyway) In some places the stop_position also get details. For me it becomes too complex to keep them synchronised, so I won't even consider to do that. If there is a platform, a way or area closedway gets tagged: highway=platform (to make it render) public_transport=platform The other faction is in some regions of Germany and some regions of France. I don't see it in many other places. There all the details go on the stop_position node. And then they draw a way to represent the waiting area and tag it: public_transport=platform bus=yes regardless of whether there is an actual platform present or not (they seem to need it in the route relations, because if you don't add those, you can't determine on which side the passengers wait and in which direction the bus will take off) Needless to say I prefer the first way of tagging, even though those platform nodes often represent the pole with the flag on it, but let's not muddy the waters by introducing a public_transport=pole. Nodes with public_transport=platform work just fine for the purpose. Now if the details are mapped on those nodes next to the way, then I fail to see why one would need to add the stop_position nodes over and over to the route relations (also keep in mind they are not necessarily always mapped in the first scenario). Reconciling both scenarios will be hard to accomplish, as everybody thinks they are doing it "the right way", myself included... I do agree that we'll need a solution for the route segments. To enable that, I think it's important JOSM's relation editor can show that a route is continuous, even when segment relations are used to build it. That's what I like about the current situation, a continuous line allows a visual check. Personally I'd also not add stops to those segment relations. Keep all the stops in the route relations for all the variations of a line. Polyglot 2016-06-20 9:07 GMT+02:00 Roland Olbricht <[email protected]>: > Dear fellow mappers, > > Is anyone interested in updating these tools? I can provide lots of >> input and testing, but my Java skills aren't where they need to be to >> attempt this alone. >> > > I'm the author of the public_transport plugin. I would be interested in > restarting development. It's not about Java skills, the problem is missing > consent about tagging or, more precise, the general modelling. > > There had been a group that was very vocal for making a textbook example > of design by committee, and the result is now known as "approved public > transport scheme". They did not ask for input from experienced mappers or > developers. I decided to consider it a waste of time and stopped developing. > > I'm not the only one. Tagging never really got traction, and only a tiny > fraction of stops conforms to that approach. This is why we have now the > mess we have. > > One example is the dissent on whether the bus stop should be a node on the > vehicle's way or a node where the passengers wait. You will find all > solutions implemented, because each local community decided different. The > "approved scheme" will allow any variant. It's even worse for where to put > the name: I got even within local communities incompatible answers, all > referring to the "approved scheme". > > Another example are route relations. While there are wild constructions > called route_master and network which are basically collection relations, > the problem that bothers most people in practice has never been tackled: We > would like to see per way segment only one or very few relations and need a > construction to assemble itineraries from that. That would greatly reduce > maintenance. And: how to tell apart services that run a few times per day > from those that have a headway of a few minutes? > > Given that, it would help have an algorithm to answer the simple questions > for real world examples and their current tagging: > - Where to start/end routing of passengers? > - Where to start/end routing of vehicles? > - How to obtain a name of a station? > There are probably more interesting questions. But it will be already hard > enough to tell apart unusual tagging on purpose (because of a special > situation) from mistakes and the various variants of taggings for these > three, and adding complexity (like more questions) had killed a lot of > prospective efforts. > > It's not enough if the solution works fine in your local area and > hopefully works somewhere else, more or less untested. We need an algorithm > to do the right thing in 95% or better 99% of all places around the world. > > Is this the right list to discuss mass edits to add the missing tags, or >> would it be >> local lists for each area, or somewhere else? >> > > Note that the hard thing isn't to write a bot that processes a lot of > objects. The hard thing is tell what we actually want. The bot has to > answer the above mentioned questions to actually do more good than harm. > > To make it clear: We need rules how to understand what we have right now, > changing at most 1% of all stops and stations or even less. Such a change > we inevitably need local knowledge, hence it is unlikely that a bot will > help. What we don't need is yet another standard. > > Best regards, > > Roland > > > > _______________________________________________ > Talk-transit mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-transit >
_______________________________________________ Talk-transit mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-transit
