Transport en commun (bus) en Loire-Atlantique (44)

Bonjour à toutes et à tous,
Suite au post de @maelito2000 au sujet de cartes.app, j’ai jeté un coup d’œil à l’état des transport en Loire-Atlantique. On y dispose de réseaux métropolitains (STRAN à Saint-Nazaire et TAN à Nantes), ainsi que des cars interurbains gérés par la région (réseau Aléop). Pour chacun, un GTFS est disponible sur transport.data.gouv.fr.
Dans OSM, suivant les cas, ces arrêts peuvent être décrit comme:

  • ref=FFAU3 avec une valeur à jour vis à vis des GTFS, avec (ou non) mention du réseau grâce à l’attribut network=,
  • ref=LIL9194N avec une valeur obsolète correspondant à l’ancien réseau départemental Lila (abandonné en 2019 au profit de Aléop),
  • absence totale de ref.

Je pense qu’il serait souhaitable de mettre en œuvre la chose suivante:

  • De manière programmatique, rapprocher les arrêts ayant déjà une ref avec les fichiers stops.txt des GTFS pour identifier le réseau correspondant. A l’instar de ce qui se pratique à Rennes ou en IDF, stocker ces références dans de nouvelles clefs ref:FR:TAN, ref:FR:STRAN et ref:FR:aleop.
  • Dans un second temps, rapprocher via coordonnées des arrêts n’ayant pas de tag ref ou un tag ref absent des GTFS avec les arrêts des GTFS, et stocker les références dans les nouvelles clefs ref:FR:TAN, ref:FR:STRAN et ref:FR:aleop.

D’où ce message pour avoir vos avis sur le sujet, notamment s’il y a des points que j’aurais manqué. Je précise que je souhaite prendre mon temps avant de faire quoi que ce soit pour éviter les bêtises…

2 Likes

À Nantes, ce n’est pas Naolib ?
Avant de s’attaquer à du rapprochement spatial, il faut vérifier la qualité du GTFS

  • vérifier sur les arrêts en commun
  • position de l’arrêt par rapport au tracé/shape (distance, du bon côté)

Il me semble que Nantes est couvert par citymapper, si c’est le même jeu de données il ne devrait pas y avoir de problème.
Pour Saint-Nazaire, c’est une appli propriétaire ? si oui le risque est plus grand.

Une question :
quand un réseau change de nom, quelle est la règle pour l’attribut network:wikidata ?

Bonjour,

Pour Nantes/TAN, voici quelques chiffres :
-en interrogeant avec l’overpass, de l’ordre de 2500 arrêts;

  • le GTFS en a un peu moins de 2400;
  • que 262 arrêts OSM avec une référence ref:TAN;
  • dont 180 à plus de 5 mètres du stop GTFS correspondant.

Le rapprochement peut se faire aussi se faire itinéraire par itinéraire.

Marc

Pour Nantes même (ville et non agglo), overpass me renvoie 850 arrêts dont quand même 640 avec ref=*, d’où ma proposition de rapprocher via les identifiants dans un premier temps pour limiter les rapprochements géographiques. Je pense que ça devrait bien marcher et permettre d’homogénéiser le réseau de la métropole, et qu’il soit distinguable du réseau régional.

Bien vu, je n’avais pas vu leur rebranding en Naolib qui date de l’automne dernier. Ça a permis de regrouper Tan avec le service de vélo en libre service notamment.

Pour le réseau régional, un nouvel identifiant wikidata a été créé (Aléop - Wikidata). Le périmètre étant différent (plusieurs régies départementales vers une régie régionale), la création d’un nouvel identifiant me semble ok.

Pour Nantes, le réseau Tan a été renommé en Naolib (public transport in Nantes - Wikidata). Le wikidata de Bicloo reste inchangé à ce jour (Bicloo - Wikidata).

J’interroge via les relations route

relation[type=route][route=bus][network="TAN"]->.a;
(
  nwr[highway=bus_stop](r.a);
  nwr[public_transport=platform](r.a);
);
(._;>>;);
out meta; 

cela récupère aussi les public_transport=stop_position qui n’ont pas à priori de ref.

Je viens de faire un essai de rapprochement spatial:
diff_stops_absents_osm.csv (83,9 Ko)

J’étais sur Nantes ce week-end et sur les cars de la région le logo est Aleop et non Aléop.
La région n’a pas l’air très claire sur la bonne graphie.

On a en Loire-Atlantique 3760 nœuds d’arrêt de bus dont la ref commence par ‹ LIL ›, ce qui correspond aux anciens identifiants du réseau Lila, importés en 2012. Cela permet de détecter les arrêts à rapprocher avec Aléop.

A noter également, le réseau Brévibus à Saint-Brévin les Pins : Réseau urbain Brévibus - Données (GTFS, gtfs-rt) ouvertes - CC du Sud Estuaire

Malheureusement, la région a procédé à une renumérotation des arrêts et l’actuel fichier stops.txt ne contient plus la correspondance dans sa pléiade de champs excédentaires.

Il existe un fichier d’agrégat pour la région, je pense qu’il serait préférable de l’utiliser quand le réseau y figure.

Je les avais manqués, on a également 255 nodes en avec ref:TAN (overpass turbo) et 21 nodes avec ref:Lila (overpass turbo). Ces arrêts sont concentrés le long des lignes de tram, et on été référencés par @Virgile1994 il y a 6 ans.

Je vais essayer de migrer en schéma PTv2 les arrêts du département avant d’essayer de faire des rapprochements, cf signalements osmose.

Je n’ai pas trop compris. Tu suggères de mettre à jour simplement les arrêts pour qu’ils soient en conformité avec PTv2 ou carrément s’assurer d’avoir toutes les lignes vienrenseignées en PTv2 avec la relation qui va bien ?

Je reconfigure juste les arrêts comme indiqué dans le blog de Noémie.
L’objectif est d’avoir les « platform » dans ce schéma pour faciliter le rapprochement avec les GTFS.
Je teste sur Saint-Brevin-les-Pins le rapprochement et l’actualisation des relations route=bus. Même sur un petit réseau de 5 lignes, JOSM/PT_assistant génère beaucoup de messages.

@Marc, en parcourant les données OSM, je note que tu taggues avec ref:Aléop44 overpass turbo
Tu utilises quel GTFS de référence? De mon coté je regarde celui-ci Réseaux interurbains Aléop - Pays de la Loire - Données (GTFS, gtfs-rt) ouvertes - Pays de la Loire. Je remarque que tes ref:Aléop44 ne correspondent pas aux stop_id de ce fichier mais aux old_id, tu as ça en tête? De mon coté je pensais me baser sur le fichier ci-dessus avec une ref:Aleop ou ref:FR:Aleop. L’avantage étant description de toute la région et pas seulement de la LA.

J’avais regardé ce site national qui pointe vers le site régional Index of /data
J’ai trouvé un fichier pdl44.zip et dans ma paresse je me suis dit que cela suffirait pour commencer une actualisation sur la région et ses 286 lignes (que 66 pour le 44), ma connaissance des autres départements de PDLL est très faible.
J’ai aussi trouvé un fichier gtfs-lila1.zip avec des données de février 2018.

J’ai essayé de faire coller les références sur les relations route=bus avec celles d’un GTFS puis de faire coller les références des arrêts avec les stops de ce même GTFS.

Je vais poursuivre avec ce GTFS plus récent si je ne suis pas trop occupé sur Rennes avec la refonte du réseau BUS suite à l’arrêt de longue durée de la seconde ligne de métro.

J’ai collé 940 références du GTFS mais il en reste 368 orphelines.

J’ai des cas de même « name/stop_name » dans une commune mais avec une distance entre les deux supérieure à 150 mètres (ma limite dans ce cas pour faire coller). En échantillonnant cela correspond souvent à des arrêts sur un autre axe, donc à priori non rapprochable.

Pour les différences de nom (exemple Église Barbechat/Barbechat), je cherche une méthode pour les points proches, des idées ?
diff_stops_absents_osm.csv (23,2 Ko)

J’ai regardé un peu en détail hier sur la ligne 330.
Voici

  • l’arrêt Boire Courant (44CONCboirR) a bien été rapproché de l’arrêt correct dans osm, mais la position dans osm n’est pas bonne.
  • l’arrêt La Quintaine (44CONCquinR) n’a pas été correctement rapproché. Plus précisément, un seul sens de circulation est présent dans osm, et vu la position de l’arrêt par rapport à la route cela correspondrait à 44CONCquinA
  • L’arrêt La cour du Chêne est carrément absent de OSM

De mon côté j’ai fait un petit script pour extraire tous les arrêts d’une ligne donnée à partir du gtfs, et f rapprocher ligne par ligne par conflagration dans Josm …