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.
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 ?
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.
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.
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.
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.
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…
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.
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.