Retours réutilisateurs sur le validateur GTFS

Miryad3108 commented 2 years ago

Instant System, Maël Le Bronnec

ID :

la présence de caractères spéciaux du type "/" qui posent ensuite problème dans les réutilisations, quand les IDs sont passés en paramètre d'URLs (c'est plutôt un WARNING de bonne pratique)

Il serait utile d'enrichir un peu les contrôles de type "INFO" qualitatif métier : même si le GTFS est exploitable, il y a plein de points qui peuvent le rendre de qualité médiocre :

pas de LONG NAME des routes
pas de couleur des routes
pas de shape des trips
des routes qui sont listées mais sans aucun stop-time donc ils ne circulent pas
pas de regroupements des stop-points en stop-areas
l'utilisation exclusive des calendar_dates au lieu du calendar qui alourdit les traitements etc ...

La limite de taille du validateur peut les handicaper : ils ont parfois rencontré des GTFS de 250mo Ils utilisent aussi celui (open source) de Mecatran, qui implémente d'autres controles que les notres https://gtfsvtor.mecatran.com/utw-test/web/pub/gtfsvtor

AntoineAugusti commented 2 years ago

Pr for ID with non-ASCII characters is here https://github.com/etalab/transport-validator/pull/119

AntoineAugusti commented 2 years ago

@etalab/transport-bizdev On peut avoir des infos supplémentaires sur l'importance d'avoir routes.txt route_long_name ? Le route_short_name apparait suffisant.

Miryad3108 commented 2 years ago

Demande faite auprès du réutilisateur. Je mettrai son retour ici.

Miryad3108 commented 2 years ago

@AntoineAugusti Retours du réutilisateur :

"ce point n'est pas bloquant pour nous, mais il est important pour la qualité du service : les utilisateurs doivent retrouver dans leurs médias les mêmes informations qu'ils voient sur le quai, sur le bus, sur les plans affichés, etc. Le LONG NAME diffère pas mal d'un réseau à l'autre : la façon de le construire, le choix du séparateur, etc : quand on essaye de le deviner à partir des terminus, le résultat diffère toujours du terrain. Donc nous n'essayons même pas, c'est au Transporteur de nommer ses lignes comme il le souhaite, en cohérence avec ses autres affichages. En PJ deux exemples concrets et bien différents. Vous noterez les lignes en gris, qui n'ont ni couleur, ni Long Name : bon courage aux utilisateurs ;)"

Screenshot_20220427-161507 Screenshot_20220427-161816

AntoineAugusti commented 2 years ago

@Miryad3108 Pourrais-tu donner le long route short name afin de bien comprendre la seule info disponible ? Juste "26" ou "30" pour le réseau Astuce de Rouen ?

AntoineAugusti commented 2 years ago

Depuis https://transport.data.gouv.fr/datasets/donnees-en-temps-reel-des-lignes-26-et-30-du-reseau-astuce-metropole-rouen-normandie/

routes.txt

route_id,agency_id,route_short_name,route_long_name,route_desc,route_type,route_url,route_color,route_text_color
26,760,26,26,,3,,,
30,760,30,30,,3,,,

Miryad3108 commented 2 years ago

Je demande confirmation mais ma compréhension c'est que

long name : tu as le numéro/lettre + les directions
short name : que le numéro/lettre de ligne

AntoineAugusti commented 2 years ago

@Miryad3108 Pour le cas des lignes 26 et 30 à Rouen, le GTFS https://github.com/etalab/transport-site/issues/2331#issuecomment-1111152211 a des valeurs de route_short_name et route_long_name présentes, mais les valeurs ne sont pas idéales.

Dans ce cas, je me demande si un processus automatisé (genre validateur) doit trouver quelque chose à dire.

Pourquoi le réutilisateur n'a pas posté de commentaire / pris contact avec le producteur pour demander une correction ?

Je me demande ce qui doit relever de règles de vérifications automatisées (surtout des choses arbitraires de styles) et d'un dialogue (si possible ouvert) avec les producteurs de données.

AntoineAugusti commented 2 years ago

cc @ChristinaLaumond qui a des connaissances côté SAE et intégration avec des calculateurs d'itinéraires.

ChristinaLaumond commented 2 years ago

hello, désolée je ne suis pas encore adepte de Github et je loupe donc la majorité des commentaires où on me taggue :D Globalement, j'ai l'impression que nous devons faire progresser les producteurs de données dans l'enrichissement commercial de leurs GTFS.

Pour cela, il faut qu'ils passent de la logique "un GTFS = de la donnée technique / de l'opendata / une obligation" à " un GTFS = une information voyageurs réutilisée donc un impact commercial, donc il faut que je l'enrichisse au maximum et que cela soit cohérent entre l'information voyageurs papier sur les fiches horaires et l'info voyageurs digitale"

Comme le précise Mael, le sujet est donc avant tout un sujet côté transporteur qui a le devoir de fournir une donnée la plus qualitative possible et qui représente le mieux leur info voyageurs sur le réseau. Ainsi, il n'y a pas réellement de règles sur le nom long et le nom court dans le GTFS par exemple. -> si je prends l'exemple du réseau de Quimperlé RATP DEV, je les avais sensibilisé sur le nom court et long mais leurs lignes interurbaines étaient tellement complexes (plusieurs destinations) qu'ils avaient préféré garder en nom long "Ligne 1" "Ligne 2" plutôt que "Ligne 1 - Mairie <-> Gare" par exemple. Cela dépend aussi de leur communication plus globale dans le réseau / leurs fiches horaires sur les poteaux d'arrêts, fiches horaires distribuées, plans etc.

De ce que j'ai pu voir pour le moment, j'ai l'impression :

Dans le cas où l'agglo a fait le choix de déployer une application multimodale comme Instant System, généralement les données GTFS seront de bonne qualité car l'opérateur travaille en lien resserré avec Instant System et donc le marketing est intégré à la boucle pour travailler sur les données digitales. Toutefois : il arrive que le GTFS qui soit fourni à Instant System soit pas celui qui arrive sur le PAN (faute de process) -> c'est donc aussi notre rôle de vérifier cela et d'accompagner en ce sens.
Quand ce n'est pas le cas, c'est là où généralement les données sont brutes et pas au niveau pour les réutilisateurs en masse type Transit, MyBus, BingMaps... -> c'est ici que c'est d'autant plus problématiques les réutilisateurs nous font part du manque de qualité. NB : Instant System / ou un autre fournisseur officiel d'une agglo peut également rencontrer ces soucis car l'agglo lui demande d'intégrer les données des réseaux voisins depuis l'opendata. Ils se retrouvent donc confronter aux mêmes problématiques de qualité de la donnée que les autres (ex : c'est surement le cas pour les lignes 26 à 30 du réseau Astuce, les interlocuteurs ne doivent pas être les mêmes que pour les lignes régulières du réseau de Rouen, ils n'ont donc pas pu enrichir les données et les ont laissé sans couleur et sans nom commercial)

Finalement, pour avancer sur ce sujet, je vois plusieurs pistes :

avancer sur le tableau global par AOM indiquant pour chaque GTFS s'il contient les couleurs, les tracés, les noms longs de ligne etc.
Sensibiliser les producteurs à l'enrichissement de leurs GTFS à travers des exemples concrets (mails spécifiques pour les producteurs où la qualité n'est pas jugée assez bonne, + flash qualité newsletter + via posts réseaux sociaux)
Organiser une séance de travail orientée producteurs ?
Je ne sais pas si l'ajouter au validateur aurait un intérêt mais il faudrait plutôt réfléchir à une sorte de notation de la qualité comme le suggérait @thbar Ex : un critère qualité ex : si tu as pas la couleurs, pas les tracés, pas les noms alors tu est en rouge. etc.
Autre solution possible : développer une sorte de "MOSAIC" dans le PAN (l'outil d'enrichissement des GTFS développé côté RATP DEV) pour justement traiter ces problématiques d'enrichissement commercial et avoir une donnée la plus précise et correcte possible. Gros gros chantier si on part la dessus ;)

C'est un peu long mais ca mérite probablement une discussion tous ensemble pour voir le plan d'actions ;)

AntoineAugusti commented 2 years ago

Je ferme, les demandes initiales ont été prises en compte / les tickets ont été ouverts sur le validateur.

etalab / transport-site

Retours réutilisateurs sur le validateur GTFS #2331