Ressources et ResourceHistory avec des métadonnées inattendues

[AntoineAugusti]

Il a été découvert que certaines ressources qui ne sont pas des GTFS ont des métadonnées qui sont réservées normalement aux GTFS. Ces métadonnées se sont retrouvées dans des ressources historisées également.

Il faudrait comprendre pourquoi on est arrivé à un tel état et réparer la cohérence des données.

Originally posted by @fchabouis in https://github.com/etalab/transport-site/issues/2228#issuecomment-1075256450

[AntoineAugusti]

Il y a des ressources en production actuellement qui ont des métadonnées propres à des GTFS. Contrairement à ce qui a été dit dans le commentaire initiale, il n'y a pas que des NeTEx, bien que ce soit quasi exclusivement le cas.

select *
from resource
where format != 'GTFS' and metadata ? 'modes'

J'ai 43 ressources

Il n'y a pas de logs de validation pour ces ressources, où la validation n'a pas été skipped.

select *
from logs_validation
where resource_id in (select id
from resource
where format != 'GTFS' and metadata ? 'modes') and not skipped;
# -> 0 rows

Il y a des ResourceHistory qui ont été dans leur vie des GTFS et des NeTEx, la classification GTFS semble erronée.

select *, payload->>'format', payload->>'resource_metadata'
from resource_history
where datagouv_id = '21c91b3a-e34e-4961-9ce9-76f0a64454ee'

On remarque des différences entre

• payload->>'format' (rempli depuis resource.format)
• payload->>'resource_metadata' (qui provient des métadonnées de l'ancien système d'historisation)

Le code de migration de l'ancien système au nouveau pourrait contenir des bugs.

À noter également que depuis https://github.com/etalab/transport-site/pull/2038 les métadonnées d'une ressource sont conservées d'un import quotidien à l'autre, dès lors qu'on peut réidentifier la ressource dans notre système. Avec ça en tête, il suffit d'une mauvaise classification/validation et d'un stockage de métadonnées pour perpétrer des données erronées.

[AntoineAugusti]

J'ai regardé les ressources du Rhônexpress qui comporte 1 GTFS et 1 NeTEx.

select *, payload->>'format', payload->>'resource_metadata'
from resource_history
where payload->>'dataset_id' = '288'
order by inserted_at;

On remarque que :

• les datagouv_id changent tous les jours
• les métadonnées comportent des infos propres à du GTFS pour toutes les lignes, GTFS ou NeTEx
• la 1ère ligne date du 2022-03-08 ce qui est relativement récent

resource_metadata est rempli depuis DB.Resource.metadata lors de l'historisation

https://github.com/etalab/transport-site/blob/85dd6494a89b6736612f5b6eeefae30937ff5b75/apps/transport/lib/jobs/resource_history_job.ex#L99

En local, j'ai supprimé ce JDD et je l'ai importé/validé sans réussir à avoir des métadonnées GTFS dans la ressource NeTEx.

Je n'ai pas de piste pour le moment expliquant comme resource.metadata peut contenir des métadonnées GTFS pour du NeTEx

[AntoineAugusti]

@etalab/transport-tech si vous avez des idées sur ce sujet je prends toute piste

[thbar]

J'ai survolé très très rapidement ; je m'interroge depuis un moment sur le cycle de vie des "data gouv id". On peut se demander s'il n'y aurait pas une sorte de recyclage quelque part, ou des choses du genre "il y a unicité temporairement", puis ça disparaît puis ça revient avec un autre identifiant (remplacement lent), et là c'est la collision.

Je peux essayer de creuser semaine prochaine, je serais d'avis de faire des snapshots des identifiants dans un coin "sûr" et immutable, et de voir si on a une forme de drift ou autre.

Désolé c'est très rapide en 5 minutes :-)

[AntoineAugusti]

@thbar Les datagouv_id semblent changer en effet régulièrement pour les ressources qui sont moissonnées depuis ODS sur datagouv, ça c'est embêtant et une première chose.

Mais la question des métadonnées qui semblent provenir du validateur GTFS dans des ressources dont format != 'GTFS' reste non résolue.

La possibilité que je vois c'est :

• une ressource est avec une URL distante avec le format GTFS
• la ressource distante change (mais pas son URL) et on conserve la même ressource, et surtout les mêmes métadonnées dans notre système
• on a ainsi une ressource avec un format non GTFS mais des métadonnées incohérentes

https://github.com/etalab/transport-site/blob/85dd6494a89b6736612f5b6eeefae30937ff5b75/apps/transport/lib/transport/import_data.ex#L662-L670

Ce qui me parait étonnant c'est qu'à première vue les URLs des ressources sont clairement des NeTEx (mot inclus dans les URLs par exemple).

[fchabouis]

Je pense avoir compris :tada:

J'ai regardé la liste des validations de ressources non GTFS qui ont abouti a des metadonnées qui trahissent une validation GTFS :

select * from validations v inner join resource r on    v.resource_id = r.id where r.metadata ? 'modes' and r.format != 'GTFS' order by date desc

Les dates de ces validations vont du 2/4/20 au 18/10/2021

J'ai été voir les PR mergées le 18/10/2021 : https://github.com/etalab/transport-site/pulls?q=is%3Apr+merged%3A2021-10-18

Il n'y en a qu'une, qui parle justement de NeTEx : https://github.com/etalab/transport-site/pull/1849

Un changement notable (j'ai pas fait exprès), c'est que j'ai ajouté cette ligne : https://github.com/etalab/transport-site/pull/1849/files#r834442251

Autrement dit, quand une ressource est identifiée comme NeTEx lors de l'import, on lui ajoute explicitement le type NeTEx. A cet endroit, on va identifier une ressource comme NeTEx grâce au format fourni par data.gouv ou en lisant sa description, voir https://github.com/etalab/transport-site/blob/3e44c53fa7ed354b66869ffe915378d560d2c356/apps/transport/lib/transport/import_data.ex#L530

Dans l'import de la ressource, cette phase se fait ici

Quelques lignes plus bas, on appelle la fonction formatted_format, qui uniformise les formats, mais uniquement en se basant sur le format de la ressource, et pas sur sa description.

Si par hasard le dataset est de type public-transit et que tous les checks de formats échouent, on finit par dire que c'est une ressource GTFS, future candidate à validation.

Conclusion : des NeTEx dans un dataset public-transit mal taggués dans data.gouv.fr, mais qui avaient "netex" dans leur description se retrouvaient taggués en GTFS chez nous, puis étaient validés. Entre temps, la PR #1849 a permi par hasard de corriger le problème. Le format de la ressource est passé à NeTEx, mais les metadatas associées sont restées.

Super Conclusion : on peut virer toutes ces metadatas, ça ne devrait plus arriver :)

:octopus:

[thbar]

Superbe, bien joué !

[AntoineAugusti]

@fchabouis Merci M. Chabouis !!!

[fchabouis]

Note : les mauvaises métadatas se sont retrouvées historisées dans les ResourceHistory, on pourra aussi éventuellement les nettoyer là