Update public transport tags for STAN french network in analyser

[simonpct]

Hello,

We recently started adding the gtfs:stop_id:FR-GES-STAN= tags to platform elements based on GTFS and PTNA data. However, the current Osmose analyser does not recognize these stops, so adjustments are required for proper detection.

Previous tags:

New tags:

Example screenshot:

Would you mind reviewing my PR and confirming if the changes meet the requirements for Osmose integration? Thank you for your time!

[simonpct]

Up ? Thank you !

[frodrigo]

@nlehuby Can we have your review of this PR, please ?

[nlehuby]

Hello,

Bus stops here seem to be mapped in a rather unusual way compared to what is done in France (see in particular https://wiki.openstreetmap.org/wiki/FR:Bus#Arr%C3%AAt_de_bus), with a highway=bus_stop on the public_transport=stop_position, and an isolated public_transport=platform, mapped as a polygon.
This does not seem very sound to me (even if it remains broadly compatible with the approved transport scheme). Unless this is the result of a concerted decision by the local community, I would suggest cleaning up this point before carrying out open data integrations.

Regarding integration:

• The ref tag must correspond to a reference or identifier visible in the field. Is this the case here: can we see the actual GTFS stop_id displayed at bus stops?
• Is it really useful to add gtfs:location_type:FR-GES-STAN=0 to all stops?
• Is there a difference between the names displayed in the field and the names in the GTFS that would justify having both name and gtfs:stop_name:FR-GES-STAN tags?

[simonpct]

Hello,

Thank you for your feedback,

I followed PTV2 without fully integrating the common attributes,
I will adjust the mapping approach in the PR to align with established conventions.

Regarding the GTFS tags:

• ref: I will use the stop code for the ref tag, as this identifier is consistently displayed on the bus stops.
• gtfs:location_type: This is indeed not mandatory and I will remove it.
• name vs. gtfs:stop_name: I still think we should keep both. The name tag is necessary because the GTFS data often truncates stop names and can have accent-related display errors, meaning we cannot rely on it for the accurate, on-site name.

I will clean up the mapping and the tags based on these points.

[simonpct]

I followed the ptv2 and the gtfs pages on the wiki :

https://wiki.openstreetmap.org/wiki/GTFS#Step_3:_Reference_the_object

[nlehuby]

Regarding the model, what is unusual is not the use of public_transport=platform, but rather

• the fact that the highway=bus_stop tag is not on the same object as public_transport=platform
• the fact that public_transport=platform is on an area

The usual model generally proposes:

• a node with highway=bus_stop and public_transport=platform
• a node with public_transport=stop_position and bus=yes
• possibly a way or a closed way, with highway=platform, if there is something on the ground that physically delimits a quay or platform as such (this is still quite rare for bus stops)

And the examples reported by your overpass query correspond to train platforms and not bus stops, so the comparison is a little biased.

Regarding the open data integration, thanks for the changes.
I think it would be better to merge using gtfs:stop_id:FR-GES-STAN as conflation id (osmRef var), as the stop_id is guaranteed to be unique in the GTFS (which is not the case for stop_code). But this is only a suggestion: I haven't looked at this particular GTFS, so if stop_code is also unique and permanent, the current version is fine.

[simonpct]

• highway=bus_stop is meant to be used on nodes only, so i din't add them
• highway=platformseems optionnal based on the wiki

• Bus stops in strasbourg currently use the same schema : no highway tag, gtfs, and platforms as closed ways.

• and the schema currently used in Nancy completely pass the PTNA validator (https://ptna.openstreetmap.de/gtfs/compare-trips.php?feed=FR-GES-STAN&release_date=&trip_id=1_63509651&relation=2074460)

[nlehuby]

Please note, I never said that your mapping choice was wrong, I'm just saying that it's not the most common method in France.
Of course, you can find places where that's how it's done in OSM, the public transport schema is a mess: there are a multitude of practices that are more or less compatible with each other, wiki pages that contradict each other, and new proposals for schema improvements every two years...

I'm just saying that your way of mapping stops on this network is unusual.

In concrete terms, if a non-local contributor passes by and spots a missing bus stop, whether they are a beginner or experienced in the topic of public transport, I don't think they will naturally map that missing stop with an area with public_transport=platform: this is not the most common practice. So there is a risk of developing inconsistencies within the network over time, which will complicate its maintenance for the contributors and the usability of the data.

In any case, you are free to stick with your current approach, because it is indeed compliant with the approved schema, which focuses primarily on the use of the public_transport tag.
But in my opinion, unless it is a decision agreed upon by the local community and there are real arguments to support it and documentation on the wiki that explains why it make more sense to map the bus stops as areas, etc, it would make more sense to switch to the more usual model that I described earlier.

[simonpct]

Thanks for the advice!

So the best approach should be to :

• Map platforms as unclosed ways
• Document the wiki thoroughly
• Add the corresponding highway tags

Does this sound right?
Regarding GTFS infos, can it still be stored on the platform object instead of the stop_position?

Thanks again!

[simonpct]

Thank you again for your valuable feedback.

According to GTFS, we will keep GTFS tags on public_transport=platform as closed ways only (also in order to maintain PTNA usage).
This approach will be clearly documented in the Nancy/STAN wiki for consistency. :)

The commit implementing these changes is ready.
I remain open to any further modifications you may suggest, but unless there are objections, it is ready to merge.

Best regards,
Simon