thbar
commented
2 days ago Merci @vdegove super support de discussion
Open vdegove opened 2 days ago
thbar
commented
2 days ago Merci @vdegove super support de discussion
vdegove
commented
2 days ago Note de Antoine sur les datasets qui contiennent un GTFS par territoire (Mobigo)
vdegove
commented
2 days ago Après discussion entre développeurs, la stratégie globale pour adresser ce chantier peut se résumer ainsi :
(C’est un peu ce qui a été fait pour les legal owners.)
La structure générale de la base de données expliquant à quoi correspond les dataset peut être améliorée. Il y a trois catégories de données distinctes dans l’idéal :
À noter que cela doit être éditorialisé : par exemple, la couverture territoriale ne correspond pas forcément aux arrêts contenus par les fichiers GTFS/Netex, il est fréquent, par exemple, qu’il y a ait des extrémités de lignes en dehors de ce territoire.
Ces données sont entremélées (une AOM porte elle-même sur un territoire, de même qu’une offre…) mais pas équivalentes. On peut par exemple avoir, pour les autocars interurbains, une AOM unique régionale qui choisit de publier un dataset par département. Inversement, on peut avoir les données des TER, qui correspondent à toutes les AOM régionales, publiées sous un unique dataset.
Aujourd’hui, on a une structure de base de données qui décrit très imparfaitement cette situation – les territoires sont mal définis, on a une AOM legacy à la fois territoire et responsable légal, on n’a pas d’offres. C’est relativement mal exposé à l’extérieur également : par exemple le contenu des tables legal owner n’est pas exposée en dehors du backoffice, ni en graphique, ni en API.
Pourquoi faire ce travail ?
Expliquer à quoi correspondent les dataset, ce qu’ils contiennent vraiment, sur quels territoires ils portent, etc, a plusieurs avantages :
Problèmes de la structure actuelle
Voir l’état des lieux des données géographiques.
On est actuellement dans un entre-deux en modèle de données. Il y a un premier modèle naïf, en 1 à 1, qui avait été fait, avec des colonnes uniques sur dataset, où le dataset était soit rattaché à une région, soit à un AOM (= AOM local), cet AOM étant à la fois territoire et responsable légal.
Le one to many a été introduit plus tard :
D’un point de vue métier, on ne peut juste pas définir la réalité, par exemple un dataset dont le territoire correspond à un département est aujourd’hui rattaché faute de mieux à la région. Voir https://docs.google.com/spreadsheets/d/1iGD17lUiL1lMrOkgbvj8lyoVv5WUV6t7I3eFJpwWUn0/edit?gid=899184689#gid=899184689 pour les cas problématiques de définition territoriale : on a 183 datasets, représentant 33% de nos datasets, qui ne peuvent pas avoir la bonne couverture territoriale.
Les deux problèmes causés d’un point de vue dev :
Difficulté : grosse part du PAN appuyé sur le modèle de données
Quand on touche à ça, potentiellement, ce qui bouge :
Donc un bon bout du PAN.
Vision cible
Certains détails peuvent changer, par exemple pour les legal_owners et les aoms, on peut garder deux tables selon si l’AOM est un EPCI ou une région.
Également : il y a un lien entre offer et AOM à travers une table de jointure. En fait, pas mal de choses sont circulaires : on pourrait vérifier au passage lors des imports que les données sont cohérentes.
Enfin, legal owner peut aussi être une entreprise (SIREN).
Quoi faire dans quel ordre
L’import des offres de la base PASSIM peut représenter un chantier à part sans impact sur le reste, dans sa version minimale.
Pour le reste, l’ordre logique :
Side quests :