Do not suggest to add public_transport=platform for highway=bus_stop or highway=platform

[bxl-forever]

Describe the bug
If a bus stop has a node with highway=bus_stop or highway=platform, iD would automatically suggest "upgrading the tags" by adding public_transport=platform to it.

In cities where public transport is mapped in detail, this is a problem. In my area, it is common to have two objects for the same stop: a node (highway=bus_stop) where passengers will wait, and a way/area with the platform area itself. Both are necessary because they have different properties (departure boards, surface tags, sometimes a different reference number). Yet, having public_transport=platform on both would create an unwanted dual tagging issue. For instance, StreetComplete will ask users twice about the same stop and its devs have a valid point that there is a data problem here.

I could easily solve this problem in my area by removing public_transport=platform from either the bus stop node or the platform area. But it wouldn’t work because iD would still be offering every user to "upgrade the tags" and restore them. It will be a matter of weeks before a random user clicks on that in good faith and puts us back to the previous situation.

To Reproduce
Steps to reproduce the behavior:

1. Create a node with highway=bus_stop, or: Create a way with highway=platform.
2. Click on it. iD will warn it has "incomplete stops" and will offer to add "bus=yes + public_transport=platform" to it.

Expected behavior
Don’t offer to add public_transport=platform.

Additional context
I understand that many people are interested in having those tags, because many parts of the world only require a very simple data model for bus networks. The point is: in areas where public transport is mapped in great detail, erasing either the highway=bus_stop node or the highway=platform area would be really damaging, that is why we’d rather have a system that works for every situation, i.e. the public_transport=* tag should be optional. (Also, in large cities, we have a lot of new mappers every month, most of them using iD, that is why we want to help improving iD, to avoid adding unwanted tags on existing objects.)

[tordans]

@bxl-forever what is your suggestion to solve this? The underlying issue is IMO, that the schema does not transition well from a "rough" mapping style to a "micro" mapping style.

I don't see any solution that would not involve huge amount of additional work … or to deactivate feature fully (for some areas).

[bxl-forever]

How about the "not:" prefix? If we added "not:public_transport=platform" to a way/area, iD would recognize it and not trigger the upgrade.

[Elefant-aus-Wuppertal]

How about the "not:" prefix? If we added "not:public_transport=platform" to a way/area, iD would recognize it and not trigger the upgrade.

Basically, the idea is not bad.

However, I think the problem lies deeper. That's not just an iD problem. For example, many PTV2 mappers are of the opinion that a highway=bus_stop node that is a member of a PTV2 relation as a "platform" role always needs public_transport=platform to comply with the PTV2 scheme.

But what if this highway=bus_stop node is already part of a platform way? Then either the way must become a member of the route relation instead of the node, or the mappers will still add pt=platform to the busstop node - because of PTV2 "checking and completing" programs. Even without iD.

[Elefant-aus-Wuppertal]

There was also some discussion about whether highway=bus_stop would be obsolete and could be completely replaced by public_transport=platform.
(which I basically wouldn't decline because public_transport=platform + bus=yes wants to say 100% the same as highway=bus_stop).

But OSM-Carto doesn't want to render pt=platform or skip rendering highway=bus_stop because "first, highway=bus_stop is simple; second, it's perfectly fine (pt=platform is just an extension), and third, highway=bus_stop was there first!"

Then one hinders the other. If a bus stops there, public_transport=platform should not be in the immediate vicinity without a highway=bus_stop, because then the bus stop will not be displayed.

But it's not possible to render public_transport=platform, because you have highway=bus_stop and that's used en masse - so it's established and accepted. Otherwise it wouldn't be used so widely.

And so you go in circles. You get the feeling that one hand doesn't know what the other is doing. We won't get any further like this.

We urgently need to solve this problem, I definitely agree. In no other area is there such a blatant violation of the "one festure, one osm element" rule as with the bus stops.

[matkoniecz]

because public_transport=platform + bus=yes wants to say 100% the same as highway=bus_stop

There are bus stops without any platform at all

[Elefant-aus-Wuppertal]

hmm, good point.

However, public_transport=platform seems to be misunderstood then, or misused by many. The demarcation criterion is also not so simple. When is a platform a platform?

Here in Germany, pt=platform is tagged to everything that is next to the road. Even at bus stops on country roads that only exist as "poles".

Then iD should not suggest tagging every bus stop with pt=platform but also allow highway=bus_stops without pt=platform.

But I think we won't be able to convince the PTV2 mapper of something like that either. For many, even a point-shaped bus stop is certainly a "platform" because (theoretically) people can wait there for the bus.

The wiki says for public_transport=platform:
"Nodes are used for locations where there is no physical infrastructure (for example a customary bus stop without infrastructure or with a pole)".

As far as I know, bus stops that don't have a "pole" (or anything else) are marked with physically_present=no. However, it might make sense for the course not to tag pt=platform there...

I have no idea whether there is an exception for these things already (don't they mainly occur in GB?).

Company stops for employees of the transport company or similar are something else anyway.

[bxl-forever]

Thanks for everyone who added comments here. Yes, @Lukas458, that was the idea in my first message. It is okay to add public_transport=platform, and "PTv2 mappers" are reported to care a lot about this, but it should ideally not be everywhere. Something like this:

• For simple tagging: node with highway=bus_stop + public_transport=platform
• For advanced tagging: way/area with highway=platform + public_transport=platform + node with highway=bus_stop

Indeed, the difficult part is to have various mappers agree on a standard. So far, either we must accept data duplication (and possible discrepancies when object changes and not the other), sacrifice good rendering (by removing bus stop nodes when platform areas are there), or have every node potentially raising a flag in iD (the reason for this ticket).

[miche101]

I don't like PTV2, it's just too much work to keep it up to date. In the future you should rely on GTFS and Routing

highway=bus_stop is the same as public_transport=platform + (bus=yes) and best as Node or Area is ok too. Beside the street and not on the street.

A PTv2 mapper adds public_transport=* keys for better working with JOSM to create all relations

[Elefant-aus-Wuppertal]

What I honestly don't understand either is:

Why not make two schemes one again?

I know the following is fantasy, but still:

1. We agree that a place where people are waiting for a bus that stops should always be represented by ONE object in OSM. Depending on how this is developed, you map it as a line or way if a whole platform exists. Therefore only tag public_transport=platform.

2. Define "Platform" clearly - what is and what is not a platform.

3. Always use public_transport=platform for bus stops with platforms, if necessary also as a point if you do not know the extent of the platform or cannot map it, but know that one is there.

4. If a bus stop is just a "small mini bus stop on a country road", without shelter, tactile paving etc.,
   or the bus stop can (or you want to) only be mapped rudimentarily, and it is not known that a platform exists (for whatever reason) (a previous argument for highway=bus_stop),
   then e.g. for example, use a new tag like public_transport=bus_stop. Allow public_transport=bus_stop for points only (to ensure that such a tag is only used for bus stops without a platform, and these can only be points).

5. A bus stop would always get one of the two tags: either pt=platform or pt=bus_stop.

6. The (partly) unloved highway=bus_stop is then obsolete and is replaced by either pt=platform or pt=bus_stop.

7. public_transport=stop_position stays as it is, as a node on the street.

8. In the case of "rudimentary" mapped bus stop locations, we would then have to agree that an object next to the road is always required for the bus stop to be rendered. I know that might upset some people, especially if you don't know exactly where the bus stop is. But seriously: Where does it happen that the position is not improved later? And in which country are bus stops only mapped on the street? The goal is always to have objects off the road, even if it's just a point.

When you get off a bus or wait for it, you do it next to the road, not on it.
The bus stops on the road, yes. But that is shown by pt=stop_position.

9. The renderers would have to solve the dilemma as follows:

• render pt=platform as nodes, ways and areas
• and render a new tag, in my example pt=bus_stop, only as nodes
• derender highway=bus_stop

For line and area platforms, a dot would simply have to be created in the middle of the line or area, at which point a bus icon and the name of the bus stop would be rendered (although then no point-like object would exist there).

Then we would have solved the problem with this double tagging. Either pt=platform or pt=bus_stop.

Somehow I don't understand what can be so difficult about it. I mean, for shops etc. which are areas, renderers can also render a point in the middle and that's it.

Maybe I'm missing something here, but somehow the current situation is also not that great at the moment...

[matkoniecz]

Somehow I don't understand what can be so difficult about it.

Many people want to mark bus stops without interacting with complicated elaborate tagging scheme like PTv2 or even more complex ones.

[dieterdreist]

I think as it isn’t completely clear, iD should not nudge people to add possibly synonymous tags, or worse, add them automatically. Highway=bus_stop has everything that is needed for a simple bus stop and adding platform tags doesn’t add anything.

[Elefant-aus-Wuppertal]

Basically, I think that we are somehow not getting the platform issue completely resolved at the moment. All sides are never satisfied, but as a (possibly temporary) solution I would also advocate suspending the automatic addition of public_transport=platform.

For so long, until we found another solution to the (from some point of view) double tagging problem concerning highway=bus_stop and public_transport=platform. As I said, the same discussions have been going on for years...