Le réseau TBM va beaucoup changer le 4 septembre 2023. Il est déjà pas à jour sur OSM, ce serait un bon moment pour tout reprendre.
On a la nouvelle carte sur tbm2023.infotbm.com pour avoir un aperçu. Le jeu de données va probablement être mis à jour le jour même. On peut déjà se concentrer sur les arrêts avant cette date.
J’avais déjà commencé à mettre à jour certains arrêts par commune en ajustant leur position, mettant leur nom à jour, et en rajoutant leur ID (mais ça prend beaucoup de temps, je les vérifie tous à la main) ce qui pourrait permettre à terme de vérifier s’ils ont changé sur le jeu de données des arrêts de la métropole ainsi qu’à ajouter automatiquement les attributs sur l’arrêt (le type d’abribus étant spécifié sur le jeu de données).
Elle affiche des tuiles bitmap : https://tiles.lc.tools/services/bordeaux-tbm-network-before/tiles/{z}/{x}/{y}.png https://tiles.lc.tools/services/bordeaux-tbm-network-after/tiles/{z}/{x}/{y}.png
Mais aussi elle transforme des données en geojson pour chaque commune.
Dans un premier temps les tuiles bitmap devraient aider à vérifier ou faire la saisie dans OSM.
L’idéal serait d’extraire les données vectorielles.
Bonjour,
Sur Rennes, nous avons eu quelque chose qui y ressemble avec la seconde ligne de métro : Avant/Après : l'évolution du réseau | STAR Nouveau réseau
L’opendata est en version GTFS ce qui est un peu plus standard.
Effectivement la première étape a été d’ajouter des références type « ref:FR:STAR » (car le network est « FR:STAR ») sur tous les arrêts. La seconde a été de le faire pour les routes avec les shapes.
Marc
Sans vouloir anticiper le 4 septembre. L’extension du Tram A allant à l’aéroport à ouvert hier. J’ai passé les stations qui ne sont plus en construction à ouverte, idem pour les voies.
Coté voirie adjacente, j’ai corrigé plein de chose pas à jour, mais sans ortho ce n’est pas facile.
La ligne de bus 1 qui allait à l’aéroport existe toujours, mais depuis les travaux elle fait des détours. J’ai essayé de ne pas casser la relation. Mais elle n’est probablement pas à jour.
Pour la relation du Tram A je n’y ai pas touché coté extension. Elle fait déjà un fourche de l’autre coté. Maintenant il y a aussi une fourche de ce coté. Il y avait deux relations, je ne sais pas combien il en faut maintenant.
Toutes les lignes sont chargées au lancement de la carte, c’est des polylines encodées que l’on peut décoder en reprenant le code du site.
Les données ne sont pas encore publiées en open data, je ne sais pas si on peut les utiliser maintenant, même si je ne pense pas que TBM ou la métropole s’y opposent.
C’est comme pour les bus, une relation par variation, toutes contenues dans une relation route_master. Il y a quatre membres actuellement dans la relation route_master, ça en ferait quatre de plus (un aller et un retour par branche opposée).
Elle ne dessert plus l’aéroport à partir du 2 mai. Le détour effectif jusqu’en septembre 2024 n’est en effet pas sur la relation. Il n’y aura qu’un prolongement en septembre donc on peut modifier maintenant sans tout perdre dans quelques mois.
C’est le jeu de données Arrêt physique sur le réseau SAEIV avec l’attribut IDENT. Sur ce jeu de données, lorsque la source est SIG_KEOLIS, l’arrêt n’existe pas (certains sont quand même présents dans OSM mais pas sur le terrain). Il faut prendre les arrêts dont la source est SAEIV_BUS (ou SAEIV_TRAM). Je sépare le jeu de données par commune (avec le code INSEE) et j’utilise le plugin conflation de JOSM pour les lier aux arrêts existants. Puis je les regarde tous un par un pour corriger leur position ou leur nom et rajouter l’ID. Certains sont un peu éloignés sur le terrain par rapport au jeu de données mais c’est assez rare, cela peut faire que conflation le lie au mauvais arrêt.
Comme montré dans le dictionnaire, on peut ensuite mettre les arrêts en relation avec les autres jeux de données pour leur mettre automatiquement les bons attributs (par exemple les abribus).
Bonjour
Très bonne initiative de lancer ce sujet @m.ezd J’avoue que j’attendais qu’une personne « locale » lance le sujet afin de voir comment coordonner nos efforts et anticiper la grosse refonte de tout le réseau. J’ai déjà regardé un nombre incalculable de fois le plan papier. Ne résidant plus sur Bordeaux mais à Toulouse, difficile pour moi de voir les évolutions terrain.
J’avoue que la thématique des TC m’a donné envie de contribuer sur OSM.
Je ne serai pas d’avis d’ajouter les attributs liés aux équipements d’abribus (sauf déjà existants). Évidemment si tu es sur le terrain, tu peux y aller. Il ne faut pas les rajouter et laisser faire StreetComplete à ce niveau.
Avant toute chose, il faudrait axer les mises à jour du réseau actuel sur les axes qu’emprunteront les futures lignes Il sera plus simple ensuite de faire une copie des membres d’une relation A vers une B.
1/ Mettre à niveau les lignes qui ne bougeront pas (par exemple : Lianes 2 ou 9, etc)
2/ Mettre à niveau les lignes sur lesquels le numéro change (ex : Ligne 25 qui deviendra la 75)
Le jour du changement que fait-on des anciennes relations VS les nouvelles
Créons nous des nouvelles relations pour des simples changements de numéros ?
Pour les lignes prolongées (Lianes 31, 35, 39), créons-nous de nouvelles relations ou partons-nous de la relation actuelle ?
En tout cas je suis partant pour le grand ménage de printemps
Je viens de comparer rapidement deux sources pour les arrêts dans l’opendata.
Le GTFS comporte plus de lignes (~5000 versus ~4500) avec environ 3300 lignes en commun.
Il serait bien d’avoir une explication sur comment sont générés ces fichiers ?
Je n’ai trouvé qu’environ 1200 arrêts dans OSM avec « ref:FR:TBM » et le rapprochement spatial ne trouve pas la bonne référence dans une cinquantaine de cas.
Des employés de mapbox font actuellement des mises à jour et souvent décomposent les ronds-points ce qui peut entrainer des discontinuités dans la route. Cela se produit aussi lorsqu’ils mettent à jour le filaire d’une rue suite à un passage à deux voies par exemple.
Je ne sais pas comment est généré le GTFS, je pense qu’il vaut mieux utiliser les jeux de données directement issus du SAEIV.
Je n’ai fait que Bordeaux, Pessac et Talence (qu’il faudrait peut-être revérifier, c’est la première commune que j’ai faite). Ça prend beaucoup de temps.
Effectivement cela va causer quelques soucis et il faudra regarder assez régulièrement les outils QA (Osmose)
@Marc l’analyse que tu as faite est sur toute la commune de Talence ou s’agit-il d’une extraction de quelques cas rencontrés
Mise à part la page wiki (https://wiki.openstreetmap.org/wiki/Bordeaux/Transports_en_commun) comment pourrait-on coordonner nos efforts de mise à jour ?
Comptez vous participer à la MAJ du réseau (en tout cas à sa préparation) ?
Il serait intéressant de parler du « suivi » des arrêts de bus, comme l’analyse de @Marc le prouve
Personnellement, j’ai commencé à mettre à jour les tracés que j’ai rectifié (Lianes 1+) : retrait du tronçon Mérignac Centre <> Mérignac Aéroport
Les arrêts SIG_KEOLIS n’existent pas, il faudrait retirer ceux présents dans OSM, je n’ai pas fait attention au début et j’ai mis leur ID quand ils existaient, la suppression pourra se faire plus tard. Il est possible qu’il y ait des arrêts manquants. De plus, comme l’ID contient le nom de l’arrêt, je pense qu’il change si l’arrêt change de nom, cela peut permettre de nous signaler la maj d’un arrêt s’il n’est plus présent sur le jeu de données.
Sur Talence, j’ai placé tous les arrêts sur les abribus à la main (il se peut que certains aient changé de place depuis ou se soient rajoutés).
Lorsque le bus s’arrête un peu loin de l’abribus, il se peut qu’il y ait un décalage entre le jeu de données et l’emplacement exact de l’abribus.
Par exemple à Peixotto : les bus sont à l’arrêt, les abribus sont sous les arbres, on aperçoit le deuxième :
La démarche « opendata » de Bordeaux Métropole me semble être de l’affichage politique.
Diffuser des données en format propriétaire sans meta-données ou rien, c’est presque la même chose : cela a juste un coût.
C’est la 1, je crois qu’ils ont abandonné l’appellation « + » pour certaines lianes (c’était pour indiquer qu’elles avaient un niveau de service plus élevé, priorité aux feux et couloirs dédiés).
Je trouve que c’est assez simple de travailler avec ces jeux de données mais je n’ai jamais utilisé de gtfs. Il y a un dictionnaire qui explique chaque jeu de données et les relations possibles avec les autres jeux, c’est vrai que certaines clés manquent de précision dans le dictionnaire.
Je trouve que tracé des lignes sur sv_chem_l est de bonne qualité, pareil pour les arrêts, on peut même distinguer les changement de voies sur les routes larges. Par contre je n’ai en effet pas trouvé de jeu indiquant les arrêts empruntés par une ligne (j’utilise directement les infos sur le site), on doit pouvoir le faire avec sv_tronc_l en liant les tronçons au chemin mais c’est compliqué a mettre en place pour une info qu’on peut avoir autrement.
