[Very WIP] Consolidation brute pour le registre d'arrêts

[thbar]

Suite à cogitations avec @ptitfred (et @Brewennn aussi qui complètera), je pose à plat les éléments pour implémenter un fichier brut intégrant la totalité des arrêts de tous les fichiers NeTEx et GTFS listés sur le PAN.

Contexte:

• [EPIC] Registre d'arrêts national (NSR) #4034

Modèle conceptuel de données pour le fichier brut

Voir: https://docs.google.com/document/d/17lGl_NlQhsl0o6Qw4Ku6cd0GZMX-R0sECCidTalqzko/edit?tab=t.0

TODO:

• corriger le rendu ci-dessous, ça passe bien dans l'éditeur Mermaid Live mais moins bien sous Safari ici.
• modifier le lien UML entre Identifier et les attributs main_id et secondary_ids
• documenter les champs (description texte pour désambiguer)
  • structuration de l'identifiant de source (PAN:$$datagouv_resource_id$$)
• affiner en itérant sur la donnée réelle (on a assez pour avancer)

classDiagram
    Stop --> "0..1" Stop : can be child of
    Stop --> "n..1" DataSource : belongs_to
    class Stop{
      latitude: decimal
      longitude: decimal
      referentiel: string [wgs84,lambert93]
      ----
      main_id: Identifier
      secondary_ids: [Identifier,...]
      stop_type: string [...]
      display_name: string
      ----
      data_source_id: string
      data_source_format: string [netex,gtfs]
      ----
      +Stop Parent
    }
    class DataSource{
        id: string
        checksum: string
        last_update_at: datetime
        validity_period: datetime_range
    }
    class Identifier{
        id: string
        type: enum[main,private_code,stop_code,...]
    }

Loading

“Prior art” en lien avec l'effort "registre d'arrêts" dans la code-base

Éléments de code qui vont dans le même sens / servent d’inspiration / sont utiles pour implémenter la présente issue.

GTFS

• Remontée en base de fichier GTFS et calculs des prochains départs #2105
• Module d'import unitaire GTFS stops avec suppression + outils associés #2851
• Structuration import GTFS en batch job + dashboard de reporting #2920
• Idées de système permettant de représenter la densité d'arrêt, puis les arrêts eux-mêmes #2982
• Visualisation "snap to grid" des arrêts GTFS #2995
• Optimisations pour la carte GTFS nationale #3122

NeTEx

• Premiers extracteurs NeTEx (StopPlaces) #4026

Idées pour l'implémentation du fichier brut.

On arrive à l'idée qu'on ferait quelque chose comme suit (sachant qu'on en reparle plus en détail avec @ptitfred ce matin, ce sont des idées brutes):

• un rafraîchissement nocturne et publication en tant que ressource expérimentale du PAN toutes les nuits
• deux fichiers produits : un CSV qui liste les Stop (voir MCD ci-dessus) et un autre qui liste les fichiers utilisés dans la consolidation données
• au niveau implémentation: on peut travailler à partir de la notion d'extracteur homogène: le contrat d'un extracteur serait de prendre une ressource (ou une ressource history, voire les deux de façon souple pour traiter des scénarios "hors historisation" plus aisément et réduire le couplage), et d'avoir une fonction type qui génère un stream de "points" par fichier d'entrée (et que ce stream serve éventuellement à créer un DataFrame si on veut s'appuyer là dessus pour consolider derrière)

à suivre

Itérations

1. Définir une première struct "stop" simple avec des attributs minimaux (latitude / longitude / type de format / identifiant de la resource PAN:$$datagouvid$$ / "stop type" / "main id")
2. Créer un module "extracteur" NeTEx qui prend en entrée un fichier ("ZIP") sur le disque et qui en sortie (contrat) livre un Stream de struct "stop" (voir au dessus), sous tests
3. Créer la même chose sur GTFS (toujours d'après un fichier sur le disque)
4. Générer un CSV (moyen à définir) qui va agréger, pour toutes les ressources NeTEx et GTFS du PAN - sans chercher à faire de tri pour l'instant (streamé bêtement). En entrée : une liste d'urls, associées chacune à un identifiant. En sortie: un fichier sur le disque avec des entêtes.
5. Générer un CSV secondaire qui contiendra identifiant de la ressource, et checksum du fichier, pour appuyer le premier fichier
6. Publier les deux comme 2 ressources dans 1 dataset, en mode "experimental", toutes les nuits

[ptitfred]

Techniquement parlant :

WGS84 est un système géodésique, communément associé à la projection cartographique UTM (Universal Transverse Mercator), tandis que Lambert 93 est une projection, associée au système géodésique RGF93.

Projection cartographique	Système géodésique
UTM	WGS84
Lambert 93	RGF93