Information sur l'expiration des réseaux saisonniers

[Brewennn]

Réflexion à avoir sur l'amélioration de l'information de l'expiration des données de réseaux saisonniers. Cette amélioration permettrait de :

• désactiver les notifications pour demander la mise à jour des données (ex : de mail).
• d'éviter une baisse du score de qualité des données (ex : JDD Bourg Saint Maurice)

Pour indiquer que la ressource est bien à jour mais que le service n'est pas disponible car il est hors saison, il est nécessaire d'ajouter le fichier 'feed_info.txt' dans le GTFS. Dès lors se pose la question des règles à adopter pour l'information des valeurs de ce fichier.

• Préciser les règles pour les valeurs 'feed_start_date' et 'feed_end_date' par rapport aux valeurs de 'calendar.start_date' et calendar.end_date'.
• Inclure les nouvelles règles dans la validateur pour les envois de notifications et l'affichage de l'expiration des données.
• Publier une page de la documentation sur la publication des données de réseaux saisonniers et une communication à cet effet.

@AntoineAugusti

[AntoineAugusti]

etalab/transport-validator#217 ajoute les métadonnées nécessaires dans le validateur GTFS du PAN

[Brewennn]

Au regard de la spécification GTFS, je propose les règles suivantes pour remplir feed_info.txt :

• les champs obligatoires feed_publisher_name, feed_publisher_url et feed_lang doivent être renseignés :
  - feed_lang est paramétré à 'fr' par défaut.
  - Si un seul agency dans le JDD alors feed_publisher_name = agency.agency_name et feed_publisher_url =agency.agency_url.

• le champ facultatif feed_end_date doit être renseigné :
  - dans tous les cas cette date doit correspondre à la date prévu de mise à jour du JDD. Ainsi pour un réseau saisonnier, feed_end_date doit être supérieur à calendar.end_date et/ou la dernière date de calendar_dates.txt.

• le champ facultatif feed_start_date peut rester facultatif même si on préconise de le remplir. Ou le rendre obligatoire au regard de Add metadata for feed_info transport-validator#217 ?

[AntoineAugusti]

Ainsi pour un réseau saisonnier, feed_end_date doit être supérieur à calendar.end_date et/ou la dernière date de calendar_dates.txt.

Doit être supérieur à la date de fin, correspondre à la date la plus tardive possible à laquelle il est certain que le service ne sera pas en opération.

Si ceci correspond à la date de fin du calendrier on enverra des rappels d'expiration, pensant qu'on attend une mise à jour à cette date.

[Brewennn]

On est d'accord @AntoineAugusti. Pour feed_start_date on le laisse facultatif ou on demande à le renseigner ? On peut opter pour la deuxième solution sachant que ce n'est pas compliqué à indiquer.

[AntoineAugusti]

On peut conseiller de le renseigner je pense

[AntoineAugusti]

@Brewennn Voici la liste des réseaux saisonniers qui ont un fichier feed_info.txt et la valeur renseignée par rapport à la date de fin du calendrier.

url	end_date	feed_end_dates	custom_tags
https://transport.data.gouv.fr/datasets/navette-chorges-chanteloube-ete-2024-reseau-vai	"2024-08-25"	{"Communauté de communes de Serre-Ponçon": "2024-08-25"}	{saisonnier}
https://transport.data.gouv.fr/datasets/navettes-stations-hiver-2024-2025-reseau-vai	"2025-04-13"	{"Communauté de communes de Serre-Ponçon": "2025-04-13"}	{saisonnier}

select 'https://transport.data.gouv.fr/datasets/' || d.slug url, rm.metadata->'end_date', rm.metadata->'feed_end_dates', d.custom_tags
from resource r
join (
  select
    rh.*,
    row_number() over (partition by rh.resource_id order by rh.inserted_at desc) row_number
  from resource_history rh
) rh on rh.resource_id = r.id and rh.row_number = 1
join multi_validation mv on mv.resource_history_id = rh.id and mv.validator = 'GTFS transport-validator'
join dataset d on d.id = r.dataset_id and d.is_active and d.custom_tags @> '{saisonnier}'
join resource_metadata rm on rm.resource_history_id = mv.resource_history_id and rm.metadata->'feed_end_dates' != '{}'

Aucun GTFS saisonnier n'a les bonnes informations de couverture dans le fichier actuellement.