feat(all) : Récupérer les données géo depuis l'API découpage administratif

[vperron]

Ceci permet entre autres de:

• récupérer les DOM/TOM
• récupérer l'intégralité des codes EPCIS, Départements, Régions à jour
• les communes ainsi que les arrondissements
• ne plus dépendre ni d'admin_express, ni des exports de l'INSEE
• de ne pas avoir un import séparé dans le pipeline et dans l'API
• passer à un modèle de détection de distance par rapport au centre de la ville et non pas son contour, donc plus performant et avec peu de perte de précision (pas encore réalisé)
• bien d'autres joyeusetés à venir en termes de validation, cohérence, etc

[vmttn]

Je pense qu'il y a moyen de simplifier 🙊

1. On peut se passer du dump des extractions dans s3. Contrairement aux fournisseurs de données, le niveau de service de cette api devrait être bonne et les données relativement stables, en tout cas il n'y a pas de raisons de penser le contraire
2. Séparer clairement les transformations de l'extraction et utiliser dbt pour faire les transfo et le nettoyage des données. L'extraction peut se résumer à quelques appel, du json chargé dans une colonne jsonb, nettoyée par dbt et passée au format tabulaire avec des tests
3. Je ne peux pas m'empêcher de penser qu'on devrait charger les données également dans l'api à partir de l'api découpage. Les données structures/services sont produites par notre pipeline ce qui justifie leur stockage régulier sur s3. Le risque d'incohérence me parait franchement minime et une simple vérification au moment de l'import de nos données devrait suffire à écarter les quelques incohérences qui pourraient se produire si on n'a pas pris le soin de mettre à jour les données découpages dans l'api et la pipeline simultanément

[vperron]

1. OK, ça m'ira toujours de simplifier ! J'ai toujours ce conflit cohérence avec le reste du code VS traitement spécifique.
2. OK aussi, ça me va bien (d'où le wip)
3. A moitié convaincu, car avec ta solution:

• On a besoin d'un second script d'extraction (similaire mais assez différent, p.ex merger les arrondissements reste valide mais le traitement, création de la table et traitement éventuel sur les colonnes seront en Python/Alembic et non pas en DBT)
• N'élimine pas le risque d'incohérence, au contraire on en introduit un. OK il suffit d'un check mais ça ajoute un check qui aurait pu être prétesté en pipeline.
• On n'est pas à l'abri que demain l'API ait besoin d'autres tables venant de notre pipeline pour enrichir les données (voire enrichir les données de commune)
  ... et encore une fois pour moi ça permet de ne conserver qu'une seule méthode pour charger toutes les données de l'API en un seul coup, ce qui le rend plus simple, solide et facile à maintenir.

[vperron]

A priori, fait les ajustements (grosse maille) que tu voulais voir @vmttn .

[vperron]

Remarques traitées et commandes d'import des communes restaurée coté API.