Hello,

Merci pour ton retour. Effectivement, j'ai oublié de supprimer la note.

Mon objectif était de supprimer les tags public_transport=station et railway=station du polygone (footprint) afin d'éviter les doublons de données et de rendu (comme sur OSM ou carte.app). C'est un problème récurrent qui ne concerne pas que la gare de Lorient, mais des dizaines de gares en France.

Je vais en discuter sur le forum dans la semaine afin qu'on trouve un consensus sur ces histoires de nœuds et polygones qui possèdent les mêmes tags et créent des doublons.

Hello,

Thank you for reaching out. These changes are intentional and follow a consensus reached within the French OSM community regarding major railway hubs (Paris Nord, Austerlitz, etc.).

The Context: We are aligning OSM data with the Document de Référence des Gares (DRG), which is the official national reference document for railway stations in France. According to the DRG, entities like "Gare du Nord Surface" and "Gare du Nord Souterraine" (Underground) are distinct administrative entities with different Reference Codes (UIC), operating on different levels. Merging them into a single node creates factual inaccuracies against this official reference.

The Validator Issue: We grouped these distinct railway=station nodes into a single stop_area relation to maintain logical grouping for consumers (like Transilien/SNCF apps). The "Subway Validator" error "Stop area has multiple stations" seems to stem from a strict 1-to-1 expectation (Metro logic) which does not fit complex Heavy Rail hubs.

Regarding "Broken Data": Could you specify exactly how this breaks the application? Ideally, the parser should be able to handle multiple stations within a hub. We believe the tool should adapt to the reality of complex hubs rather than degrading data accuracy to fit the tool.

Technical Question: Does your parser/application fully support the public_transport=stop_area_group relation (PTv2 standard)? If yes, we could migrate to a cleaner structure (one stop_area per UIC, grouped in a parent stop_area_group). If not, we must keep the current configuration to ensure connectivity.

Hello,

Thanks for the check.

Fair enough. As a geomatician, I used this method to simplify SQL queries on my end. I usually work on the French network where it is unfortunately quite rare to find stations properly organized in relations, hence the habit.

However, I agree that since the stop_area relation is perfectly structured here in Brussels, duplicating the tag is technically redundant.

I will leave it as is (clean) for this location and won't duplicate the code on the stop positions here.

Hi, you're right, I swapped two tags. The change has been made, thank you.