ImportData : gérer conflits dans la détection de formats

[AntoineAugusti]

Suite de #4063. #4066 améliore la situation mais des conflits persistent pour certaines ressources.

Cas actuellement problématique :

• URL : http://example.com/export?key=opendata-gtfs-rt
• Titre : SIRI Lite SX

https://github.com/etalab/transport-site/blob/aa175694b7e54a4f2b4e5f8136dc228f4d328b77/apps/transport/lib/transport/import_data.ex#L351-L359

La ressource va matcher en tant que GTFS-RT (param URL) et en tant que SIRI Lite (titre de la ressource).

La priorité voudrait que : format > titre > description > URL mais le code actuel a cette logique uniquement pour chaque clause de détection de format, pas au global.

Les 2 ressources sont match pour 2 formats différents, mais le Enum.uniq_by va conserver uniquement le 1er match, et il se trouve que get_valid_gtfs_rt_resources est avant get_valid_siri_lite_resources, on retient donc la ressource avec un format détecté comme GTFS-RT actuellement.

https://github.com/etalab/transport-site/blob/aa175694b7e54a4f2b4e5f8136dc228f4d328b77/apps/transport/lib/transport/import_data.ex#L280-L282

[vdegove]

Merci pour l’explication, très clair :ok_hand:

On peut vivre avec ces cas problématiques un moment ou pas ?

[vdegove]

Parce que bon, tu vois arriver la solution un peu bourrin : au lieu de faire tous les checks format par format (et à l’intérieur de chaque format, puis par priorité de format déclaré > titre > …), faire les checks d’abord par priorité format déclaré > titre > etc et à l’intérieur de chacun de ces cas, trouver le format. Mais gros gros travail.

[AntoineAugusti]

On peut vivre avec ces cas problématiques un moment ou pas ?

Oui et non.

Oui car c'est un problème qui est là depuis très longtemps, qui concerne une faible volumétrie.

Non car :

• Dans certains cas, ça fait une erreur 500 sur le JDD car on lance une validation avec un format, le format de la ressource change et on a une incohérence entre format de la ressource et validation effectuée.
• Pour les autres cas on a un affichage incohérent, des ressources qui ne sont pas affichées, des producteurs confus.

[AntoineAugusti]

En profiter pour s'assurer qu'on regarde aussi l'URL pour détecter le format GTFS, ce qui n'est pas fait actuellement.

https://github.com/etalab/transport-site/blob/af527629b29eeaf4cc02c49d096e2213224d74ec/apps/transport/lib/transport/import_data.ex#L486-L498

[Brewennn]

Je me demandais s'il était souhaitable de rajouter un niveau de détection dans le cas où une ressource GTFS n'est pas importée alors que le titre ou la description du jeu indique 'GTFS', consistant à détecter le format indiqué dans les métadonnées de la ressource headers:content-type = 'application/zip' (voir exemple GTFS de Lille non détecté par le PAN). Il y a cependant des limites :

• Ajout d'un niveau qui ferait appel à l'API de data.gouv.fr pour obtenir les métadonnées de toutes les ressources d'un JDD précis, ce qui ajoute de la complexité au processus.
• Possibilité de détecter de faux positifs (des fichiers compressés qui n'ont rien à voir) mais faire cette détection via les métadonnées en seconde règle limite ce risque.