search

datagouv / cadastre

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

2 types différents pour le champ "contenance" des fichiers parcelles Etalab en shapefile #94

Open geoemka opened 4 years ago

geoemka commented 4 years ago

Bonjour

Juste pour info, on détecte 2 types déclarés pour le champ "contenance" des parcelles cadastrales Etalab 2020, fichiers parcelles.shp. On a très occasionnellement du 'Real' avec des décimales, et plus souvent des 'Integer'. Sachant que l'unité est le m² et que l'information est au m² près (à ma connaissance) , le type integer donne le bon niveau d'information.

Si avoir facilement un seul type pour ce champ dans le fichier source Etalab est possible, c'est un petit gain de temps !

Cordialement, Mathieu K

ChristopheVergon commented 4 years ago

Bonjour Effectivement l'unité cadastrale de contenance est le m², le codage d'origine est celui issu des fichiers MAJIC (matrices cadastrales) et mieux qu'integer c'est varchar[4]. Il s'agit de la contenance fiscale, la deuxième contenance de type real doit provenir du calcul de contenance graphique à partir du plan, un st_area(parcelle.geom) qui devrait effectivement être arrondi au m². Après le shp c'est un truc de la préhistoire donc j'utilise pas et la soupe d'Etalab à partir de l'Edigéo d'origine encore moins. Même si je félicite @jdesboeufs régulièrement pour le boulot qu'ils font. Ce serait tout de même un peu beaucoup de la responsabilité du producteur de données d'expliciter ce genre de chose mais bon la DGFiP c'est la grande muette. Pour terminer sur ces histoire de contenance la seule qui a une valeur c'est la contenance arpentée par un géomètre expert et je ne sais plus si le tag arpenté est présent ds les données EDIGéO. Dans les données MAJIC oui. J'ajoute que l'on devrait préciser le système de projection car une contenance de parcelle varie en fonction de la projection utilisée, c'est sur que pour trois m² ça va pas avoir d'effet mais pour plusieurs hectares ...