Add rendering for public_transport=platform

[AndiG88]

Edit: Okay maybe rather use it on public_transport=platform

Use the same icon as highway=bus_stop

(if you want to do more use different ones depending on bus/tram=yes/no)

It would be great if you could support the "new" public transport schema, I think one of the main reason people don't use it, is because it does not show up on the map.

http://wiki.openstreetmap.org/wiki/Key:public_transport http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport

[23cpo]

public_transport=stop_position is used over 200,000 times. http://taginfo.openstreetmap.org/keys/public_transport#values I think it should be supported and get rendered.

[RobJN]

In the West Midlands of UK we have been mapping bus stops using highway=bus_stop at the location of the shelter/sign (i.e. on the pavement). The equivalent tag in the Public Transport schema would be public_transport=platform.

We need to be a bit careful about what we render. The worst case solution is that we end up rendering bus stops in 2 places - on the road way and where the shelter/sign/platform is. This is a Bad Idea as it will confuse people and may lead to some folks removing one instance as they may see it as duplication.

Some stats: From Taginfo UK:

• "bus=*" with any "public_transport" : 986 instances (assuming that all of these have both the platform and stop position mapped, as per the tag guidelines, this gives 493 bus stops)
• "highway=bus_stop" : 219,475 instances.

From Taginfo Global:

• "bus=*" with any "public_transport" : 251,336 instances (assuming that all of these have both the platform and stop position mapped, as per the tag guidelines, this gives 125,668 bus stops)
• "highway=bus_stop" : 1,295,300 instances.

I would love to be able to say that we can solve this problem by having different rendering rules in different countries (depending on the dominant tag use), but this would be a nightmare to code and maintain. Worse still it would be a short term sticking plaster solution that would lead to entrenched fragmentation in OpenStreetMap.

[AndiG88]

on the road way and where the shelter/sign/platform is. This is a Bad Idea as it will confuse people and may lead to some folks removing one instance as they may see it as duplication.

And what is preventing users from doing this right now? In fact I have tagged several of my first Bus stops exactly like that, because ID shows a nice icon on the way when you put a bus_stop on it.

http://taginfo.openstreetmap.org/tags/public_transport=stop_position#combinations

As you can see 100000 bus_stops are mapped on a stop position. Considering that the platform tag has been used as much it's pretty save to say that most of those stop positions (and bus_stops on them) are on the road. So this is already a problem today. There reason you don't see it is probable because people mapping just remove one.

So what about rendering a this blue dot like on tram_stop(?) on public_transport=stop_position and/or using the icon on the public_transport=platform tag? Then you don't know what to render, right? Bus or tram? So could there be a general icon like it is used in Germany? http://commons.wikimedia.org/wiki/File:Zeichen_224.svg (not suggesting to use that one). Wouldn't that be a good idea in general to have such an icon for combined bus&tram stops? Should we use a tag like public_transport:platform=bus?

[RobJN]

Nothing is preventing people from deleting things right now, but as you have discovered, things that are rendered draw a lot more attention (from both mappers and people who just view the Mapnik render).

Unfortunately I struggled to follow the rest of you're comment. But my point still stands. Take a look at this area:

http://www.openstreetmap.org/#map=19/50.93487/6.96162

It already has a mix of where the bus icon is rendered - some on the road, some beside the road. The concern is that we end up rendering some bus stops on both.

I would suggest that a good first step would be to promote consistent use of the highway=bus_stop tag (for tagging the bus shelter/sign) and then you could ask for public_transport=platform with bus=yes to be rendered the same as highway=bus_stop. Although I expect that you'd feel differently about this.

(Note: My comment is all about buses. As the public_transport tag is for all forms of transport, then you'd have to consider each one separately as the rendering implications of each may be different).

[AndiG88]

My point is simply how many bus stops do we see with two icons for the exact same stop? Pretty much zero. Why? Because people see it on the map and fix it. That's why I don't see why it would be any different if a public platform get rendered the same way, too.

I would suggest that a good first step would be to promote consistent use of the highway=bus_stop tag (for tagging the bus shelter/sign)

But how is that going to happen? There are over 100k that are tagged wrong as they are on a stop position and probably a lot more without such a tag. And I have been applying the new schema to a lot of stops in German recently and for most stops the last edit was 3-5 years ago. Why would anybody think about that or change it? I theory I completely agree, but in reality nobody is going to fix a quarter of a million bus stops that have been like that for years. (Not to mention that without local knowledge you don't always know on which side the platform it belongs).

public_transport=platform with bus=yes to be rendered the same as highway=bus_stop. Although I expect that you'd feel differently about this.

That part is fine. I mean then that bus tag would have to be put there in addition because right now it is supposed to go into the stop position.

[RobJN]

Since 25th April 2008 the (English language) highway=bus_stop wiki page has clearly stated that the highway=bus_stop tag should be mapped beside the road. As such the expectation is that the bus stop is rendered beside the road. This request would change this convention to render bus stops as part of the road's way. A change that is bound to lead to duplication of the rendered icon and confusion amongst mappers and map users.

P.s. I'm not sure when the public_transport schema came about (the wiki suggests later), but really it doesn't matter. What matters is that a tagging issue does not become a rendering issue. This is not a simple fix and regrettably shows the problem of new tagging schemas that are not backwards compatible. Hopefully we can learn from this and make better decisions in the future as it is a great shame that we have this mess.

[AndiG88]

highway=bus_stop Wiki (old): Note that highway=bus_stop is also occasionally used to mark the position on the carriageway where the vehicle stops, rather than the place where the passengers wait. [...] The highway=bus_stop tag is widely used to identify the position where passengers wait for a bus beside the carriageway, however there is not complete agreement within the community on this matter, and some users advocate using highway=bus_stop as a node within the highway=* at the place where the vehicle stops.

For me that is everything, but clear. It even repeats it.

What matters is that a tagging issue does not become a rendering issue.

The problem is that it does. Your best tagging scheme is not going to be used if it does not show up on the map, but the old alternative does. If building=commercial + type=bread would render a bakery on the map, but shop=bakery wouldn't which tag scheme do you think would be more common, especially if ID tagged you the first one if you search for bakery?

of new tagging schemas that are not backwards compatible.

But that isn't because public=transport is bad, that's because highway=bus_stop is a mess and there was never an agreement how to use it exactly. As you said before if they were all on the side of the road you could apply the same icon on public_transport=platform + bus=yes right away.

[dieterdreist]

Am 02/apr/2014 um 01:23 schrieb AndiG88 notifications@github.com:

you could apply the same icon on public_transport=platform + bus=yes right away.

+1, I suggest we do this and fix problems then in the map

[gravitystorm]

there was never an agreement how to use it exactly.

@AndiG88 Yes there has. @RobJN has pointed out that there's been clear agreement on how to use highway=bus_stop for almost 6 years. If you keep refusing to believe this, it inclines me to disregard the rest of this discussion.

[AndiG88]

I don't have a problem if that's how it is, but until Rob changed the wiki yesterday it stated twice (see my quote above) that the tag is sometimes used on the way and did not say that is a wrong usage. What I would have expected if there is a 6 year old agreement is that it is worded like it is now.

Also if that is the agreement, then I guess there should be no problem to apply the same icon on public_transport=platform+ bus=yes as that exactly matches?

[RobJN]

I did change the wiki page yesterday, yes. Why? Because I looked through the pages history and decided that PeterITOs change - although good in some areas - weakened the very clear message that highway=bus_stop is for beside the road. New tagging schemas can be mentioned, but shouldn't be at the cost of clear info on the existing tag page.

I'm glad that we are coming to the same conclusion - encourage the proper use of highway=bus_stop and render public transport platform with bus=yes in the same way.

For other transport modes, stop position may be ok. For buses use platform.

On 2 Apr 2014 09:31, "AndiG88" notifications@github.com wrote:

I don't have a problem if that's how it is, but until Rob changed the wiki yesterday it stated twice (see my quote above) that the tag is sometimes used on the way and did not say that is a wrong usage. What I would have expected if there is a 6 year old agreement is that it is worded like it is now http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop.

Also if that is the agreement, then I guess there should be no problem to apply the same icon on public_transport=platform + bus=yes as that exactly matches?

Reply to this email directly or view it on GitHub.[image]

[Rovastar]

@AndiG88

"Also if that is the agreement, then I guess there should be no problem to apply the same icon on public_transport=platform+ bus=yes as that exactly matches?"

Irrespective of the validity of the bus stop discussion I am rolling out my stock answer here if these tags are not stored in our Carto database they will unlikely to be added to the map.

We are not making schema changes to the database yet to accommodate this. And to my knowledge we do not have a field for "bus" or probably "public_transport" hence there this will not be done for a while even if it was a valid suggestion.

[dieterdreist]

2014-04-02 15:39 GMT+02:00 Rovastar notifications@github.com:

I am rolling out my stock answer here if these tags are not stored in our Carto database they will unlikely to be added to the map.

maybe this was already mentioned and/or replied to, sorry if so, what about using hstore datatype for the db? The Germans are doing this with a custom scheme that has very few columns because it keeps most of the tags only in hstore and has views for them. From what I know the performance penalty is not so big (10% or less). It would give us a whole lot of flexibility and details out from the osm db which as it stands now is not available for rendering. There is a description here: http://svn.openstreetmap.org/applications/rendering/mapnik-german/README(not sure if up to date, but it is with hstore). The default.style is here: http://svn.openstreetmap.org/applications/rendering/mapnik-german/views/default.style

[pnorman]

From what I know the performance penalty is not so big (10% or less).

The rendering performance penalty for --hstore/-k is a 0.24% speed decrease if the hstore column is not used.

The rendering performance penalty for the mapnik german .style + hstore is substantial, at 4.7% (unpublished results with views).

However, this misses the point for two reasons.

1. Hstore is a way to reduce future schema changes. It doesn't get us away from this one, as the change to hstore is a schema change itself. My read of the current situation is that schema changes will be a 3.0 change, and probably involve a slimming down of the .style file, the use of --hstore, and substantial query rewrites, backed up by benchmarking.
2. We have public_transport in the database already.

[dieterdreist]

2014-04-03 8:27 GMT+02:00 Paul Norman notifications@github.com:

Paul, it is clear that hstore would mean a significant schema change including re-importing. I just raised this, because we are facing the problem of missing column since ever and every now and then, and hstore would be a solution to this, giving us really all the flexibility we will need for rendering all kind of strange tags (as long as objects get imported, i.e. have at least one tag that makes them interesting)

We have public_transporthttps://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style#L126in the database already.

but as I understand we don't have "bus" currently so we don't know whether the platform is a bus_stop or on a train station, right?

[AndiG88]

Is there any key where you could put the information what kind of bus stop that is?

Otherwise what about using a general icon? In Germany for example all stops just have an H, is there some kind of international icon for that?

[Rovastar]

If suddenly we had a load of H's displayed on the map I would feel left out not owning a helicopter. ;-)

@pnorman I should have checked and yes we do have public transport. It was more about I knew we didn't have bus = key which we would need to render this correctly like dieterdreit pointed out

[pnorman]

For what it's worth, I'm :-1: on rendering public_transport=platform + bus=yes, regardless of the schema change issues. The mapper feedback loop is important, and I don't think encouraging what is a non-standard less common tag is a good idea, but the call on that is up to @gravitystorm.

[AndiG88]

and I don't think encouraging what is a non-standard less common tag is a good idea

So... have you ever talked with the JOSM developers about this?

[sb12]

I did some example renderings for bus stops with public_transport=platform and bus=yes instead of highway=bus_stop to get an idea how it would look. While doing this I found the following issues:

• At least in my region the tagging of bus stops is very inconsistent. Sometimes it's mapped as public_transport=stop_position, sometimes as public_transport=platform and sometimes as an extra node. This leads to doubled bus stop points, when not removing the highway=bus_stop rendering.
• Not all platforms where a bus stops do have the bus=yes key.
• I don't get the symbol rendered on platforms mapped as a way. Any ideas of the experts how to do this?
• It does look a bit strange on combined tram and bus stops:
• Showing the platform as a bus stop is also inconsistent with the current rendering of railway stations and tram stops, where the icon is usually either in the middle of the station or on the tracks.

For now it's definitive not a good idea to remove the support of highway=bus_stop as most bus stops are not correctly mapped in the new scheme yet. Rendering the platform as bus stop will lead to lot's of doubled bus stops at the beginning, but these will probably be removed by mappers over time.

Some more pictures for bus stations and platforms as an area:

[dieterdreist]

Am 21/giu/2014 um 14:37 schrieb sb12 notifications@github.com:

At least in my region the tagging of bus stops is very inconsistent. Sometimes it's mapped as public_transport=stop_position, sometimes as public_transport=platform and sometimes as an extra node. This leads to doubled bus stop points, when not removing the highway=bus_stop rendering.

the complete mapping would be both, platform and stop position with key public_transport while the stop position with highway bus stop is implicit (but mapping isn't completely consistent neither there)

I don't get the symbol rendered on platforms mapped as a way. Any ideas of the experts how to do this?

you could do this similar to highway shields but with a lot of spacing to avoid duplicates?

Showing the platform as a bus stop is also inconsistent with the current rendering of railway stations and tram stops, where the icon is usually either in the middle of the station or on the tracks.

IMHO the middle of the station is similar to the middle of a bus stop, no inconsistency

For now it's definitive not a good idea to remove the support of highway=bus_stop

+1

[sb12]

At least in my region the tagging of bus stops is very inconsistent. Sometimes it's mapped as public_transport=stop_position, sometimes as public_transport=platform and sometimes as an extra node. This leads to doubled bus stop points, when not removing the highway=bus_stop rendering.

the complete mapping would be both, platform and stop position with key public_transport while the stop position with highway bus stop is implicit (but mapping isn't completely consistent neither there)

sorry, what I meant was the node where the highway=bus_stop is mapped.

you could do this similar to highway shields but with a lot of spacing to avoid duplicates?

Thank you this worked. Some examples:

Showing the platform as a bus stop is also inconsistent with the current rendering of railway stations and tram stops, where the icon is usually either in the middle of the station or on the tracks.

IMHO the middle of the station is similar to the middle of a bus stop, no inconsistency

Yes, but with this approach we do render the bus stop symbols on the platform and not in the middle of the bus stop, while we render the railway and tram stop symbols in the middle of the station and not on the platforms.

If we wanted to be consistent with railway=station and railway=tram_stop etc. we should render one bus symbol for the complete stop in the middle of the bus stop/bus station.

[matkoniecz]

public_transport tag is available in the database, but bus tag and others tags specifying type of stop_position are not. So currently it is impossible to check whatever element is a bus stop. To replace current style, without losing ability do display bus/tram/etc stops in a different ways database change is necessary

[pnorman]

For now it's definitive not a good idea to remove the support of highway=bus_stop as most bus stops are not correctly mapped in the new scheme yet.

highway=bus_stop is not incorrect, so it's unlikely we will ever remove it.

[gileri]

highway=bus_stop is not incorrect, so it's unlikely we will ever remove it.

Not incorrect, but badly defined. It can both mean a stop position on the road or a platform. And it's needlessly specific to buses stop, as most features described in the "new" Public Transport scheme can be applied to all public ground transportation.

[dieterdreist]

2014-11-03 17:07 GMT+01:00 Eric G. notifications@github.com:

Not incorrect, but badly defined. It can both mean a stop position on the road or a platform.

AFAIK most mappers use it to mark the position of the pole on the bus stop ("platform" is something I'd expect at a station, not on a small bus stop, so that's slightly missleading as well) so you can project this to the nearest road (with the route on it) and get the stop position implicitly. Not that it would matter in any instance of real bus stop I have ever seen.

And it's needlessly specific to buses stop, as most features described in the "new" Public Transport scheme can be applied to all public ground transportation.

being specific can also be seen as an advantage, in many fields of osm specific keys have been used historically (e.g. village green, greenfield, brownfield, building=church vs. building=chapel), while the new public transport scheme is so generic that we don't even know if something is a bus stop or maybe a tram stop? (in our current rendering db). In this case there's no real advantage in having to map and later parse 2 or 3 generic tags to get to the same information you can get from 1 specific tag.

[kocio-pl]

I think we should drop rendering public_transport=stop_position, because it's meant just for routing (and it's very helpful, because we can make real time semi-automatic updates of routes here in Warsaw!). If we want to see something people really use, we have public_transport=platform tag (or other kind of platforms etc).

[AnBuKu]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am 17.03.2015 um 06:23 schrieb kocio-pl:

I think we should drop rendering public_transport=stop_position, because it's meant just for routing (and it's very helpful, because we can make real time semi-automatic updates of routes here in Warsaw!).

Fully agree. Same here in Bern with BERNMOBIL using OSM for their mobile app *

If we want to see something people really use, we have public_transport=platform tag (or other kind of platforms etc).

And yes, rendering of public_transport=platform as a replacement of public_transport=stop_position would be very nice and helpful for browser users of osm.org

cheeers, Andreas

• Link (Sorry, German only) http://www.bernmobil.ch/Seiten/fahrplan/oevbern/faqoevbern/?oid=2211&lang=de#4

— Reply to this email directly or view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/435#issuecomment-82115282.

---

Andreas Bürki

abuerki@anidor.com S/MIME certificate - SHA1 fingerprint: ED:A5:F3:60:70:8B:4C:16:44:18:96:AE:67:B9:CA:77:AE:DA:83:11 GnuPG - GPG fingerprint: 5DA7 5F48 25BD D2D7 E488 05DF 5A99 A321 7E42 0227 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iQEcBAEBAgAGBQJVB71DAAoJEFqZoyF+QgInebsH/ArTTG319IZsozn4Cpcox1nb EeVBt7y6XjBGeRmpDjcaUGjy2qDwisJr2T2ODSVcLwlgTDintDyLMKTxwYBsU3aU kfjVUhV1DcpkY1/G236X1nh57cjQSl+YkrFXVNHt6nEizGFFvsnFNWIYrhFZ91xx wL67CT6pplNklXmY4Yj1J1lcemtKRXggBHD8SrtWa696IM159kOEBKxvTP1qhDp9 rC/yqmjCN3/2EfYK5PMSPRxQLIZfSrHnvLxgW6G8p3j82ltAJGGteig68BERzfkl PH+LutlEdEzTrXduO4/HZKdpmBtyJRHwYGheQeO+aTdAAbGgpCdJVwR6bfE98OY= =W3rL -----END PGP SIGNATURE-----

[matthijsmelissen]

As far as I can see, this was tagged incorrectly as 'Needs upgrade to osm2pgsql'.

[matkoniecz]

@math1985

public_transport tag is available in the database, but bus tag and others tags specifying type of stop_position are not. So currently it is impossible to check whatever element is a bus/tram/etc stop. The only available information is that it is some sort of stop position for a public transport.

[HolgerJeromin]

Don't we need bus= (and other keys) in the database?

[matthijsmelissen]

Re-added milestone.

[d1g]

@AndiG88 Yes there has. @RobJN has pointed out that there's been clear agreement on how to use highway=bus_stop for almost 6 years. If you keep refusing to believe this, it inclines me to disregard the rest of this discussion.

and

For what it's worth, I'm :-1: on rendering public_transport=platform + bus=yes, regardless of the schema change issues. The mapper feedback loop is important, and I don't think encouraging what is a non-standard less common tag is a good idea,

They kept only for that "mapper feedback loop". And data consumers use public_transport=* because they can get meaningful data (4 separate tags), not randomly placed highway=bus_stop or highway=platform which pretend to cover 3-4 objects at once.

If all software functions, nobody cares about tagging.

And no, this isn't "a non-standard tag" but one of 4 ways to mark a PT http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Stop (s)

Which was approved: 83 approve the proposal, 6 oppose the proposal.

If you want 83 people to respect your opinion, don't neglect fact that this is hugely supported tag/proposal within OSM community.

And if @AndiG88 and @gravitystorm have a short memory on approved tags (not random tags like highway=platform or highway=bus_stop that were defined despite agreement on highway=*):

a highway=* key reserved for "highway=* should be changed to importance for the road grid (hierarchical position in the interconnecting network) instead of physical attributes. " (https://wiki.openstreetmap.org/wiki/Proposed_features/Highway_key_voting_importance)

[d1g]

Please rename issue to public_transport=platform, per author request:

Edit: Okay maybe rather use it on public_transport=platform

[matkoniecz]

per author request

Creator of an issue may edit title of the issue.

[matkoniecz]

Can anyone supply link with documentation why public_transport=platform bus=yes tag duplication of highway=bus_stop is a good idea?

Neither https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform nor https://wiki.openstreetmap.org/w/index.php?oldid=625726 nor https://wiki.openstreetmap.org/wiki/Key:public_transport is explaining this.

I assume that there is some reason for that (this tagging is quite widely used) but it seems to not be documented anywhere and reasons for that should be quite strong to justify deprecating tags used millions of times and to introduce more complicated tagging.

I found https://wiki.openstreetmap.org/w/index.php?oldid=625726#Main_Problem_with_the_existing_Schema but is it entire reason for new scheme? Given that it adds other new significant problems, that at least in my opinion are worse than what is listed there, I am not convinced that it is a good idea to support it.

Note that it makes no sense to render both public_transport=platform bus=yes and highway=bus_stop as we should discourage fragmenting of tagging. I plan to add " and stop rendering highway=bus_stop" to the title.

And assuming that public_transport=platform bus=yes rendering would be introduced - what about many, many other versions of public_transport=platform and tags that are supposedly replaced by it? AFAIK it was supposed to replace also railway=halt, railway=tram_stop, railway=platform, aeroway=gate, amenity=taxi etc.

EDIT 2019-10-22:

According to the proposal itself - standard tags like highway=bus_stop, railway=tram_stop were not deprecated.

Note

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.

in the proposal - https://wiki.openstreetmap.org/w/index.php?oldid=625726#What_this_Proposal_does_not_cover

[RobJN]

Note that it makes no sense to render both public_transport=platform bus=yes and highway=bus_stop as we should discourage fragmenting of tagging.

I plan to add " and stop rendering highway=bus_stop" to the title.

The problem is it is already fragmented and after many years it continues to be so. I am not fully up to speed with public transport mapping (I no longer do any as I find it too complicated and don't have the time to read it all), but if mappers who have previously spent many hours using PTv2 have doubts then it seems far from clear cut that this is the way to go.

https://www.openstreetmap.org/user/Polyglot/diary/44333 https://www.openstreetmap.org/user/Polyglot/diary/44440

There is also the Ptv3 proposal from @Zverik : https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport

p.s. since my post 1 April 2014 the number of highway=bus_stop tags has increased by 1 million. It certainly doesn't feel like something we should stop rendering.

[A67-A67]

iD now has a new validation rule that adds a highway=footway to a public_transport=platform way. While this is not totally wrong, the public_transport tag already tells us that its primary function is a platform, it makes non-compatible renderers like osm-carto render a platform as a footway.

It would be better when osm-carto knows that a way like this one, is a platform and doesn't need an extra highway=platform for compatibility.

[jeisenbe]

I've just looked into this issue, and the comment above is correct: https://github.com/gravitystorm/openstreetmap-carto/issues/435#issuecomment-46757866

It is not at all standard to use bus=yes with public_transport=platform - this combination is not suggested at the page Tag:public_transport=platform nor was it mentioned in the approved proposal. The tag bus=yes was designed for use with public_transport=stop_position.

Some mappers are using the tag in this way. Taginfo shows that only 59% of public_transport=platform have bus=yes (and <1% are trollybus=yes), while 75% have highway=bus_stop. For rail: 5% have railway=platform, compared to only 2% with train=yes and 1.5% with tram=yes.

There's also 6% of public_transport=platform combined with highway=platform. Source: https://taginfo.openstreetmap.org/tags/public_transport=platform#combinations

So it appears that the best way to specify a bus stop at the side of a road, as opposed to "any kind of place to wait for a public transportation vehicle", is to use highway=bus_stop in addition to public_transport=platform.

The situation is the same for railway=platform and other modes, because again, public_transport=platform does not specify bus vs train vs tram etc.

Since this is the case, I believe @pnorman is correct: this issue should be closed, and we should continue to rely on the current tags to render bus stops, train platforms and the rest.

This may even have been the original intention of the public_transport proposal, since there was no other way to specify the mode or vehicle at a public_transport=platform other than using the pre-existing tags?

[A67-A67]

Actually there are two issues here, that can be solved at once or separately: platform as a node and platform as a way. The reaction above is mostly about the former. The latter is however becoming the biggest issue.

public_transport=platform as a node This combination public_transport=platform + bus=yes should be rendered as a bus stop symbol. Now the tag highway=bus_stopfrom the old scheme has to be added for compatibility with maps like osm-carto. Note that people have to add highway=bus_stop to get the bus stop on osm.org, even though public_transport=platform + bus=yes should be enough.

In my opinion at least both tagging schemes should be rendered, so the compatibility tag highway=bus_stop is not necessary anymore.

public_transport=platform as a way public_transport=platform on a way, both a normal way and an area, replaces highway=platform and railway=platform. Rendering can be done easily by just rendering public_transport=platform ways as the dark-gray line/area which is now used for highway=platform and railway=platform.

Not rendering this is becoming more and more an issue. The iD editor is now adding highway=footway to all platform ways. So osm-carto renders these now as a footway, instead of a platform. In the combination railway=platform + highway=footway + area=yes the highway-tag even seems to overrule the railway-tag, so the platform looks like a pedestrian area...

The latter issue could be easily solved, even without solving the former issue. In this case public_transport=platform should overrule highway-tags and railway-tags like highway=footway and render as the dark-gray platform color.

[matkoniecz]

The iD editor is now adding highway=footway to all platform ways. So osm-carto renders these now as a footway, instead of a platform.

Are you sure? Afaik this iD bug/misfeature was fixed.

The latter issue could be easily solved, even without solving the former issue. In this case public_transport=platform should overrule highway-tags and railway-tags like highway=footway and render as the dark-gray platform color.

Incorrect data can be shown as incorrect. This style is intended as feedback to mappers so this is OK.

even though public_transport=platform + bus=yes should be enough.

It seems disputable to me, see comment about yours. Neither PTv2 proposal nor usage supports this. And still nobody answered https://github.com/gravitystorm/openstreetmap-carto/issues/435#issuecomment-491350865 question

Can anyone supply link with documentation why public_transport=platform bus=yes tag duplication of highway=bus_stop is a good idea?

[kocio-pl]

Can anyone supply link with documentation why public_transport=platform bus=yes tag duplication of highway=bus_stop is a good idea?

I would say that this is how we could get out of ambiguity of what a "bus stop" really means without unexpected dropping common tagging.

[matkoniecz]

Closing per https://wiki.openstreetmap.org/w/index.php?oldid=625726#What_this_Proposal_does_not_cover

This proposal does not replace, deprecate or obsolete the already existing and well known tags.

ongoing dominance of standard and simple tagging (see https://github.com/gravitystorm/openstreetmap-carto/issues/435#issuecomment-516016068 ) and lack of documentation why significantly more complex and confusing tagging scheme would be wanted (see https://github.com/gravitystorm/openstreetmap-carto/issues/435#issuecomment-491350865 ).

I am especially confused why this proposal was created and supported in the first place given that stated intention was to duplicate existing tagging without intention of replacing it.

---

Overall simple tagging (highway=bus_stop type) is preferable over more complex that makes everything more complicated (simplest bus stop tagged three times in two different places). Enormous effort went into discussing and using it, without any clear analysis/documentation why additional complexity is worth negative effects.

[gileri]

I am especially confused why this proposal was created and supported in the first place given that stated intention was to duplicate existing tagging without intention of replacing it.

Just above the section you cited you can find why that proposal was created. As to why this proposal did not call for replacement of PTv1, I can only guess that was in order to have a gradual deprecation later while keeping compatibility for the time being.

ongoing dominance of standard and simple tagging

It is older, global transitions are not that quick. 1.5M highway=bus_stop vs 2.5M public_transport=platform platforms can be called dominance, but this graph from OSM tag history tells another story : PTv2 was introduced later, and even while the renders and tools did not pick it up for years, its usage is growing at a quicker rate than PTv1 (and slightly accelerating), showing a clear interest to map this way.

[matkoniecz]

Just above the section you cited you can find why that proposal was created.

Sorry. Not sure why I have not mentioned it. But note that mentioned problems are not really relevant to explaining why new proposal is desirable.

Inconsistent handling of railway=tram_stop / railway=halt (node on the way) and highway=bus_stop (node beside the way).

This proposal failed to solve it - as old tags are not replaced anyway

Missing tag for stop position causes extra preprocessing for routing software.

Not sure why this extra preprocessing step should be done manually, instead of automatically. It could be understood if that extra processing was impossible, but it is not such case

No separate tags for stop position and platform / pole.

Not sure why it is considered as a problem, tagging both is a pointless duplication.

Insufficient possibility for line variants for bus lines.

This part maybe makes sense. It is hard to say as I never tagged or really maintained such info. But it is not relevant to other parts.

I still claim that documentation why significantly more complex and confusing tagging scheme would be wanted is missing.

I am still confused why this proposal was created and supported in the first place given that stated intention was to duplicate existing tagging without intention of replacing it.

I still think that simple tagging (highway=bus_stop type) is preferable over more complex that makes everything more complicated (simplest bus stop tagged three times in two different places). Enormous effort went into discussing and using it, without any clear analysis/documentation why additional complexity is worth negative effects.

I hope that bias here to not change my original opinion is not significant.

[matkoniecz]

It is older, global transitions are not that quick. 1.5M highway=bus_stop vs 2.5M public_transport=platform platforms can be called dominance, but this graph from OSM tag history tells another story : PTv2 was introduced later, and even while the renders and tools did not pick it up for years, its usage is growing at a quicker rate than PTv1 (and slightly accelerating), showing a clear interest to map this way.

Interpretation 1 - strict following proposal

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.

So rendering highway=bus_stop and not rendering public_transport=platform actually is following the proposal. Proposal, as written, is explicitly not deprecating highway=bus_stop.

As to why this proposal did not call for replacement of PTv1, I can only guess that was in order to have a gradual deprecation later while keeping compatibility for the time being.

Maybe. But AFAIK there was never a clear support for such deprecation.

---

Interpretation 2 - bus=yes tag

bus=yes tag from what I see was in proposal missing for platforms from what I see in https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726#Platform

Note https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726#Compatibility_with_well_known_tags - bus=yes was supposed to be added only to public_transport=stop_position

But in use of public_transport=platform as highway=bus_stop replacement it is actually used.

Looking at https://taghistory.raifer.tech/ it has about 2 000 k uses for highway=bus_stop on start of 2018, and about 900k for public_transport=platform

It is now 2 500 k https://taginfo.openstreetmap.org/search?q=highway%3Dbus_stop vs 1 587 k for alternative https://taginfo.openstreetmap.org/tags/public_transport=platform

But only 989 k public_transport=platform has bus=yes! So only about 60% of public_transport=platform represents bus stops.

It is possible that public_transport=platform + bus=yes grows quicker than highway=bus_stop, bot sure how to check this, but linked data is not supporting this.

BTW, https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726#Compatibility_with_well_known_tags makes clear that to mark something as bus stop according to this proposal one must use highway=bus_stop