[Question] Pourquoi y a-t-il moins de pdc dans la v2.3.1 par rapport à la v2.2.0 malgré l'assouplissement ?

[BastienGauthier]

Bonjour,

Aujourd'hui par exemple, 66298 pdc en 2.3.1 vs 69811 pdc en 2.2.0, alors qu'il y a bien les pdc "ES*" en 2.3.1. Quel est l'autre changement que j'ai raté qui a l'effet inverse ?

Bonne journée !

[thbar]

Hello @BastienGauthier! (et poke @cyrilmorin) ! Merci pour cette très bonne question :smile:

La mise à jour du schéma peut avoir des impacts positifs ou négatifs, toutefois ce que vous constatez là est lié (a priori) au fait que seuls les jeux valides sont intégrés à la consolidation, et qu'ils peuvent devenir invalides sans que le schéma ne change (pour des questions de production de données), lors d'une mise à jour d'un jeu individuel.

Nous travaillons à améliorer le suivi sur ce point (par exemple, à envisager de conserver, pour un jeu donné, la dernière version "valide" du jeu et à l'intégrer, lorsque ses futures versions deviennent invalides, pour assurer une meilleure continuité de la donnée).

Dans le cas présent il s'agit probablement d'un "gros producteur" dont le fichier sera devenu invalide, indépendamment de cette évolution de schéma.

Je conserve le ticket ouvert car c'est une bonne question et une raison identifiée d'améliorer le fonctionnement de la consolidation.

Pour avoir l'explication complète, il faudra:

• prendre l'ancien fichier et le nouveau, le comparer
• générer un différentiel des identifiants ayant bougé (ajoutés / supprimés, surtout)

[BastienGauthier]

Bonjour @thbar, merci pour la réponse ! Je comprends donc qu'on ne continue pas à faire tourner les anciennes versions en double run, et que la 2.3.1 est construite avec des fichiers différents de la 2.2.0, c'est bien ça ? Pour ce que vous mentionnez de la combinaison des fichiers à différentes dates, j'ai fait l'exercice de mon côté, et ça fonctionne plutôt bien : https://github.com/BastienGauthier/clean_french_irve

Dans le graphes du readme, on voit bien le gain de la combinaison (vert) vs le fichier sur la plateforme (bleu).

[thbar]

Poke @Pierlou qui se charge actuellement de cette consolidation !

[Pierlou]

Bonjour, Toutes les versions non mentionnées comme étant à ne pas consolider sont consolidées. Les fichiers des versions précédentes sont des reliquats, qui ne seront plus mis à jour et peuvent donc être supprimés ou conservés pour mémoire, à la discrétion de l'équipe transport. Le code de consolidation est ouvert et disponible ici, en résumé :

1. on scrute toutes les ressources de data.gouv.fr qui ressemblent de près ou de loin à des données IRVE
2. les ressources ainsi remontées passent au crible de la validation
3. toutes les ressources valides pour une version donnée (parmi celles qui doivent être consolidées) sont agrégées et enrichies (notamment avec les colonnes de géocodage)
4. publication en csv et geojson

NB : vu le contenu des modifications entre la 2.2.0 et la 2.3.1, il est fort probable que si la consolidation tournait pour la 2.2.0 aujourd'hui, le fichier serait sensiblement le même que la 2.3.1 (voire plus léger, car la 2.3.1 est plus permissive). Je laisse transport répondre sur l'analyse de quels fichiers sont entrés/sortis pour entrainer la baisse mentionnée.

[BastienGauthier]

Bonjour, merci pour toutes les réponses. Je pense que ma question a été répondue dans le sens où je n'avais pas vu que la 2.2.0 était toujours exposée mais ne tournait plus. Je n'ai pas particulièrement besoin du détail des fichiers entrés/sortis.

Pour @Pierlou , je pense que la mention était plutôt vis-à-vis de la possibilité d'intégrer ce petit effet mémoire dans la consolidation pour avoir en permanence les fichiers, même s'ils ne sont pas disponibles quelques jours.

(Côté geocodage il y a également la question de l'issue #25, mais c'est un autre sujet)

[Pierlou]

Je ne suis pas sûr de comprendre "l'effet mémoire" en question. La consolidation tourne tous les matins et scanne tous les fichiers de data.gouv à l'instant T.

[BastienGauthier]

L'idée de l'effet mémoire que je mentionne est qu'une fois la consolidation du jour faites, comparer à celle de la veille avant qu'elle soit écrasé pour conserver la ligne correspondant aux pdc qui étaient là la veille mais qui ont disparus. Ça impose de garder aussi un petit fichier de date de dernière vue pour chaque pdc pour nettoyer les lignes qui ne sont pas apparues depuis 6 mois typiquement, mais ça permet d'être beaucoup plus robuste sur le fichier exposé. Dans le lien plus haut, je fais ça depuis quelques semaines et j'ai déjà ~20k pdc de plus, donc ça me semble une bonne voie pour exposer un fichier plus stable.

[thbar]

Hello @BastienGauthier ! Mes excuses pour le délai de réponse.

Je comprends ce que vous dites, c'est grosso modo la même idée que ce que j'ai évoqué plus haut:

Nous travaillons à améliorer le suivi sur ce point (par exemple, à envisager de conserver, pour un jeu donné, la dernière version "valide" du jeu et à l'intégrer, lorsque ses futures versions deviennent invalides, pour assurer une meilleure continuité de la donnée).

Quand on consomme le jeu de données, on ne veut pas être "surpris" (ni se poser la question) par la disparition de 10-20% de l'agrégat pour des raisons qui sont souvent indépendantes de la réalité terrain de l'existence des points de charge.

Il faut qu'on travaille à une mémorisation effectivement pour ne pas impacter autant les ré utilisateurs, et créer de la confiance dans le jeu.

Poke @jmaupetit également sur ce sujet (Qualicharge).

@Pierlou il faudra qu'on en reparle avec Julien, arriver à assurer une continuité sur ce sujet est important pour la qualité du fichier.