indicateur de fraîcheur pour JDD mis à jour quotiennement - IDFM

[Brewennn]

Bonjour,

L'indicateur de fraîcheur des données a plongé depuis la mi-février pour Ile-de-France alors que le JDD est mis à jour quotidiennement.

Une hypothèse serait que les ressources soient mises à jour après que nous publions l'indicateur ? Je vais me renseigner sur les modalités de mises à jour côté IDFM.

[maxime-siret]

Feedback direct d'IDFM par mail, pour info

[Brewennn]

Feedback direct d'IDFM par mail, pour info

Ce n'est pas arrivé dans le boîte 'contact' pour l’instant. Tu peux me mentionner stp ?

[maxime-siret]

Yes je t'ai renvoyé

[ptitfred]

Le calcul de fraîcheur s'appuie sur les dates de calendriers dans les fichiers calendar.txt et calendar_dates.txt. Il s'appuie sur les dates "minimales" et "maximales" extraites par le validateur. Le calcul lui-même est fait dans transport-site.

Si la plage de date est dans le futur, le score n'est pas calculé.

Si la plage de date est dans le passé, le score est de 0.

Sinon (le GTFS est présentement actif) le score est de 1.

Le score de fraîcheur d'un dataset est la moyenne des scores de fraîcheur des ressources (quand c'est pertinent).

La courbe présente un historique lissé par lissage exponentiel.

Le minimum est le 19 avril 2025 ce qui fait que jusqu'à récemment la ressource étant dans le futur le score de fraîcheur n'était pas calculé. Un score absent est affiché comme un score nul (c'est un choix).

Sauf erreur de ma part le score de fraîcheur devrait donc commencer à remonter.

[Brewennn]

Merci pour les précisions.

En regardant les GTFS du 15 avril par exemple, la plage débute avant le 15 et se finit bien après, le score aurait dû remonter.

Je pense que le problème vient de nous. En forçant la validation, l'affichage ne se met pas à jour :

et les métadonnées n'apparaissent pas dans l'API (https://transport.data.gouv.fr/api/datasets/6449c52caeceb71273a42dd3) :

[Brewennn]

Dans les détails du fichier GTFS, la plage horaire ne correspond pas avec ce qu'on trouve dans calendar.txt et calendar_dates.txt.

[ptitfred]

Il est possible que certains jobs d'arrière plan n'aient pas tourné, notamment après un refresh manuel. J'investigue pour te répondre.

Dans tous les cas c'est davantage un souci de transport-site que de transport-validator. Je suggère qu'on transfère l'issue dans l'autre repository.

[Brewennn]

oui effectivement on peut transférer.

[ptitfred]

La dernière validation enregistrée pour cette resource date du 15 janvier dernier

Validation effectuée en utilisant le fichier GTFS en vigueur le 15/01/2025 à 13h10 Europe/Paris avec le validateur GTFS du PAN.

(still digging)

[ptitfred]

ResourceHistory#240161 is a GTFS-Flex, we do not validate it

[ptitfred]

Donc dès qu'un GTFS contient un fchier booking_rules.txt ou locations.geojson, nous le taggons comme GTFS-Flex et ne le validons pas.

[ptitfred]

Voir #3058 (comment) et #3058

[ptitfred]

Donc dès qu'un GTFS contient un fchier booking_rules.txt ou locations.geojson, nous le taggons comme GTFS-Flex et ne le validons pas.

Personnellement ça ne me semble pas justifié (on pourrait tout de même le valider comme GTFS de base et donc extraire les metadata), mais comme ce fut une décision consciente explicite je me vois mal la remettre en question sans l'avis des personnes concernées.

[Brewennn]

Etant donné que les règles de validation de GTFS Flex sont sorties (voir #4550), il y a deux solutions :

• Soit on peut implémenter rapidement ces règles et le problème sera résolu ?
• Soit ça prend du temps et dans ce cas, peut-on quand même agir sur le score de fraîcheur car on arrive à extraire la donnée sur les calendriers d'exploitation même pour les jeux contenant du Flex ?

[ptitfred]

Je ne comprends pas pourquoi on ne commence pas déjà par valider ces GTFS de façon traditionnelle sans se préoccuper de l'extension GTFS Flex. Qu'est-ce que je ne vois pas dans tout ça ?

[Brewennn]

@cyrilmorin et @AntoineAugusti, peut-on revoir notre position consistant à ne pas valider les GTFS lorsqu'ils contiennent booking_rules.txt ou locations.geojson ?

[cyrilmorin]

Hello,

L'objectif initial n'est effectivement pas de ne pas le valider, mais bien de ne pas signaler comme NOK ou OK (score de qualité) les GTFS-Flex alors que nous ne sommes pas capables de le valider.

Pour info on avait plutôt le cas GTFS-Flex (TAD) séparé du GTFS (Transport régulier) car il y a différents outils de modélisation de la donnée. Donc ils étaient par définition "en erreur" règles TAD très différentes. On aura peut-être de plus en plus un GTFS global (avec du flex) mais probablement pas tout de suite.

Dans l'idéal et maintenant que ces règles de validation sont officielles, il faudrait supprimer cette exception et valider les règles comme initié dans #4550 :)
Attention il est possible qu'en enlevant l'exception sans les nouvelles règles, le score de qualité d'IDFM sera à 0 s'il y a du TAD zonal (pas vraimeent plus acceptable)

Mn avis : ces exceptions sont toujours très imparfaites et galères à maintenir dans le temps et surtout incorrectes selon les cas de figures avec beaucoup d'effets de bord.
La seule solution viable est l'introduction des règles TAD zonal dans notre validateur

[Brewennn]

Etant donné que l'implémentation des règles Flex prendront du temps, peut-on trouver une solution à court terme pour quand même agir sur le score de fraîcheur bien que la validation n’aboutit pas ?

[AntoineAugusti]

@Brewennn J'ai fait une PR pour forcer le score à 1 uniquement pour ce GTFS.