Harmoniser les tags operator et network sur les gares d'Île-de-France

Bonjour.

Les gares d’Île-de-France (nodes railway=station) présentent une grande diversité de valeurs pour les tags network et operator, avec beaucoup de valeurs absentes et quelques incohérences.

Tag operator (cf. requête overpass turbo) :

count value
297
4 Disneyland
100 RATP
1 RATP / SNCF
2 RATP Ile de France Mobilités
4 RATP Transilien SNCF Ile de France Mobilités
373 SNCF
1 SNCF LMobilités
2 SNCF Réseau
2 SNCF;RATP
1 Transkeo
787 TOTAL

Tags network (cf. requête overpass turbo) :

count value
565
3 CDGVAL
1 De Paris Saint-Lazare à Versailles Rive Droite
1 Ligne 7
1 Ligne L
2 Ligne N
1 Métro
2 Métro 1
6 Métro de Paris
14 Métro de Paris;RATP
1 Métro de Paris;RER
1 Paris Saint-Lazare
14 RATP
12 RER
1 RER (RATP SNCF)
2 RER B
2 RER B4
1 RER Parisien;RATP
1 RER d’Île-de-France
4 RER;RATP
1 RER;Transilien
2 Réseau Express Régional
1 SNCF
1 SNCF Réseau
1 SNCF.
2 Saint-Lazare
2 Tramway d’Île de France;RATP
132 Transilien
1 Transilien Paris Nord;Transilien Saint-Lazare;RER
1 Transilien Saint-Lazare
2 Transilien Saint-Lazare;RER
1 Transilien, Intercités, TER, TGV
1 Transilien;TER Picardie
1 transilien L
3 Île-de-France Mobilités
787 TOTAL

Je propose d’harmoniser ces 2 tags. Pour le tag operator c’est assez simple : il s’agit du gestionnaire de la gare, pour la plupart SNCF ou RATP (parfois les 2, par exemple Val de Fontenay). D’accord pour ça ?

Pour le tag network c’est plus compliqué. Le wiki décrit ce tag pour les relations route, mais je ne souhaite pas passer par ces relations (car incomplètes et difficiles à maintenir). Je voudrais pouvoir indiquer sur une gare par quels types de lignes elle est desservie : Métro, RER, TER, Grandes Lignes, TGV, peut-être Grand Paris Express etc. Que pensez-vous d’utiliser ces valeurs (parfois multiples) pour le tag network sur les nodes railway=station ?

1 Like

Bonsoir,

Je viens de parcourir rapidement la page du wiki France/Transports en Île-de-France - OpenStreetMap Wiki

Il semblerait qu’il existe un GTFS, celui ci devrait pouvoir servir de base pour harmoniser les noms des différents « network ».
Ensuite ajouter un tag network:wikidata permet de s’affranchir des problèmes de graphie des noms.

Marc

Bonsoir,

Personnellement je ne pense pas que le tag network soit d’une grande utilité pour les gares ou mêmes les arrêts de transports en commun (pour les arrêts l’utilisation du tag network=* est même indiqué comme erreur par Osmose). Une gare peut être utilisée par plusieurs lignes de transports en commun de différents réseaux et garder l’ensemble cohérent deviendra vite difficile. L’ouverture programmée de la concurrence ne va pas contribuer à améliorer cette situation bien au contraire.
Cet usage de network est un peu comparable avec l’usage du tag route_ref=* qui est utilisé pour indiquer les lignes de transport en commun qui passent par cet arrêt/plateforme mais reste terriblement difficile à maintenir à jour.

Il me manque les connaissances informatiques pour livrer une solution clefs en main, mais je reste persuadé qu’en retournant le problème il est possible d’obtenir les informations voulues : pour chaque gare regarde quels types de lignes (voir quels réseaux) passent par cette gare et donne moi une valeur agrégée pour chaque gare.

Bonne continuation,

Patchi.

Bonsoir Antoine,

Je salue ta démarche, c’est très utile

Peut-être me tromperais-je mais une gare est-elle vraiment exploitée par deux exploitants différents ?
Val de Fontenay semble coupée en deux (RER et pas RER).
Je déconseille de mettre des listes dans la clé operator. Il faut trouver un découpage des sites qui convienne pour matérialiser la limite entre les domaines de chaque exploitant ou bien indiquer l’exploitant principal qui doit facturer aux autres.

On a le même cas dans l’énergie, mais il n’y a quand même qu’un seul operator=* dans tous les cas
https://wiki.openstreetmap.org/wiki/Power_networks/France/Exploitants#Séparation_transport/distribution

Pour ce point je suis d’accord avec @Patchi, on cherche à vouloir faire rentrer une collection qui découle de la topologie dans une clé.
C’est moins problématique que le cas d’operator=* ci-dessus mais pas évident dans l’exploitation et la maintenance non plus.

Voyons d’autres avis, bonne soirée

Il me semble que c’est SNCF Gares & Connexions qui gère les gares de voyageurs des voies de chemin de fer en France. Réseau ferré national (France) — Wikipédia
Sur leur site, il y a la listes des gares, il y en a 3000
https://www.garesetconnexions.sncf/fr/gares-services/liste-gares

Pour le métro c’est différent et lorsqu’on a station de métro et gare ferroviaire je ne sais pas comment ça marche

A priori, oui, idem pour les propriétaires qui peuvent être multiples, ou pas.
Wikipedia indique cela.

  • Val de fontenay
    propriétaire : RATP;SNCF
    exploitant : RATP;SNCF
  • Nanterre Université
    propriétaire : RATP;SNCF
    exploitant : RATP;SNCF
  • Châtelet - Les Halles
    propriétaire : RATP
    exploitant : RATP;SNCF
  • Aéroport CDG 2
    propriétaire : SNCF;ADP
    exploitant : SNCF; ?

etc…

Sur le terrain, ça peut se voir, ou pas. Nanterre Université à tout le bâtiment voyageur au couleur Ratp, il y a juste 1 guichet aux couleurs SNCF. Pour les quais, c’est en fonction de la ligne qui y passe.

C’est assez facile d’obtenir une valeur agrégée avec une requête Overpass.

Je suis assez d’accord que le tag network est plus pertinent sur les lignes que sur les gares, mais ça suppose que les lignes soient bien décrites et c’est bien plus difficile à maintenir. Les lignes de RER ont de nombreuses branches, et il existe de nombreux trajets différents – théoriquement autant de relations route. Le RER C par exemple compte par moins de 37 missions, selon Ligne C du RER d'Île-de-France — Wikipédia.

Il semble y voir différentes pratiques de mapper ces lignes sur OSM. Pour le RER C les relations route correspondent à des tronçons (par exemple RER C Tronçon C2 - Massy Palaiseau → Choisy-le-Roi). Pour le RER B elles semblent correspondre à des missions (par exemple RER B5 : Massy-Palaiseau → Mitry-Claye). Je ne sais pas quand et comment ces choix ont été faits, mais ça ne facilite pas leur utilisation et leur maintenance.

D’où ma proposition d’utiliser network aux gares, pour faciliter l’identification des gares desservies par les différents réseaux. Certes pas idéal ni courageux mais pragmatique…

1 Like

Faut que j’aille voir la source.
Cela m’étonnerait que l’exploitation soit conjointe tant le facility management à plusieurs est compliqué.

Sur OSM il y a déjà deux gares distinctes et il me semble que ce serait une bonne chose pour distinguer la partie SNCF de la partie RATP.

Tu as la partie Société du Grand Paris qui arrive aussi bientôt là-bas.

Donc dans un pareil cas, on mettra operator=RATP n’est-ce pas ?
Disposer d’un guichet à l’intérieur de la gare ne suffit pas pour en devenir exploitant à mon avis.

Je ne sais pas. N’oublie pas le quai qui est aux couleurs Transilien/Sncf.

Le schéma PTv2 est à mon avis assez clair sur cette question :
Each direction or variant of a route is represented by a separate relation.
Fastidieux je l’avoue et je n’ai pas commencé à appliquer ce système au départ lors de mes premiers essais pour mapper des lignes de transports en commun. Mais dès lors que l’on essaie de vérifier le trajet de lignes avec des fichiers GTFS, cela devient vite indispensable de mapper chaque variante séparément. Et je pense que les tracés de lignes de chemin de fer ne changent pas beaucoup dans le temps comparé aux lignes de bus. Donc un projet d’envergure mais qui va durer dans le temps / où la maintenance est possible. De plus certains outils bien pensé facilitent grandement la maintenance de ces réseaux, je pense surtout à un outil comme PTNA hébergé par nos collègues OSM d’Allemagne qui permet une maintenance rapide d’une multitude de réseaux.