Render public transport platforms and stops (new scheme, relation-free implementation for now)

[stefanct]

Since supporting the new/alternative tagging scheme of public_transport=* completely is not trivial due to the heavy use of relations, let's start with some easy bits:
#134

That is: rendering of public_transport=stop_position (like railway=tram_stop i.e. a small blue square, or like highway=bus_stop (if bus=yes but no other transports are tagged) and public_transport=platform (like railway=platform for areas and ways, and maybe shelters for nodes with shelter=yes?).

[smehrer]

+1

[AndiG88]

Is just found this. Are there any plans to make this happen?

[wolfbert]

I support this.

[pnorman]

#311 has some tag suggestions.

[sabas]

public_transport=platform should be rendered as an area.
Osmose reports as an error the area=yes on every platform and when someone fix it the renderer draws the platform as a closed area.
cc: @frodrigo

[PolyglotOpenstreetmap]

I'm sticking my head in the sand and give up in despair. To please JOSM's validator I'll tag bus stops with public_transport=platform, bus=yes and to get them rendered I'll double tag them with highway=bus_stop.

All 70000 of them for one country alone.

I like the new scheme for public transport. It makes sense to me, but apparently not for the people who work on the rendering side of things. I started out holding my breath and tagging simply highway=bus_stop, but then JOSM does not assign roles automatically and the valdidator complains, so since a few months I'm filling the DB with redundant data. So be it.

Jo

[matthijsmelissen]

We have around 400 open bugs, and only a handful of people working on the code. It might take some time before things get fixed, but that doesn't mean we believe things 'don't make sense'. If you would like to help speed things up, feel free to write a pull request.

[dieterdreist]

2014-06-19 19:29 GMT+02:00 PolyglotOpenstreetmap notifications@github.com:

I like the new scheme for public transport. It makes sense to me,

It solves some problems and defines complex mapping schemes which allow to
insert highly detailed information, agreed. On the other hand in the case
of bus stops it doesn't improve the situation IMHO, rather it requires 2
tags what can be expressed without information loss with one in the old
scheme.

[pnorman]

👎 to this. Encouraging a less-common way of tagging bus stops only hurts everyone trying to use the data.

[PolyglotOpenstreetmap]

We can just keep tagging them redundantly then. Everybody happy, except maybe the people who backup the data or need to transfer the lot. But that's what we have data compression for, I guess.

Now I need to go find that one bus stop where I only put public_transport=platform, bus=yes as a test case and add highway=bus_stop to it after all.

I had hoped that moving to the new rendering scheme would resolve this, but apparently not. Maybe it's a good idea that somebody amends the wiki page about the 'new' scheme for tagging public transport then to indicate that you can try to use it all you want, but nobody cares if you do. And if you try to use exclusively the 'new and improved' scheme, your data won't be rendered.

Cheers,

Jo

[matthijsmelissen]

@gravitystorm's comment in the substation discussion probably also applies here:

But changing tags has much larger consequences than changing whitespace, or changing a variable name. It is, more or less, our external interface to OpenStreetMap data, and have a look to see how much ABI breakage in the kernel is frowned apon. If we change a tag, then every system that uses that tag needs changing too. Every installation of openstreetmap-carto needs updating. Every customised fork of openstreetmap-carto needs updating. Every stylesheet that uses the original tag needs updating, and every cartographer needs to find the time to investigate and make the changes. And every server that hosts any copy of those stylesheets needs updating. And every customer support request from a user of a map using OpenStreetMap data where their maps are missing some features needs investigating, and every manager needs to figure out where all these man hours are going.

[sb12]

I like the public_transport scheme and use it a lot. It's great for detailed tagging of platforms, bus stops and stations, and it looks also great on special purpose maps (e.g. http://www.öpnvkarte.de/).

BUT: It's a night mare for general purpose renderers where a single icon of a bus in the centre of the bus stop would be sufficient. There are a lot of questions and issues coming up:

• Where do we want to render the symbol (on the platform or on the stop position or in the middle of the stop_area)? (see Add rendering for public_transport=platform #435)
• How do we tell if it's a bus stop, a tram stop or a train stop?
• How do we handle the stop_area relation? How to get the names and other details from the relation?
• We need many additional keys in the database (public_transport, bus, train, tram, light_rail etc.)

BTW: Do you know any other renderer that supports the public_transport scheme? How do they solve these issues?

It's also difficult to handle for a beginner who just wants to add the bus stop in his town or when you don't know exactly where the platform or stop position is.

And I think this complexity is the reason, why the public_transport is not accepted as well as you want to.

I don't understand why the complex public_transport scheme needs to replace simple tags like railway=station and highway=bus_stop. Actually I can't find any place in the wiki where it is recommended to not use highway=bus_stop. In my opinion public_transport should extend but not replace highway=bus_stop.

[matthijsmelissen]

Does the public transport layer handle the new scheme?

[AndiG88]

Where do we want to render the symbol (on the platform or on the stop position or in the middle of the stop_area)?

You have the same issue with highway=bus_stop icon. 10% are actually placed on the street and not at the stop sign. With the public_transport scheme you at least know where it ends up.

How do we tell if it's a bus stop, a tram stop or a train stop?

How do you do it now? railway=tram_stop + buy=yes is basically ignored.
http://www.openstreetmap.org/?mlat=48.36712&mlon=10.89771#map=19/48.36712/10.89771 is just as much a tram stop as it is a bus stop. Maybe we simply should not have a bus icon, but rather something simple like you can see there or some kind of general stop icon, in Germany we for example have this:

We need many additional keys in the database (public_transport, bus, train, tram, light_rail etc.)

We need them just as much now. But as pointed out above we simply chose to ignore combined stops.

It's also difficult to handle for a beginner who just wants to add the bus stop in his town or when you don't know exactly where the platform or stop position is.

Doesn't the platform exactly match the bus_stop?

In my opinion public_transport should extend but not replace highway=bus_stop.

What's the difference between a highway=bus_stop extended with public_transport compared to a stop just tagged with the public_transport schema - apart from the highway=bus_stop (which then would be 1:1: public_transport_platform)?

[matkoniecz]

see also https://trac.openstreetmap.org/ticket/4381 and https://trac.openstreetmap.org/ticket/2798

[kocio-pl]

I agree with AndiG88, but don't know how to make nice quotes here. =} I think highway=bus_stop should be eventually fully replaced (some sunny day), just ask yourself: what type of highway is bus stop?... It was just a dirty hack, probably because there was no evidence we need something more deliberate and consistent at that time.

Now it's a shame to not use the new, properly designed tagging scheme, at least in the main and public transport rendering styles. And I don't mean "burn all the highway=bus_stop!", but for now just promote corresponding public_transport=platform+bus=yes to be the first class citizen in rendering (plus others, as proposed in https://trac.openstreetmap.org/ticket/2798). The code for it is probably straight, but if I would try to write it and test, I want to know it won't be ignored. Is it a fair proposition, or something else is needed too?

[dieterdreist]

Am 09/lug/2014 um 02:22 schrieb kocio-pl notifications@github.com:

what type of highway is bus stop?... It was just a dirty hack, probably because there was no evidence we need something more deliberate and consistent at that time.

I don't see a problem with the highway namespace. For one these are generally tagged on nodes, but even if there was a way (for the "platform") highway = bus_stop this would IMHO be a valid representation for what is actually on the ground and how people would refer to this stretch of asphalt in the real world

[matthijsmelissen]

I think waiting areas for buses are too specific to render as area on a general purpose map, especially if these areas consist of not much more than one painted line on the pavement.

Is there an easy way to distinguish between bus and train platforms?

[AndiG88]

I think waiting areas for buses are too specific to render as area on a general purpose map, especially if these areas consist of not much more than one painted line on the pavement.

Most of them are highway=pedestrian anyway. Also thisissue is not really about that. It's more about having some kind of icon for a public_transport= stop.

[dieterdreist]

Am 21/lug/2014 um 01:47 schrieb math1985 notifications@github.com:

I think waiting areas for buses are too specific to render as area on a general purpose map

when it matters the mapper could add highway =pedestrian and area=yes (the latter might be implicit)

[matkoniecz]

if bus=yes but no other transports are tagged

public_transport tag is available, but bus is not. So 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. (also @gileri)

[gileri]

I am planning to close this feature request as declined. If someone thinks that more detailed explanation would be useful - let me know and I will explain in more detail.

I, like multiple people in this thread, support and use PTv2 for reasons explained on this issue and other resources. I would still like to see PTv2 rendered, but understand that there is still work to do for that to happen.

Please do not close this issue. Even if it was not yet implemented/tested/demoed (no blame thrown here), I feel that this change is something doable, positive, and realistic.

[mkyral]

I's not used because it is not visible. And it is not rendered because it is not used :-(

[PolyglotOpenstreetmap]

Actually, it IS used, both tagging systems are used in combination. One to get the stops to render, the other because it's supposedly more expressive. Unfortunately, it did not solve the problem it was supposed to solve. Instead it even led to people adding details on more than a single OSM object for the same stop. In some places you'll find a stop_position node in combination with a platform way, in others you'll find platform nodes and in yet other places even all 3 of them, sometimes with the stop's details replicated among them. A maintenance nightmare, but alas. And, of course, there are also sill places where the stops are mapped next to the highways, with just a highway=bus_stop tag on them. I tried to to back to that way of tagging. It's not that it doesn't work, it does, but somehow I got used to tagging public_transport=platform/bus=yes additionally on those stop nodes. As far as I'm concerned the most important aspect, is to not have a stop's details on more than a single object per stop. If we could agree to use a node for this object, it would be possible to declare that highway=bus_stop is equivalent to public_transport=platform bus=yes And thus start rendering that combination the same as highway=bus_stop. Then you wait 5 years and you check whether people start replacing the use of highway=bus_stop with that combination. Of course, it may be that this won't work, because there will also be mappers who say: Hey, we use public_transport=stop_position as the main object That's where we want to put railway=tram_stop and tram=yes. Oh well, Polyglot

…

On Wed, Dec 26, 2018 at 10:12 PM Marián Kyral ***@***.***> wrote: I's not used because it is not visible. And it is not rendered because it is not used :-( — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#311 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYcVWVDb25ybopJczl8yS72BhwViHneks5u8-Y7gaJpZM4BZLp9> .

[matkoniecz]

Ok, I will write in more detail. But in short: I consider

highway=bus_stop is equivalent to public_transport=platform bus=yes And thus start rendering that combination the same as highway=bus_stop.

to be undesirable as I consider using multiple tags where one sufficies and is already widely used and supported to be undesirable.

[kocio-pl]

There are uses that are far beyond bus and tram scenario, so it makes sense to render it:

Use public_transport=platform to identify the places where passengers board or alight from public transport of any type, including boarding facilities at airports, bus stations, ports, railway stations, as well as for ski lifts and at roadside bus stops, taxi ranks.

https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform

[kocio-pl]

Rough estimation - currently 72.83% has highway=bus_stop (80.77% has highway=*) and 6.05% has railway=*, which means that ~5% (~60k - well beyond 5k limit) is not related to bus, tram or railway, so it is a unique type of objects we don't render yet:

https://taginfo.openstreetmap.org/tags/?key=public_transport&value=platform#combinations

[PolyglotOpenstreetmap]

You do realise that those numbers are skewed, by the simple fact that stops without highway=bus_stop / railway=tram_stop won't render? If we were to stop caring whether our 70k Belgian stops render, those numbers would already change by about 10%. The circular logic applied favours the status quo and renders the whole public_transport scheme moot, at least for the stops. My reaction to that of a few months ago, was to try and drop the "new" schema altogether, but we're beyond that point as well. So double tagging seems to be the only viable option for the foreseeable future. Polyglot

…

On Thu, Dec 27, 2018 at 9:46 AM kocio-pl ***@***.***> wrote: Rough estimation - currently 72.83% has highway=bus_stop (80.77% has highway=*) and 6.05% has railway=*, which means that ~5% (~60k) is not related to bus, tram or railway, so it is a unique type of objects we don't render yet: https://taginfo.openstreetmap.org/tags/?key=public_transport&value=platform#combinations — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#311 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYcVd-dJaUdtKWdkKyuQzb2VSAxMLcwks5u9IjigaJpZM4BZLp9> .

[kocio-pl]

Yes, I do realize it. The split in tagging is done and refusing to accept it is just closing eyes. I try to show that it is needed anyway, not rendering does not help anything but hurts some valid cases.

[dieterdreist]

sent from a phone

On 27. Dec 2018, at 10:06, Jo ***@***.***> wrote: The circular logic applied favours the status quo

while this is true, it also seems generally a sane choice, imagine what would happen if it were easier to change things than stick with the established tags

[kocio-pl]

Sure, some kind of stability and inertia is a good thing. But change should be still possible for the project to improve. Removing things even in clear cases (like farm retagging to farmyard/farmland) is slow, so there's no fear of chaos. And we're not talking about some random change - it's approved proposal, voted 7 years ago and widely used. It was established before OSM Carto came into existence...

[PolyglotOpenstreetmap]

Not sure about chaos, but I am convinced you'd see the use of highway=bus_stop / railway=tram_stop wane drastically, if the public_transport combinations were rendered independently.

[kocio-pl]

We have double tagging for years, so anybody interested had already a lot of time to prepare. And we're not talking about removing rendering old schemes, so there's no hurry. What else would you do to make the change smooth and avoid chaos?

Lack of change is not kind of smooth change.

[daganzdaanda]

It seems we are rendering
https://www.openstreetmap.org/way/392315371
and not rendering
https://www.openstreetmap.org/way/390222659

It looks as if highway=platform is what makes the platform appear. The English wiki seems to tell people it's on its way out, the German wiki already calls it "replaced" by public_transport=platform.

I think we should be continuing to support highway=platform, but should start treating public_transport=platform just the same.

[jeisenbe]

I'm in favor of closing this issue.

1. public_transport=stop_position is not useful for general map users. Generally the railway platform or bus stop location is where passengers want to go, and bus drivers do not need us to record their stop positions for them.

2. public_transport=platform duplicates the much more common highway=bus_stop and more common railway=platform, and it's confusing because it isn't the same as highway=platform which is an actual physical object.

3. We can't render these properly unless mappers add bus=yes / train=yes etc. to each object. This wasn't part of the original proposal for public_transport, and doing this is twice as much work for mappers compared to just tagging highway=bus_stop.

This was discussed on Tagging last month, and there's also a proposal open which would suggest stopping using public_transport=stop_position and =platform, and continuing to just use highway=bus_stop, railway=platform, amenity=ferry_terminal, etc. - as is the more common practice: https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport

I've considered updating the proposal and bringing it to a vote, but the usage statistics show that this is not really necessary. The suggested system in the proposal is already what's actually used by a large majority of mappers, and what we currently use for rendering.

[kocio-pl]

I don't understand the the claim 3 - what do you mean saying that we can't?

I see public transport platform rendering as very clear in meaning. The important part is not bus/tram, but universal meaning. See the problem we have with public transport terminals/stations rendering, which we started to discuss in #3257 lately. We don't have to review every possible transport existing on earth to know what a platform means and that it's important for people. For example seaway=* proposition or amenity=ferry_terminal omits this problem completely. The fact, that the most popular transport types has their own platform defined, does not help all the other types, and I don't think this is good.

[matkoniecz]

I don't understand the the claim 3 - what do you mean saying that we can't?

public_transport=stop_position may be for either bus or tram or something else

[kocio-pl]

Still I don't understand what "can't" means here. IMHO rendering generic platform (shape and name) is easy and we can render more elements if more precise data is here. Also it's quite simple to make presets for popular platforms to avoid unneeded typing, if you think this is a problem, or just make bus or tram default value.

In return we get semantic and flexible solution without discovering new tag for each type of public transport and making style codebase large and consisting of special cases.

[jeisenbe]

I see public transport platform rendering as very clear in meaning

It only represents "the place where passengers are waiting for the vehicles," so it doesn't represent a physical highway=platform (a flat, elevated area that facilitates boarding a bus), but it's the same as highway=bus_stop (a place where passengers wait for a bus). And since it can also be used for aerialways, ferries and trains, the meaning less clear than highway=bus_stop. While the proposal said that only real platforms should be mapped as an area, there are over 5000 highway=bus_stop + public_transport=platform without highway=platform which are mapped as closed ways: https://overpass-turbo.eu/s/M8J - so rendering these the same as highway=platform would be a mistake.

We can't render these properly unless mappers add bus=yes / train=yes etc. to each object
Still I don't understand what "can't" means here

I mean we can't use the current rendering with a specific icon for highway=bus_stop unless mappers are required to add bus=yes, train=yes, ferry=yes, aerialway=yes` etc - tags which were not required as part of the "public_transport" proposal (they were suggested with stop_position only), and not used universally.

For example, 76.0% of public_transport=platform are tagged with highway=bus_stop and 6.3% with highway=platform but only 60.7% are tagged with bus=yes or trolleybus=yes (https://taginfo.openstreetmap.org/tags/public_transport=platform#combinations)

Rendering all public_transport=platform like railway=platform or highway=platform would be incorrect, because as mentioned, most are on highway=bus_stop nodes, which normally lack a physical platform. And a small number of public_transport=platform are for where passengers wait to board an aerialway or ferry - quite different features, which also have different renderings currently.

Encouraging mappers to add bus=yes + public_transport=platform to every highway=bus_stop and highway=platform is extra work for mappers which was not envisioned by the public_transport proposal. There are 410,000 public_transport=platform nodes (not countying ways) which lack any tag bus=/train=/trolleybus=/subway=/aerialway=/ferry= tag: https://overpass-turbo.eu/s/M8F - but most of these have highway=bus_stop or railway=platform so they are handled fine by most database users currently.

we get semantic and flexible solution without discovering new tag for each type of public transport

I consider a tag that can be used for a ferry pier, an aerial gondola stop, a bus stop, a tram stop, and a train platform to be far too flexible and not clear in meaning. But let's discuss the tagging system at https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport rather than here.

[matkoniecz]

According to the PTv2 proposal itself data consumers are supposed to distinguish between bus stop, tram stop, train station or a ferry terminal NOT by using vehicle tags.

PTv2 proposal documents that it should be done using standard tags like highway=bus_stop, railway=tram_stop etc. PTv2 is not a replacement for simple tagging (sometimes called PTv1), it was at least described as an optional extension that is not deprecating anything.

Later some mappers (or maybe a separate group?) started using vehicle tags also for stop positions, with some voices calling for deprecation of tags like highway=bus_stop with public_transport=platform + bus=yes style tagging. But it is not what was disccused and voted on in PTv2 proposal.

It is method that was like original tagging scheme never voted on (AFAIK), is more complex and less popular

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

Therefore, by rendering highway=bus_stop and similar simple tags we are already following PTv2!

ongoing dominance of standard and simple tagging (see #435 (comment) ) and lack of documentation why significantly more complex and confusing tagging scheme would be wanted (see #435 (comment) ).

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.

I am therefore closing this issue as declined. See also comment above.

And please, read at least entire discussion in this issue and in #435 before commenting to avoid repeating things (except pointing out any parts in my comment that were untrue).