[EPIC] Registre d'arrêts national (NSR)

thbar commented 5 months ago

Pour différentes motivations:

travail sur le registre d'arrêts national avec @cyrilmorin
remontées terrain concernant les publications de données des producteurs (uniformisation / gouvernance / gestion des identifiants des arrêts), notamment avec @Brewennn
remontées terrain des réutilisateurs (= comment relier le dynamique au statique, comment s'y retrouver de façon générale) et de moi-même en tant que consommateur de la donnée (#4026 etc)

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.

Brewennn commented 5 months ago

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.

thbar commented 4 months ago

Différents retours de personnes, ou cogitations de ma part :

Retour de plusieurs parties (dont RATP Dev récemment) : se pose le cas (bien sûr) de systèmes non natifs NeTEx directement (exploitants, souvent), ou avec des restrictions de taille maximum sur les identifiants. Ce point a été évoqué par Entur (Norvège), on le retrouve d'ailleurs dans la doc ici https://github.com/entur/tiamat?tab=readme-ov-file#background

During the implementation of Tiamat was desirable to produce NeTEx IDs for stop places more or less gap less. The reason for this implementation was legacy systems with restrictions of maximum number of digits.

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).

Définition de la notion de scope d'unicité : surface ou "périmètre" (de façon plus généralisée, administratif ou autre) sur laquelle les identifiants sont garantis (ou réputés) uniques.

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:

si il y a de multiples exploitants sur une zone de gestion (ce qui peut arriver avec les IRVE), l'entité qui gère la totalité de la zone peut être amenée à imposer un préfixe ou un autre système permettant de désambiguier les identifiants (ainsi l'exploitant A peut appeler ses arrêts de façon indépendante, sans risque de collision avec l'exploitant B, qui fait pareil etc), on élargit un peu
si on passe en régional, la question de l'unicité individuelle des arrêts devient centrale, et elle peut-être gérée ou bien au niveau régional, ou bien via des guidelines imposées au niveau exploitant (voir avec NAM pour lister les cas)
quand on passe au national, cette question de l'identification "globalement" (au niveau France) unique devient stratégique, autant pour permettre des calculs d'itinéraires inter-régionaux, que même pour permettre à des développeurs (voir @laem avec https://cartes.app) d'éviter de découvrir des bugs en production suite à des collisions d'identifiants entre deux jeux de données
enfin, quand on passe au niveau européen, comme évoqué avec @Brewennn (avec qui j'ai vu la Suisse) ou @cyrilmorin (avec qui j'ai vu une personne en charge d'un land allemand sur ces aspects), la question de l'itinéraire transfrontalier

thbar commented 4 months ago

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 https://github.com/laem/gtfs/commit/fb36cfcdcbe33b8f58782860ab5c657fdc4898ff), chose qui n'aurait pas été nécessaire avec des identifiants globalement uniques.

thbar commented 4 months ago

Echange fructueux avec @mveissier ce matin, je partage certains points ici:

Ce document Règles de conversion « CNIG-NeTEx » mentionne les concepts (quays etc) et le lien / différences entre NeTEx et le standard CNIG accessibilité
On est d'accord sur le fait de se rapprocher du terrain de différentes façons
J'ai partagé les éléments du PAN Norvégien suivants:
- le profil Norvégien https://enturas.atlassian.net/wiki/spaces/PUBLIC/pages/728891481/Nordic+NeTEx+Profile définit les concepts clés (StopPlace, Quay etc)
- le NSR (National Stop Registry) travaille si je comprends bien sur un sous-ensemble de ces concepts clés, à savoir (voir API): topographic places, tariff zones, stop places, quays, parkings, fare zones, et "groupes"
- j'ai la sensation que commencer par "quays" et "stop places" est raisonnable à notre échelle (je comparerai ce modèle général à ceux de la Suisse et de l'Allemagne), cela montre par contre qu'une table simple ne suffira pas
plusieurs éléments clés terrain où il sera utile d'aller collecter les besoins
- https://www.societedesgrandsprojets.fr/services-express-regionaux-metropolitains-grand-est le SERM de Mulhouse - Bâle & de Strasbourg
- https://www.gart.org/actualite/le-calendrier-et-la-methode-pour-permettre-aux-collectivites-dobtenir-le-statut-de-serm/ l'explication de ce qu'est un SERM
- https://www.vie-publique.fr/loi/290687-loi-serm-rer-services-express-regionaux-metropolitains#:~:text=Une%20définition%20des%20SERM%2C%20un%20billet%20unique,-Afin%20de%20leur&text=Cette%20offre%20multimodale%20de%20services,renforcement%20de%20la%20desserte%20ferroviaire principe du billet unique pour chaque SERM

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.

thbar commented 4 months ago

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).

thbar commented 3 months ago

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)

"Démontrer des réussites tangibles pour justifier l'impact de l'équipe"
"Mettre un accent particulier sur un territoire spécifique, où les données tarifaires et les arrêts ouverts seront réutilisés dans des applications de mobilité"

J'ai vu hier @mveissier et Mathieu Capou (Nextendis) où ce deuxième point en particulier a été abordé.

thbar commented 2 months ago

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 :

Les différents PAN
Des industriels travaillant à différents niveau (local ou agrégation) comme RATP Dev, Okina / Lumiplan
L’équipe du Titre Unique (Mélanie Veissier et son AMOA)
Carole Lecomte (DREAL Normandie) dans le cadre du déploiement des données d’accessibilité (je vais y revenir)
Muriel Larrouy (DMA)
et d’autres (…)

Ces rencontres font que je fais les préconisations suivantes.

Changement de périmètre long terme

Les 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:

StopPlaces et Quays (au sens Transmodel / NeTEx). Dans les données, on peut voir une association 1 <- -> 1 assez souvent, mais il est impératif d’avoir les deux concepts avec une relation 1 <- -> N pour ne pas être coincé sur le terrain
Données d’accessibilité
Tarifs

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 tarifaires

Le 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:

créer une base nationale (mais pour ça il faut identifier la donnée)
ou une piste temporaire que je propose aussi : labelliser / estampiller, de façon spécifique, avec un cahier des charges précis, des jeux de données qui sont “compatibles” avec une réutilisation globale

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:

le respect de la norme NeTEx (comme stipulé dans les annexes du Titre Unique) - multiplier les formats sera problématique pour les réutilisateurs
la vérification de certaines caractéristiques (structuration des données, format des identifiants, stabilité des identifiants)
présence de certaines données en quantité et en qualité (tarifs, accessibilité, stop places / quays)
accord clair sur la labellisation entre les parties prenantes (pour avoir une durabilité de cette qualité)

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

Point avec @cyrilmorin et @brewennn demain pour exposer ceci dans le détail
Idem avec équipe plus large du PAN (intrapreneur / coach / personnes intéressées à contribuer) la semaine prochaine
Organisation rencontre PAN <- -> DMA <- -> Titre Unique pour travailler à une organisation commune
Suite des participations aux réunions sur l’accessibilité (DMA) et rencontre d’autres acteurs (ex: Citiway demain), pour faire passer cette idée
Cartographie plus précise des territoires où l’on veut zoomer (territoires conjoints à Tarifs + Access ?)
Analyse des données côté PAN (format des identifiants sur les territoires ? Structure de la donnée ? NeTEx ?) avec du code associé
Construction d’un cahier des charges pour une labellisation et/ou une agrégation
Organisation de rencontres plus larges avec autant DMA/TU/PAN que régions/industriels
Comm associée

Positionnement FinDPE

Le comité souligne l'importance du titre unique dans les recommandations faites par le CNR, mais la nécessité de création d'une base de données unique doit être validée par des réutilisateurs potentiels. Une approche plus tournée vers les cas d’usages pour atteindre des réutilisations concrètes et utile est demandée, avec dans 6 mois des réussites concrètes qui justifient l'impact de l'équipe. Un focus pourra ainsi être fait sur un territoire donné, où les données tarifaires/arrêt ouvertes seront réutilisées dans les applications de mobilités, par exemple Google Maps, citymapper, mais aussi les applications des AOM.

Lexique

FSNM : Fournisseur de Services Numériques Multimodaux
GS : Gestionnaire Service

Extraits de bibliographie TU

Exigences CCTP billetique

Exigences CCTP billettique - projet TU v1.1 (Mélanie Veissier, 20/06/2024)

Les éléments proposés permettent donc de préciser :

Les exigences de publication du référentiel tarifaire accessible avec la plateforme nationale d’interopérabilité (pour la mise en conformité avec l’article 25 de la LOM) et des préconisations d’organisation pour la généralisation de ce référentiel

Ref Article 25 - LOI n° 2019-1428 du 24 décembre 2019 d'orientation des mobilités (1) - Légifrance

Puis:

Exigences applicables aux GS partenaires : publier sa gamme tarifaire locale sur le Point d’Accès National (…) format NeTEx (…) "tarifs de base communs standard (tous modes en lignes régulières): — données tarifaires du réseau (zones tarifaires et arrêts, niveaux tarifaires), — structures tarifaires standard (point à point, y compris tarifs journaliers et hebdomadaires, tarifs zonaux, tarifs forfaitaires"

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

AOM concédante	Syndicat des Mobilités de Touraine	Caen la Mer	Le Mans Métropole	Région Centre - Val de Loire	Région Normandie	Région Pays de la Loire
Type de mobilité	TC urbain et périurbain	TC urbain et périurbain	TC urbain et périurbain	TC ferré régional	TC ferré régional	TC ferré régional

Service de mobilité	Transport Public	Transport Public	Transport Public	Transport Public	Transport Public	Transport Public
Nom commercial	Fil Bleu	Twisto	Setram	Rémi	Nomad	Aléop
Région	Centre-Val de Loire	Normandie	Pays de la Loire	Centre - Val de Loire	Normandie	Pays de la Loire
Département	37 - Indre-et-Loire	14 - Calvados	72 - Sarthe	sans objet	sans objet	sans objet
Commune principale	Tours	Caen	Le Mans	sans objet	sans objet	sans objet
Exploitant	Keolis Tours	Keolis Caen	setram (SEM)	SNCF Voyageurs	SNCF Voyageurs	SNCF Voyageurs
Type de contrat	DSP	DSP	DSP	Convention exploitation	Convention exploitation	Convention exploitation
Nature des recettes	forfait de charge avec intéressement à la recette supplémentaire aux objectifs de recette	à préciser	régie	à préciser	à préciser	à préciser
Date échéance	12/25	12/24	12/25

Système billettique	Kuba	Kuba	Kuba	SNCF Voyageur	SNCF Voyageur	SNCF Voyageur
date de renouvellement	2028	non planifié	2026	non planifié	non planifié	2027
Gamme tarifaire	1 voyage : 1,60 €  2 voyages : 3 €  10 voyages : 14 € 24 heures : 4,10 € 48 heures : 6,20 € 1 h Famille : 2,60 € Calèche : 1,60 € événement : 1,90 € (journée)	1 heure : 1,60€ 5 tickets : 7€ 10 tickets : 14€ 24 heures : 4€ 48 heures : 7€ 72 heures : 9€ Ticket Famille : 6,40€ (yc P+R)	1 voyage : 1,50€ 2 voyages : 2,90€ 10 voyages : 13,50€ 24 heures : 4,20€ Le Mans City Pass (72h) : 10€	cf onglet Matrice OD TER	cf onglet Matrice OD TER	cf onglet Matrice OD TER
Fournisseur m-ticket	Airweb	Airweb	Airweb	SNCF Voyageur	SNCF Voyageur	SNCF Voyageur
Geste actuel validation mticket	Affichette CB2D propriétaire	Affichette CB2D propriétaire	Affichette CB2D propriétaire	Sans validation	Sans validation	Sans validation

Positionnement	Lot 1	Lot 1	Lot 1	Lot 1	Lot 1	Lot 1
Restriction modale/géo en MVP	sans restriction	sans restriction	sans restriction	Ligne Caen/Le Mans/Tours (20 gares  dont 6 en Centre VdL)	Ligne Caen/Le Mans/Tours (20 gares  dont 6 en Normadie)	Ligne Caen/Le Mans/Tours (20 gares  dont 8 en Pays de Loire)
Titres à facturer dans l'offre de mobilité post-payée TU	1 voyage : 1,60 €  24 heures : 4,10 €	1 heure : 1,60€ 24 heures : 4€ Mensuel : 44€	1 voyage : 1,35 €  24 heures : 4,20 € Mensuel : 39,80€	cf onglet Matrice OD TER	cf onglet Matrice OD TER	cf onglet Matrice OD TER
Geste de validation pour l'offre de mobilité post-payée TU	Autodéclaration	Autodéclaration	Autodéclaration	Autodéclaration	Autodéclaration	Autodéclaration
Titres prépayés	1 voyage : 1,60 €  10 voyages : 14 € 24 heures : 4,10 €	1 heure : 1,60€ 10 tickets : 14€ 24 heures : 4€ Famille : 6,40€	1 voyage : 1,50 €  10 voyages : 13,50 € 24 heures : 4,20 €	cf onglet Matrice OD TER	cf onglet Matrice OD TER	cf onglet Matrice OD TER
Geste de validation titres prépayés	Scan affichette normalisée	Autodéclaration	Scan affichette normalisée	Autodéclaration	Autodéclaration	Autodéclaration
Solution de contrôle	Application mobile de contrôle TU fournie par le Titulaire (cf. CCTP § 03.3.01)	Mise à jour de l'application locale	Application mobile de contrôle TU fournie par le Titulaire (cf. CCTP § 03.3.01)	non déterminé	non déterminé	non déterminé
Source des données statiques	https://data.tours-metropole.fr/api/v2/catalog/datasets/horaires-temps-reel-gtfsrt-reseau-filbleu-tmvl/alternative_exports/filbleu_gtfszip	https://www.data.gouv.fr/fr/datasets/r/23fbc741-5751-425d-8275-2b96c7c21ab2	https://www.data.gouv.fr/fr/datasets/r/5339d96c-6d20-4a01-939a-40f7b56d6cc1	https://eu.ftp.opendatasoft.com/sncf/horaires/export-ter-netex-last.zip	https://eu.ftp.opendatasoft.com/sncf/horaires/export-ter-netex-last.zip	https://eu.ftp.opendatasoft.com/sncf/horaires/export-ter-netex-last.zip
Format des données statiques	GTFS	GTFS	GTFS	NeTEx TC	NeTEx TC	NeTEx TC
Source des données dynamiques	https://data.filbleu.fr/ws-tr/gtfs-rt/opendata/service-alerts	https://api.okina.fr/gateway/cae/realtime/anshar/ws/services	https://proxy.transport.data.gouv.fr/resource/setram-lemans-gtfs-rt-trip-update	https://proxy.transport.data.gouv.fr/resource/sncf-siri-lite-situation-exchange	https://proxy.transport.data.gouv.fr/resource/sncf-siri-lite-situation-exchange	https://proxy.transport.data.gouv.fr/resource/sncf-siri-lite-situation-exchange
Format des données dynamiques	GTFS-RT	SIRI	GTFS-RT	SIRI	SIRI	SIRI
Source des données tarifaires	Non disponible	Non disponible	Non disponible	Non disponible	~https://api.atm.cityway.fr/dataflow/gamme-tarifaire/download?dataProfil=OPENDATA~	Non disponible
Format des données tarifaires	sans objet	sans objet	sans objet	sans objet	Tarif CSV/Xml	sans objet

AntoineAugusti commented 2 months ago

@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é.

thbar commented 2 months ago

@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:

l'accessibilité est généralement jusque là peu fournie quand on regarde de plus près (les champs sont là dans le fichier que tu as pointé, mais peu ou pas valués) ; on discutera ce point avec @Brewennn vendredi (on assiste à une réunion sur les données d'accessibilité sur justement la zone Normandie, portée par Carole Lecomte de la DREAL Normandie)
il faut vérifier le côté gouvernance (qui semble acquis dans le cas du fichier que tu as pointé), la mise à jour régulière nécessaire (sinon ça tombe à l'eau) etc

thbar commented 2 months ago

(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 commented 2 months ago

Une présentation qui récapitule ce que je propose:

éléments techniques livrables à court terme
approche générale

a été faite hier à la majorité de l'équipe.

prhod commented 2 months ago

@thbar je reprends ici les éléments évoqués par mail.

IDFM utilise un système de "regroupement" des points d'arrêts des opérateurs sur des points d'arrêts "IDFM"
Ce type d'approche permet d'avoir une autorité sur le sujet et une garantie sur la qualité, mais :
- nécessite une gouvernance claire et une gestion des modifications de la base de manière bidirectionnelle (remontée opérateur -> administration de la base, et administration de a base -> opérateurs)
- implique des échanges de données plus compliqués. Le profil Netex FR demande déjà une hiérarchie d'arrêt à 4 niveaux, cette gestion en ajoute un 5ème

thbar commented 2 months ago

Merci @prhod ! Tu avais évoqué aussi un lien entre identifiant "haut niveau" et identifiant "legacy", si j'ai bien compris ?

prhod commented 2 months ago

@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 :)

thbar commented 2 months ago

@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 !

thbar commented 2 months ago

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:

@mveissier qu'on voit demain (équipe Titre Unique)
Muriel Larrouy (Direction Ministérielle à l'Accessibilité) vu le lien (autant sur la dynamique générale que sur l'intérêt d'avoir une partie de la donnée d'accessibilité directement dans le registre) entre l'accessibilité et ce que je propose
puis (à discuter avec @maxime-siret) à une partie du GT7, notamment les acteurs qui font actuellement de l'implémentation de registres (= initiatives assez "périmètrées") ou de référentiels (= projets plus larges au niveau donnée, mais avec évidemment des points de connection vers des registres)

EDIT: correction de typos / mots incorrects

thbar commented 2 months ago

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:

En précisant peut être que le CNIG reste ouvert à la possibilité qu'on monte un GT "tamponné" en son sein pour ce sujet. Pour info, on avait eu le CR ci-dessous associé :

Le sujet d'un référentiel des arrêts partagés répond à une forte demande des producteurs et réutilisateurs de données de transport. Un même arrêt pouvant être desservi par plusieurs opérateurs de transport, cela implique qu'il peut être référencé dans plusieurs bases de données. Les arrêts possèdent donc des caractérisations, définitions et attributs différents en fonction de l'entité qui les opèrent. L'équipe du Point d'Accès National a mené un travail d'investigation auprès de différentes Autorité Organisatrice de la Mobilité, Opérateurs de Transport et d'Information Voyageur afin de comprendre comment les données d'arrêts étaient partagées et réutilisées. Ce benchmark a montré que des difficultés existaient à utiliser ces données issues de différentes sources car elles étaient livrées avec différentes identifications en fonction de l'opérateur. Cette problématique avait été préalablement identifiée par le Ministère des Transports en 2012, un groupe de travail avait été créé et avait abouti sur un modèle de données pour les transports en commun. Ce modèle s'appuyait sur des normes existantes au niveau européen et avait été détaillé dans un profil d'échange normé Netex. Cependant, l'enjeu reste d'actualité pour plusieurs raisons : l'ensemble des acteurs de l'écosystème n'ont pas adopté le modèle proposé d'une part, et d'autre part de nouveaux services de mobilité se sont développés et une mise à jour du modèle pourrait être envisagée. Ainsi, la quantité des données fournie par des entités différentes qui ont chacune un modèle différent pose des problèmes d'interopérabilité, notamment pour le partage entre les acteurs (AOM entre elles, AOM et OT) mais également pour la réutilisations par les opérateurs de SIM. La question majeure soulevée aujourd'hui est celle de la gouvernance territoriale afin d'assurer une gestion cohérente et coordonnée des différentes bases de données d'arrêts partagés au niveau des AOM et AOT. Plusieurs étapes sont envisagées :

Une première réunion de concertation avec les AOM afin de définir au mieux leur besoin en termes d'harmonisation et de gouvernance ;

Puis dans un second temps, des réunions de travail selon les modalités préalablement définies à une plus grande échelle.

thbar commented 1 month ago

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.

Je publie le texte de ma proposition (qui doit être remaniée) ici https://gist.github.com/thbar/78e3ea32c4d2d998c0ec7cd7c07f9d4b
Elle devra être retouchée: 2.1 Le montant du FinDPE est incorrect 2.2 Phrase à revoir qui devient "Ceci n'est pas ENCORE le registre d'arrêts" 2.3 Une slide à ajouter à mon retour de congés -> concepts clés (StopPlaces / Quays avec hiérarchisation, Accessibilité, puis explication de l'articulation entre les Tarifs et le registre) 2.4 Ajout de la vision cible sur une slide (idem)
On a défini plusieurs étapes (avec Brewenn et Frédéric) à suivre dans le trimestre T4 2024, à savoir: 3.1 rafraîchissement de la présentation PDF, en ajoutant la vision cible, et une slide importante sur le contenu précis du registre (notes plus haut) 3.2 rencontres techs avec des industriels pour vérifier qu'on n'a pas trop d'angle mort dans la réflexion 3.3 implémentation d'une consolidation "brute" (titre adapté avec Jorge "Ceci n'est pas encore un registre d'arrêts"), fichier CSV avec tous arrêts de tous les NeTEx et GTFS dont on dispose

thbar commented 1 month ago

Point fait ce jour avec @Brewennn @AurelienC @ptitfred pour affiner une présentation "brandée PAN" et aller la partager avec des acteurs techniques.

etalab / transport-site