Proposal talk:Drop stop positions and platforms

FAQ

Why not the opposite?

Well of course you can make 2 million bus_stop tags obsolete. If you start removing these, you'll find out that many people used old tags, users generally don't understand new tags, and using the data became harder: for example, because platforms don't have mode tags, like bus=yes.

Let's just replace old tags with new tags in iD!

The issue is, it is virtuall impossible to describe new tags to a novice. For iD, you'll have to come up with "A point on a highway or railway where an actual car serving the public transport route actually stops", but in two-three words.

Can it be solved with ditching just stop_positions?

Yes, but not entirely. We would still have highway=bus_stop and railway=platform. And introducing the public_transport=platform, you lose the distinction between the two.

But how do I map a platform for a bus_stop that's inside a highway?

That is one case when highway=platform makes sense.

And what about tram stops? Having platforms for these is important.

railway=platform. It has always been there.

I think public_transport=station has its own meaning and should be kept.

Great, so please document it, or better, make a proposal: the current definition of the tag duplicates existing railway=station, building=train_station, amenity=bus_station and others, losing the mode of transport and other details.

The Wiki page Tag:public_transport=station documents a difference: "While railway=station is about all railway stations (i.e. including cargo), the public_transport=station tag is used only on the stations interesting for passenger transport." U30303020 (talk) 11:18, 30 March 2018 (UTC)

Let's count the numbers and make an informed decision of what to keep and what to lose.

The issue I am trying to solve here is not the technical issue of having two simultaneous tagging schemas. It's the complexity for mappers and confusion. We cannot get rid of old tagging, since most mappers know nothing more and won't comply, not to say about software.

This is rather a pledge to attract new mappers. And people unwilling to read the wiki, mailinglist and other data from time to time, i.e. people unwilling to cope with (slow) changes should not be considered a priority reference to base decisions own. OSM is an open platform, it seeks to do change by evolution, and evolution is a slow, self-organizing process, rather than one driven by individuals or small groups of people. --Cmuelle8 (talk) 14:46, 28 March 2018 (UTC)

I believe only a negligible fraction of mappers read the wiki. And if they did, it is very hard to form a coherent understanding of the public transport schema, which is spread over dozens of pages. This is but a first step to simplifying it, thus making it more practical both for mappers and for users. --Zverik 15:51, 28 March 2018 (UTC)

Why not instead create a step-by-step tutorial with quality graphics, or a vid for better explanation? The problem I see with your approach is that we might drift to a state where things were over-simplified and thus ambiguous. The working group and the people influencing it seven years ago already have simplified the scheme to great extent, being careful not to introduce room for misinterpretation (which is easy to create, unintentional or not).

Discriminating features (not people) is a very important point for a tagging scheme, and thus it is important to not cram too many features into a single key. See, there are a lot of features already summoned by the values to highway=* and it is not a binary question which features should be tagged by kv-combinations associated with this key (its a fuzzy one). So by all means, it does make sense to sort features to a dedicated key that do not strictly belong to highway=*. This is exactly what the public_transport scheme did/does and there is no sound reason to dilute this, imho. For the same reason, we do not have, e.g. highway=ditch. --Cmuelle8 (talk) 16:12, 28 March 2018 (UTC)

Implications for stop_area

The proposal doesn't mention public_transport=stop_area. How would this fit into the new proposal? Would it disappear completely? Or be retained for trains and trams but disappear for buses, given that I think the proposal is that there would be just one node for a bus stop? --Alan gr (talk) 09:12, 19 March 2018 (UTC)

All relations introduced by PTv2 will remain. At the moment nobody knows exactly how to apply stop_areas to overground public transport, so you can continue using them as you like. The proposal only affects three tags it mentions. Regarding bus and tram stops, yes, I think we will continue mapping them as one node, though for tram stops it is recommended to draw a platform with railway=platform. --Zverik (talk) 09:33, 19 March 2018 (UTC)

Too complex indeed

My biggest beef with the public_transport scheme is that it hasn't led to a simpler system. Having to add 2 objects for 1 stop to each and every route relation just doesn't feel right to me.

The reason some want to do this, is because they want to add the node on the way to the route. Of course, then it's not clear where the passengers are supposed to wait, so then they want to add a way or area as well.

The way I had solved this, is by using nodes next to the way, adding all the details to these nodes, which conveniently have coordinates and only add these nodes to the route relations.

The public transport scheme wanted me to map these nodes as public_transport=platform, JOSM adds a platform role for them, when they are added to a route relation and the standard rendering stubbornly only shows them on the standard rendering if highway=bus_stop is added to them. Since I have all the details on these nodes, I don't see a problem with adding the modes of transport the stop serves.

If there is an actual platform for these stops, I map them as a way with highway=platform (and previously public_transport=platform). If there is tactile_paving or they are high enough to make it easier for wheelchairs, the relevant tags can be added. I don't see a reason to add these platform ways or areas to the route relations, nor is there a reason to add name or other details to them.

Then the stop_position nodes. Where I think they are useful, is at the beginning or end of the line (and then split the way on them). Along the itinerary, they are not important, so I mostly don't add them. I definitely don't add them to the route relations, and thus they don't need details like name, ref, etc duplicated on them.

I think this way of mapping can easily be used for tram and metro as well. I haven't mapped many train stations though. Since we were mapping railways as 1 OSM way object for 2 tracks initially, I can understand where mapping stations as nodes on these ways comes from, but today I don't see any problem with mapping them as nodes next to the railway. Drawing the platforms separately.

There are many more bus stops in the world than train, tram and metro combined. We need a system for them that is easy to work with for mappers and still versatile enough to enable mapping all the specifics.

Regarding the public_transport scheme, I made my peace with it, just like I made my peace with the idea that we will never be able to drop highway=bus_stop, so now I'm somewhat grudgingly combining them and using them to my advantage where possible. But Ilya is right in that it is hard to explain it all to new mappers. I made an attempt here: https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistant/Mapping_Public_Transport_with_JOSM (screenshots are at the bottom) and several times on my OSM diary.

If we do drop public_transport=platform/stop_position. I would like for JOSM to assign platform role when isolated highway=bus_stop nodes are added to the route relations, but that is trivial to implement.

--Polyglot (talk) 08:53, 20 March 2018 (UTC)

Implications for relation member role of bus stop?

Resolved

Should the relation member role of a highway=bus_stop stay platform? This could lead to confusion with stop for railway=tram_stop. --SelfishSeahorse (talk) 21:40, 20 March 2018 (UTC)

If they are on an isolated node next to the highway, I'd say yes. But, on the other hand, I'm starting to wonder what purpose these roles really serve, if any.--Polyglot (talk) 22:03, 20 March 2018 (UTC)

I agree with Polyglot, in the subway validator I use these roles only for tag validation. To me, route relations should contain a single object for each stop, unless there's an "entry_only" / "exit_only" platform. Platforms if possible, stops otherwise. In the current schema, a role of a bus_stop mapped besides the road would indeed be platform. --Zverik (talk) 08:44, 23 March 2018 (UTC)

Implications for bus platforms?

What should be done with public_transport=platform + bus=yes like here? Should bus platforms be removed from the route relation and should a highway=bus_stop be added to the route relation instead? --SelfishSeahorse (talk) 21:40, 20 March 2018 (UTC)

I would move all the details to this node: :https://www.openstreetmap.org/node/5467635385

And only add that node to the route relations.

On the platform way, I would simply keep highway=platform/wheelchair=no. I would draw the shelter as a closedway with amenity=shelter/shelter_type=public_transport.--Polyglot (talk) 21:57, 20 March 2018 (UTC)

Great question, for which I don't have an answer yet. I guess I'd add all the info to the bus_stop node, but then we're running into the same stop_position issue: if we make it a node inside a highway, we lose the platform connection, and if we lose the bus_stop node altogether, we find ourselves without a properly marked bus stop. I guess this will be one of the edge cases similar to PTv2, only with more understandable tags. --Zverik (talk) 08:49, 23 March 2018 (UTC)

Tram stop position vs bus stop position

Resolved

One goal of the public transport proposal was to remove the inconsistent handling of railway=tram_stop being placed on the way and highway=bus_stop being placed beside the way. If stop positions and platforms are dropped, this problem remains. Therefore, I think it should also be allowed to put railway=tram_stop beside the way – on the same node as highway=bus_stop if buses also stop there. Thus, the properties of the bus and tram stop don't have to be tagged twice and the rendered map would also be clearer (see here). --SelfishSeahorse (talk) 21:40, 20 March 2018 (UTC)

I've overlooked that the proposal reads "that you can set highway=bus_stop and railway=tram_stop on a single node if needed." --SelfishSeahorse (talk) 11:31, 23 April 2018 (UTC)

It didn't lead to more consistency, unfortunately. I agree that placing railway=tram_stop on nodes beside the way would be a lot better.--Polyglot (talk) 22:01, 20 March 2018 (UTC)

I partly agree with Polyglot: the change in tagging didn't really lead to any change in mapping. We still have the same issue, only with extra tags added on top. I prefer to think of this situation as a highway-railway dichotomy: bus and trolleybus stop nodes are places near a highway, while railway and tram stops are nodes inside a railway. Thus railway=platform ways are recommended for tram stops. But I am also not against placing tram_stops near the tracks. --Zverik (talk) 08:52, 23 March 2018 (UTC)

Other proposal: way from platform to stop position

Instead of mapping and tagging a platform node and/or stop position node, we should draw a way from the potential position of the platform node to the potential position of the stop position node, and tag this way only, e.g. as a bus stop. The way would be representing the boarding passenger flow. This way shall be mandatory (*1) and the only element (*2) of the stop, which is route member. Any physical platform can be drawn as an area and connected to the way defining the stop, but shall neither be a member of the route nor tagged with stop specific information (except of physical properties of the platform like height of platform ref).

Using the way to define the stop has several advantages:

• Consistent mapping of bus, tram, and railway stops.
• Renderer is free to render on the highway/railway or platform position, and might choose this dependent on the zoom level. And there is no issue of a potential duplicate rendering left.
• No duplication of data.
• One route member per stop only (*2)
• Allows simple and intuitive preset names in iD
• Stops are always connected the highway/railway.
  • This allows sorting and validation without loading indirect members of the route, because no geometry calculations are required. Especially for Web based or mobile editors, having to load all indirect members of a route can be hard or impossible (the theoretical worst case is 2000 ways with 2000 nodes each). Having to load 2000 direct members in worst case seems to be much easier.
  • Well defined splitting point at the ends of the route due to this existing connection, without requiring special handling of the first and last stop.
• The direction of the way towards the highway/railway defines a right and left direction along the highway/railway. This enables:
  • Tagging the direction of travel at the stop, which helps to validate and to sort incomplete routes,
  • Tagging the extend (to the right and left) of the zone for entering or exiting e.g. a train. In contrast the current stop position isn't able to define this zone, because how to place the stop position node based on the real stop position of the vehicle is undefined, and taging an asymmetric extend (e.g. when placing the stop position node where the front of the vehicle stops) is impossible due to missing.

(*1) Potential exception: Simplified mapping of the stop as a single node on the highway/railway might still be allowed.

(*2) Special cases might allow to add more of such ways with a special role: E.g. platforms on both sides of a train (Spanish solution), or multiple piers accessing a ferry simultananously.

-- Slhh (talk) 19:44, 1 April 2018 (UTC)

More mapping, less wiki fiddling

If people would have mapped more, specifically public transport infrastructure, then instead of trying to impose their views by dictation, this dropping proposal would not have been started all together. But its easier to bring about some wiki words, then to sit and map and tag. --Cmuelle8 (talk) 14:58, 28 March 2018 (UTC)

If by that you're implying I'm not doing any public transport mapping, you should have looked into my editing history for the past half a year. All this have come from the experience, not only in mapping, but also in rendering and making a public transport router. --Zverik (talk) 15:49, 28 March 2018 (UTC)

No, I'm implying that the mass of mappers (and wiki fiddlers) could have focused more on mapping in a coherent way. It's wishful thinking and I doubt it will change in the future, the words were not meant to assault anyone directly. See, it starts in the tools used - there are many, and some offer to map things (slightly) differently than others. Meanwhile, vespucci and josm share common presets, but these are not the only editors used. And it's far from easy to translate or find a common denominator of all of the opinions, suggestions and recommendations out there, that is then offered by those presets. This fact is another point, why imho we should stick and promote things that have been thoroughly worked on and thought about, rather than start to reintroduce past mistakes. And specifically that PT proposal has had lots of thought. --Cmuelle8 (talk) 16:32, 28 March 2018 (UTC)

I have been mapping public transport, vast amounts of it. I never dared to make bold proposals like this one (kudos to Ilya for speaking up), as I think trying to get consensus on anything is a hopeless endeavour, unfortunately. And even if you do get a vote to pass, it doesn't really mean much. I do feel a change is needed though, as I feel I'm working around the shortcomings of how some people interpret the scheme.

I see people adding multiple objects to route relations for a single stop. Because they think the stop_position needs to be added, but they also want to add the platform way. To make it look nicer in the overview of the relation editor, they add details like the name to both. Then they start adding platform ways, where no platforms exist, so the list of stops looks consistent, with 2 objects for each.

Having all details on 1 platform NODE and only adding that node to the route relations solves all that duplication and all of a sudden stop_position nodes become a whole lot less important.--Polyglot (talk) 15:52, 28 March 2018 (UTC)

Thanks for the (detailed) input. The problems you raise pinpoint to the need for validation tools, that check common mistakes made and raise errors/warnings before upload. JOSM e.g. has a great validation framework that may spot some of the things you describe, maybe a ticket on their bugtracker may aid to decrease the amount of mistakes made in this realm. --Cmuelle8 (talk) 16:20, 28 March 2018 (UTC)

Again, very few people even know about validators. And few people use JOSM. My opinion is that error count can be reduced by simplifying the schema, not trying to force every mapper to use JOSM and consult obscure validators. --Zverik (talk) 16:28, 28 March 2018 (UTC)

Again, I'm convinced the opposite will happen. You may attempt to make things simpler than simple, imho. The validator in JOSM is the main reason for the data to be half-way coherent. This ruleset is a "force of the past", if you will, but one that evolved and has been driven by observation of the mistakes made. Brushing it aside will lead to people making the same mistakes, and having the same discussions over and over and over .. --Cmuelle8 (talk) 16:38, 28 March 2018 (UTC)

Mixing PTv2 with older tags: What is the adventage of that?

As far as I understand, PTv2 did not replace previous tagging techniques. Proposed features/Public Transport says: "This proposal does not replace, deprecate or obsolete the already existing and well known tags. The usage of the proposed tags is recommended but not mandatory." I would understand that in a way that you still perform tagging to the wiki and the proposal if you do not use PTv2 and its public_transport=*.

You propose to make public_transport=stop_position, public_transport=stop_position, and public_transport=stop_position optional while still using PTv2 relations such as stop_area-relations or route_masters. So you intend to mix "PTv1" and PTv2, right?

I guess, if you want to have a straightforward tagging scheme, you will have to do mass edits either removing public_transport=* etc. or tags proposed by you. Additionally, the according wiki pages would have to get updated right away. Looking at the Russian version of PTv2 RU:Public transport or the manual once set up by Zverik RU:Общественный транспорт, I see some PTv2 features not yet displayed there (notably the fact that multiple tags are optional). This leads to confusion and wrong tagging and multiple tags being used to describe one feature, which is essentially the issue you would like to resolve.

I do not see how you would like to avoid this in your current proposal. That is why I do not yet see an advantage in it. U30303020 (talk) 11:59, 30 March 2018 (UTC)

Fighting the wrong enemy

When once it was enough to put a highway=bus_stop + name=* on a bus stop, now one has to read the proposal and check which tags should go on a platform, which on a stop position (do you remember where bus=yes goes?)...

No, according to the Public Transport Proposal, it is still enough to put a highway=bus_stop + name=* on a bus stop.

And turns out you also have to do double work, since there are stop positions for everything now.

No, according to the Public Transport Proposal, neither the stop nor the platform is mandatory. It's enough to have one of them. It's not mandatory to map them--it's only mandatory to include the mapped ones in the route.

By the time the proposal was made, we already had hundreds thousands of stops and platforms mapped, using tags that were introduced around 2006. No way we could retag these, so instead of changing tagging, we ended up having two tagging schemas, and we had to follow both.

No, not a single bus stop has to be changed to make it compatible to the Public Transport Proposal.

And what's worse, meaning of tags is still unclear: for example, I've seen many times how railway=station and public_transport=station for a same railway station were different objects, with no clear system.

It's a sad truth that public_transport=station is misused. But according to the Public Transport Proposal, a public_transport=station object is an area. (There is only a minor exception which doesn't apply to any station in middle europe that I know about.) Probably all nodes with railway=station and public_transport=station are mapped against the rules of the Public Transport Proposal (but according to the rules of https://wiki.openstreetmap.org/wiki/Tag:railway=station)

Which means, you have to map as much as you can. Which means, suddently for a single stop you have to map at least two objects, and possibly make a relation linking these together.

Thats plainly wrong.

No rendering. Having a visual representation depend on auxilarry tags, like bus=yes, prevented the standard style from rendering bus stops and platforms until 2017. And even now you cannot render stop with certainty because of duplication of stop positions and platforms: which do you choose, knowing that any of these can be absent?

That's right. So we cannot give up highway=bus_stop. But the Public Transport Proposal didn't propose to do that.

Returning to mapping the PT infrastructure the old way will not change anything for data contributors: they haven't really adopted the new PT schema.

They have adopted it. The main change was in the routes and the old routes are nearly gone.

You cannot remove the new tags without changes for the mappers. The new tags were made to allow mapping additional objects as highway=bus_stop may take the role stop and the role platform but not both. Only one highway=stop_position per halt of the vehicle is allowed and it is restricted to be a node.

Instead of (or along with) public_transport=platform, use:

Allowing highway=bus_stop on ways and areas make it impossible to map according to the old rules (public_transport:version=1). These routes cannot handle others halts than nodes. The public_transport:version=1 routes are still important for the mapping of partially known routes.

... light rail ...

The Public Transport Proposal doensn't have "light rail", "coach" or "share_taxi". ("light_rail" was added to the poll text AFTER the poll was done and I'm really really angry about this violation of democratic rules). A bus line is a bus line even if horse cars a used to serve it.

I don't recognize the Public Transport Proposal here. But if this were an article aimed to criticize what many mappers are doing then I would be on your side. (Weide)

On-street versus off-street

Does the confusion really come from an extra tag or merely from a conflict between some users seeing the bus stop as an object off street while others see the bus stop as an object mapped on-street? This has been fought vigorously years ago before the introduction of PTv2, and I don't see how we would avoid falling back to that old conflict if we get back to the old tagging.

To add facts, off street usage of highway=bus_stop varies between 99% in the United Kingdom (see "data tab" int the upper right corner there) and 66% in Poland. Hence, there is a majority for off-street usage, but variations are so high that we should talk to the local communities before making any changes. --drolbr

Local communities

The adoption of the tags varies wildly between different countries. For example, half of the total use of stop_position comes from only three countries (France, Germany, Poland). Are there plans to discuss the matter with the local communities? Wouldn't it be better to discuss the matter in the affected communites first? --drolbr

How to reach non-wiki readers

The proposal aims to change a bunch of wiki pages. However, there are a significant number of people that simply never read the documentation. Misplaced tags (here stop_positions off any way) make up 5-10% of total usage and are applied by hundreds of users. What is planned to reach out to these users? --drolbr