[EPIC] Registre d'arrêts national (NSR) #4034
Comments
AntoineAugusti
added
the
epic
|
Retour Suisse : organisation très centralisée car c'est Office Fédéral des Transports (OFT) qui établit les horaires pour le JDD, agrège les JDD des collectivités et gère le registre d'arrêts. lorsqu'une commune ou un service librement organisé souhaitant ajouter un arrêt, ils doivent en faire la demande à l'OFT qui valide ou refuse (https://www.tp-info.ch/fr/gestion-des-donnees/point-darrets-et-points-dexploitation/arrets, https://atlas.app.sbb.ch/service-point-directory). C'est ce dernier qui attribue l'ID de l'arrêt. Cela peut poser problème pour certains opérateurs comme Flixbus qui ne publie que selon leurs ID. La question se pose également pour les trajets transfrontaliers : quels ID choisir. |
|
Différents retours de personnes, ou cogitations de ma part :
Cet aspect sera important à traiter (peut-être via des systèmes de mappings, ou l'intégration de "clés legacy" comme je crois que c'est fait en Norvège) pour que dans les faits, on arrive à consolider, sans créer des coûts "court terme" trop important (ex: "rétrofitter" une capacité à avoir des identifiants plus longs sur un système qui ne le supporte pas, plutôt que permettre d'attendre le renouvellement du système sur un temps plus long).
Quand on travaille à l'échelle d'un exploitant, ce scope d'unicité est la zone couverte, et l'unicité est souvent implicite (car un peu plus simple à atteindre ; sans elle les systèmes même internes ne fonctionnent pas convenablement). Quand on élargit le périmètre, les choses changent:
|
|
Et retour concret de @laem en terme d'impact ; il a du "préfixer à la main" une fois un bug constaté de vive lutte en production (voir cartesapp/serveur@fb36cfc), chose qui n'aurait pas été nécessaire avec des identifiants globalement uniques. |
|
Echange fructueux avec @mveissier ce matin, je partage certains points ici:
La suite: je vais aller regarder côté allemand et suisse (les registres seront je pense probablement moins "large" en terme d'entités, mais à vérifier), et voir comment c'est architecturé. Important car existence de transfrontalier. |
|
J'ai contacté l'Allemagne et la Suisse pour savoir quels concepts / entités / attributs ont été retenus formellement dans leurs registres respectifs. On arrivera ainsi à avoir un panorama suffisant pour y voir clair en terme d'état de l'art (la Norvège étant la plus avancée probablement en nombre de concepts traités, l'Allemagne étant plus large, et l'Allemagne et la Suisse étant en lien avec le transfrontalier ce qui nous amène directement sur des sujets à traiter). |
|
Note importante extraite du procès verbal de la DINUM (le premier point est évident et habituel sur beta gouv en général, le deuxième est précis en terme d'attente et m'intéresse tout particulièrement)
J'ai vu hier @mveissier et Mathieu Capou (Nextendis) où ce deuxième point en particulier a été abordé. |
thbar
changed the title
|
Je publie ici une synthèse intermédiaire, avant de reboucler avec @cyrilmorin et @Brewennn, puis plus largement l’équipe du PAN, car le projet registre d’arrêts est priorisé de façon plus forte à présent (et j’y vois aussi un peu plus clair, cf notes plus bas). En résumé, j’ai échangé avec différentes entités / personnes sur les derniers mois & semaines, dont par exemple :
Ces rencontres font que je fais les préconisations suivantes. Changement de périmètre long termeLes premières étapes faisaient l’hypothèse d’un registre très resserré (lat/lon/id). Si cela serait plus directement “facile à produire” et semble rassurant de prime abord, en pratique côté réutilisateurs, il aurait peu d’intérêt (et le FinDPE voir plus bas insiste sur cette utilisabilité). Après avoir échangé avec différents interlocuteurs (voir plus haut), je pense que les concepts minimaux (qui n’ont pas besoin d’être intégrés obligatoirement d’un coup, mais qu’on doit intégrer dans la vision du design dès à présent pour avoir une ligne claire sur la durée) sont:
Concernant les deux derniers points, je propose (équipe du PAN / écosystème / industriels) de se former sur ce qu’est un fichier NeTEx accessibilité et/ou tarifs, et partager cette vision, et comprendre si ces données nécessitent, par rebond, d’autres données à intégrer également. Identifiants globalement uniques, stables + importance des mappings avec les identifiants “legacy”Comme cela est prévu dans Transmodel/NeTEx/SIRI, il faut évidemment recommander des identifiants globalement uniques, stables dans le temps (y compris aux changements de marchés publics), qui permette de travailler à une échelle globale, mais aussi traiter le point suivant: importance des mappings avec les identifiant “legacy”. Un point revenu fréquemment est que à l’échelon exploitant, les systèmes legacy peuvent être en difficulté technique (raisons historiques non faciles à modifier) d’intégrer des identifiants globalement uniques, impératifs dès qu’on s’éloigne de l’échelon local (que ça soit pour agréger la donnée, ou même pour la réutiliser - la collision entre deux identifiants d’arrêts éloignés de plusieurs centaines de kilomètres est très dommageable). Je propose d’accepter cette réalité terrain et d’intégrer la notion de “clé legacy” en attribut secondaire, chose qui a été faite en Norvège si je comprends bien aussi. Cela permettra de traiter correctement les besoins des exploitants locaux, tout autant que ceux des agrégateurs. “Synergie” entre PAN, Titre Unique, et déploiement de l’accessibilitéPour que l’ouverture de données fonctionne, je propose d’organiser des rencontres communes entre l’équipe Titre Unique, la DMA, et le PAN dans un premier temps, puis de faire de même avec des interlocuteurs non pas uniquement au niveau région en tant que tel, mais aussi au niveau industriels (ex Okina) ou étatique (DRIEAL Normandie). Il me semblerait astucieux de chercher à mutualiser les territoires pilotes du Titre Unique avec ceux du déploiement DMA / données d’accessibilité. Préconisations côté données tarifairesLe dossier Titre Unique évoque la construction éventuelle d’un outil pour produire la donnée tarifaire. C’est une piste similaire à celle mise en place sur Accèslibre Mobilités / DMA, qui aura son intérêt. Il ne faut toutefois pas mettre de côté un deuxième moyen, qui est la production en direct par des industriels (Okina a mentionné cette possibilité), sans passer par un outil, tant il est vrai que la donnée tarifaire est déjà présente dans les systèmes, et les étapes de transposition en NeTEx Tarifs et de publications pourraient être faites de façon centralisée. “Labellisation de jeux” versus “agrégation par le PAN”Au final, on identifie évidemment que le “besoin” utilisateur est de pouvoir avoir de la donnée de qualité, avec tous les attributs nécessaires, et de façon normalisée. Cela sur les arrêts, les tarifs, et l’accessibilité. Il existe par contre plusieurs stratégies pour y aller:
L’approche numéro 2 me paraît intéressant pour commencer car de toute façon, pour créer une base nationale, il y a le fameux “garbage in, garbage out” qui est mentionné par toutes les personnes faisant du calcul d’itinéraire. Il faut de la donnée de qualité, avant de la consolider (sinon la consolidation est de piètre qualité). Je préconise donc de travailler déjà à identifier, voire, à labelliser formellement (façon “AOP”), des jeux produits sur le PAN, jeux qui seraient mis en avant, mais surtout dont on vérifierait l’adéquation au besoin. Un tel cahier des charges pourrait inclure:
Ces éléments permettront de faciliter derrière la création d’un agrégat national, comme le fait la Norvège, voire, toujours comme le fait la Norvège, d’également proposer des sorties formats GTFS en aval, pour satisfaire les différentes exigences. Le PAN pourrait aussi proposer une intégration fine sur le site, avec un label visuel, des liens vers les profils de normes / documentation / quickstarts sur les normes etc. Le “contenu du registre” serait donc à terme, dans cette hypothèse, un agrégat constitué des jeux labellisés (cette approche permettant de mettre à disposition des jeux plus tôt pour les réutilisateurs, sans attendre une étape “consolidation” qui prendra du temps à réaliser). Prochaines étapes proposées
Positionnement FinDPE
Lexique
Extraits de bibliographie TUExigences CCTP billetique
Ref Article 25 - LOI n° 2019-1428 du 24 décembre 2019 d'orientation des mobilités (1) - Légifrance Puis:
Annex 06 CCTP référentiel des territoires“Annexe 06.1 CCTP-référentiel des territoires_DGITM-SDMINT-02-2024” (non dispo en ligne ?) Copie à l’instant t, ce tableau ne fait pas référence officielle
|
|
@thbar As-tu pu regarder le JDD des lieux de mobilité en Normandie ? C'est ce qui s'apparente le plus à un registre d'arrêts pour une région. On a des identifiants, des autorités, des attributs d'accessibilité. |
|
@AntoineAugusti merci pour le lien. Le "zoom" dans certains jeux plus précis est prévu pour les semaines à venir (on en a parlé avec @vdegove au point dév par exemple, il y aurait des besoins en analyse / outils / code, il faudra prioriser ces travaux au niveau équipe). Vu la masse, il était préférable d'éviter de se noyer dans le nombre de jeux jusque là car ça représente vite pas mal de travail supplémentaire. Ce jeu peut être intéressant au même titre que d'autres agrégats régionaux (encore + du fait que Caen la Mer est dedans, et que c'est un territoire pilote pour le TU), avec les points d'attention suivants toutefois:
|
|
(en tout cas ça fait partie des datasets sur lesquels on pourrait tester une forme de labellisation, lister des critères et voir si ils sont bien vérifiés - format des identifiants, lien avec les identifiants legacy qui semblent être là, qualité de l'accessibilité, gouvernance etc, donc c'est un bon élément à garder dans notre liste) |
thbar
changed the title
|
Une présentation qui récapitule ce que je propose:
a été faite hier à la majorité de l'équipe. |
|
@thbar je reprends ici les éléments évoqués par mail.
|
|
Merci @prhod ! Tu avais évoqué aussi un lien entre identifiant "haut niveau" et identifiant "legacy", si j'ai bien compris ? |
|
@thbar oui, mais c'est la même chose (identifiant opérateur = légacy, identifiant IDFM = haut niveau). Je me suis dit que c'était plus explicite en le reformulant :) |
Ok, je m'en doutais un peu, mais phrasé comme tu l'as remis là c'est plus aligné avec d'autres échanges que j'ai eu. Merci pour la clarification ! |
|
La semaine dernière, j'ai présenté mes conclusions actuelles concernant la mise en place d'un registre d'arrêts national en France, et une proposition de roadmap pour la suite à une bonne partie de l'équipe du PAN. Comme vu avec @maxime-siret (nouvel "intrapreneur" qui gère le PAN depuis début septembre), je partage mes slides ici avec quelques ajustements pour diffusion publique. initiative-registre-d-arrets-pan.pdf C'est à considérer comme un "work in progress", mais avec des éléments tangibles tant au niveau production, que gouvernance / comm. Je vais relayer cette proposition pour avoir leurs retours notamment auprès de:
EDIT: correction de typos / mots incorrects |
|
Document "prior art" communiqué par @mveissier hier (merci !) sur des investigations réalisées (en 2022 si j'ai compris) sur ce dossier, présentation PAN qui ne me dit rien à première vue: Arretspartages-CNIG_v2.pdf (présentation donnée au GT CNIG en 2022) À la relecture, je m'aperçois que le modèle que je propose réponds à différents points traités dans ces slides (notamment la question des correspondances d'identifiants, et la territorialisation), et partage mon analyse sur le fait de s'appuyer sur les acteurs terrain. Par ailleurs je cite Mélanie aussi:
|
|
Tant que j'étais occupé à gérer la dernière panne (#4262), je partage avec @Brewennn (qui va avancer dessus pendant que je suis en congés) différents éléments.
|
|
Point fait ce jour avec @Brewennn @AurelienC @ptitfred pour affiner une présentation "brandée PAN" et aller la partager avec des acteurs techniques. |
Pour différentes motivations:
je crée ce ticket long-terme pour collecter les retours terrains "non reformulés", en se concentrant sur des éléments factuels et concrets. Je vais nourrir ce ticket petit à petit.
The text was updated successfully, but these errors were encountered: