Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
SOGEFI opened this issue Mar 22, 2023 · 8 comments
Open

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

SOGEFI opened this issue Mar 22, 2023 · 8 comments

Comments

@SOGEFI
Copy link

SOGEFI commented Mar 22, 2023

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 :

  • DEDI (date d'édition ou de confection du plan)
  • ICL (Orientation d'origine)
  • DIS (Date d'incorporation PCI)
  • INP (Mode d'incorporation au plan)
  • DRED (Date de réédition)

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
Copy link

Je vote pour!

@ThomasG77
Copy link
Contributor

ThomasG77 commented Mar 29, 2023

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
Copy link
Contributor

ThomasG77 commented Apr 1, 2023

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
Copy link
Author

SOGEFI commented Apr 26, 2023

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
Copy link
Contributor

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
Copy link
Author

SOGEFI commented Jul 11, 2023

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

@ThomasG77
Copy link
Contributor

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

Oui

@ThomasG77
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants