Better support to derive stop names

[stefanct]

In some situations unroll seems unable to derive the (correct) name of stops. Apparently it does neither consider public_transport=stop_area nor public_transport=stop_position relations or the node with highway=bus_stop (which could be the platform or stop position on the roud) and then prints "unamed stop" if the name cannot be found in the public_transport=platform object.

In other cases it uses the commonly wrong name of platforms or stop positions (e.g., name=A which should actually be ref=A). Both could be avoided if unroll would take stop_areas into consideration and give their name tags priority over other name sources. Additionally, I would suggest to look for the highway=bus_stop/tram_stop entity and use its name value. This corresponds to the legacy scheme to tag PT in OSM.

[nlehuby]

Thanks for your feedback.

Unroll only uses the role in the route relation to get the stops objects (it does not check for public_transport=platform or highway=bus_stop, etc). And this stop object is supposed to have a correct name.

The stop_area relation is for grouping features in a same interchange, I do not see the connection with the issue of the name you are talking about 🤔

Can you provide examples where it does not work as expected ?

[stefanct]

The stop object (i.e., members of the route relation with role "stop") in a PTv2 scheme is a node with platform=stop_position. If used correctly (and without a legacy highway=bus_stop or tram_stop) it will not have a name tag because the stop position is unnamed in reality. The name of the station in PTv2 is only stored in the stop area object (this avoids redundancy).
stop_area relations group together what is collectively referred to as a stop/station.
There might also be a public_transport=station but only for bigger stations not simple bus/tram stops with only two platforms, which also might hold a name often identical to the station.

Unfortunately, because the documentation is so spread out and often contradictory, the use of the legacy PT scheme still ubiquitous and the OSM community failing at properly using name tags, this is easy to get wrong as you almost always will find a name tag on the stops because it is required if highway=bus_stop/tram_stop is used and thus taking the name of the stop objects usually works fine.

However, I am not sure if the "unamed stop" outputs I have encountered are actually related to this because at least the current data would lead to a different result. Maybe the data used by unroll is outdated? What's your verdict about this? https://jungle-bus.github.io/unroll/route.html?line=29530

[nlehuby]

Actually, there are two kinds of stops : the platform and the stop_position.
As we only need one stop, Unroll displays the one that is most likely to be present in OSM. For buses, it is the one with the platform role.

Personally, I think that the name should remain on the object that represents the stop because it is simpler for both the contributor and the data user (It's a bit unfortunate that it's redundant, but I don't know any editor or data user that will recursively look to see if they can display a name from some relation if present before displaying the one from the name tag on the object). Especially since, as you point out, the name is required on highway=bus_stop objects and the ptv2 scheme clearly indicates that the public_transport tags are not intended to replace pre-existing tags. So I see no reason not to put the name on these objects.

So in your example, I would suggest to move the name and the highway=bus_stop tags from the stop_position to the platform objects to make it ok. This one for instance is already ok.

The update date of the data is displayed at the bottom of the Unroll page, just before the footer.

[Hidooo]

@nlehuby No, platforms and stop_positions together form one stop, as stefanct explains. The PTv2 scheme is unfortunately pretty complicated, but you can check if it's being used (the tagging of PT version is mandatory in PTv2), to be able to know where to look for the correct tags. Name tags are only mandatory on the stop_area relation, but are also common on the stop_position. Never on the platform, which however often has a name tag anyways: the ref that should, but isn't always, moved to the ref tag.

The bus stop you link to doesn't use PTv2. It would not render correctly if the renderer only followed the PTv2 scheme, hence the need to, as you've identified, also look for older tagging schemes.

And all major renderers, apps and editors support the PTv2 scheme (carto, OsmAnd, Organic Maps, ÖPNVkarte, iD, JOSM etc). And while PTv2 didn't replace pre-existing tags, it made them obsolete and no longer necessary to use when mapping new public transport infrastructure, so you definitely need to follow the PTv2 scheme for routes to render correctly and display the correct names on the website. This page provides a good summary.