datagouv / cadastre

Scripts de préparation des données cadastrales diffusées par Etalab
67 stars 10 forks source link

Ajout de nouveaux champs pour les feuilles (GéoJSON) #126

Open SOGEFI opened 1 year ago

SOGEFI commented 1 year ago

Actuellement pour les feuilles cadastrales (layer SUBDSECT_id des lots ÉDIGÉO) tous les champs ne sont pas restitués dans les fichiers GéoJSON.

Les champs :

ne sont pas présents dans les fichiers GéoJSON or ils sont pertinent pour des analyses statistiques. Est-il possible de les rajouter ?

biratchet commented 1 year ago

Je vote pour!

ThomasG77 commented 1 year ago

Partagé à l'idée de faire ainsi car changer la structure d'une donnée employée de manière importante par des tiers = risque de tout casser dans leurs traitements automatiques

J'envisage plutôt de traiter à part et de le sortir dans un CSV car on est déjà capable de sortir ces colonnes avec le parser actuel (pas dans ce dépôt mais celui https://github.com/etalab/edigeo-parser)

J'ai un traitement en cours pour sortir un CSV qui prend un peu du temps (de l'ordre de la journée). Je ferais un autre commentaire quand cela sera fait et dispo quelque part. Pour le moment, bien qu'automatisé, le traitement est plutôt séparé du reste de la logique de l'existant. Je verrais pour mieux intégrer si le besoin devient moins "confidentiel".

ThomasG77 commented 1 year ago

Fichier sur https://cadastre.data.gouv.fr/data/edigeo-feuilles-2023-01-01.csv. Attention, l'emplacement pourra être amené à changer, n'ayant pas communiqué dessus.

Il faut aussi noter que le parser n'a pas été capable d'extraire les infos de 639 sections parmi 594873 (je n'ai pas investigué si c'est le parser ou la donnée en cause). Il y a 594873 sections identifiées mais lors d'une jointure avec les fichiers GeoJSON existants, il est possible que vous ayez moins de 594873 sections car les géométries des sections ne sont malheureusement pas toutes extraites correctement des données Edigeo. De ce fait, vous pouvez déduire indirectement le nombre de sections sans géométrie.

En effectuant un post-traitement avec GDAL en complément, on a corrigé presque toutes les erreurs (5 cas sont en erreur pour cause de fichiers THF manquants). On a donc les infos de 594868 sur 594873 sections maintenant. Sur le même lien, j'ai écrasé le fichier antérieur.

Le format date sur les champs du type 02/02/2005 n'est pas toujours respecté (voir par exemple le cas du champ DEDI en PJ dates-dedi-sections-anomalies.txt ).

Il faut noter que DATE_OBS (CREAT_DATE), DATE_MAJ (UPDATE_DATE) sont formatés différemment sous la forme 02-02-2005 du fait d'un traitement.

SOGEFI commented 1 year ago

Super !

Partagé à l'idée de faire ainsi car changer la structure d'une donnée employée de manière importante par des tiers = risque de tout casser dans leurs traitements automatiques

En l'occurrence ici il ne s'agit que de l'ajout de nouveaux champs (aucune modification ou suppression de champs existants).

En attendant l'extraction systématique de ces infos, Est-il possible de disposer d'un fichier plus à jour (données avril 2023) ?

ThomasG77 commented 12 months ago

Fichier sur https://cadastre.data.gouv.fr/data/edigeo-feuilles-2023-04-01.csv. A vous de faire la jointure de votre côté.

Les champs ne changeront pas car tous les autres utilisateurs dépendent d'une structure particulière des fichiers et le "aucune modification ou suppression de champs existants" n'empêche pas de tt casser chez les autres selon comment ils intégrent la donnée dans leur SI.

SOGEFI commented 12 months ago

ok merci. Est-il prévu de produire ce fichier à l'arrivé de chaque nouveau millésime ?

ThomasG77 commented 12 months ago

Est-il prévu de produire ce fichier à l'arrivé de chaque nouveau millésime ?

Oui

ThomasG77 commented 10 months ago

Dernier fichier sur https://cadastre.data.gouv.fr/data/edigeo-feuilles-2023-07-01.csv