datagouv / cadastre Goto Github PK

Dériver une géométrie des préfixes cadastraux à partir des contours de sections car les parcelles sont identifiées de façon unique par 4 éléments :
INSSE + PREFIXE + SECTION + NUMERO
Sur ces quartes éléments, seul le PREFIXE ne dispose pas de géométrie dans les EDIGEO (mais elles peuvent être créées en assemblant les sections de même préfixe)

Bonjour,

Un problème vu aujourd'hui sur la commune de Mastaing (59391),
il manque des sections des parcelles etc. dans les fichiers (département et commune).

Bonjour,
Dans l'ouest de l'Aube, il manquerait quelques communes: Nogent sur Seine 10268, Saulsotte 10367... Ce qui m'intrigue c'est qu'elles sont au parcellaire polygonal de l'IGN, mais pas dans celui issu de l'EDIGEO. Alors que généralement c'est plutôt l'inverse.

Maintenant que ces formats sont fournis par la DGFiP, il faut les intégrer au processus de déploiement des données.

Pour des raisons historiques, le PCI utilise les anciens codes INSEE de Saint-Martin et Saint-Barthelemy, lorsque ces territoires étaient rattachés à la Guadeloupe.

Pour la diffusion modernisée, nous ne sommes pas tenus de respecter cela et pouvons utiliser les codes officiels en vigueur depuis 2008.

Pour des questions pratiques, le code court est considéré comme un code département, et le code long comme l'unique code commune.

Le traitement d'un département est très long.
Un minimum d'information sur la progression serait un gros plus.

Actuellement seul le numéro local de la parcelle (au sein de la section de rattachement) est exposé seul. Les autres informations hiérarchiques sont contenues dans l'identifiant.

Solution 1 : on laisse comme ça
Solution 2 : on ajoute les autres informations sur des champs séparés
Solution 3 : on supprime le numéro local de parcelle

Je remarque que dans les fichiers bâtiments, il n'y a pas d'identifiants uniques dans les geojson.

Le soucis c'est que si nous voulons mettre à jour les bâtiments dans notre base de donnée, nous devons donc tout effacer puis réimporter, plutôt que juste mettre à jour ce qui a changé.

Et donc si on ajoute des données dans notre base pour un bâtiment défini, ces données seront perdues à chaque import.

Il faudrait une clé unique immutable comme il y a pour les parcelles, ou les communes.

Il pourrait être intéréssant de récupérer ces données (code insee + prefixe section + code section + numero de plan + numero_batiment). Ou tout autre clé unique qui ne bougera pas.

Remontée beta-testeur :

J’ai 53 ID pour lesquels j’ai eu des rejets d’intégration dans la géométrie : Multipolygon avec une ligne fermée (3 sommets) à la place du 2ème polygone :

• 060530000D1399
• 11262000BO0594
• 122030000A1288
• 12024000ZC0055
• 121420000J0282
• 14160000ZN0023
• 17277040ZR0010
• 22266000BI0108
• 26212000AB0026
• 2B2870000C0220
• 333090000A1957
• 330430000A0905
• 33281000CI1032
• 34003000KV0167
• 34123000BR0155
• 342290000K0029
• 35235000ZC0022
• 351040000D1133
• 353470000L1202
• 37208000BE0378
• 480810000D0536
• 49215000BK0620
• 49215000BK0562
• 52104000ZE0053
• 54091000ZI0066
• 54091000ZI0069
• 57091000110177
• 58281000AM0236
• 591260000A0711
• 59479000AD0388
• 595090000A2770
• 59569000BH0585
• 626780000C0441
• 626780000C0438
• 68292000010229
• 68300000120426
• 68066000ND0184
• 731760000D3248
• 74124000AI0685
• 741360000A5227
• 774770000A0002
• 80443000XH0008
• 813080000B0260
• 81099000BS1146
• 81099000MO0241
• 81099000MO0177
• 86090000ZD0061
• 90094000AD0105
• 915460000C1294
• 97119000AL0196
• 972220000A0695
• 972170000K0951
• 97414000EN2546

Bonjour,

L'IGN promet de livrer en 2019 dans la BDTopo des informations d'attributs du bâti en provenance des fichiers fonciers. La BD topo est cependant décalée par rapport au bâti et aux parcelles du PCI.
Les informations utiles collectés à partir des fichiers fonciers :

Nb de logements
Nb d'étages
Date de construction
Matériaux de construction (toits et murs)
cf http://professionnels.ign.fr/doc/IGN_Nouvelle%20BD%20TOPO-10%20am%C3%A9liorations.pdf

Je pense qu'il serait plus utile et cohérent que ces informations figurent directement dans la couche bâtiment du PCI en opendata. Votre avis ?

Merci et bien à vous

Une légère simplification topologique permettrait de supprimer ce genre d'anomalie.
À défaut une réparation du polygone en polygone papillon permettrait à des outils comme PostGIS de fonctionner correctement.

Signalement utilisateur (email)

Ce message ne concerne que les données EDIGEO Lambert 93 des millésimes 2017-10-12 et 2018-01-02.

Sur le millésime 2017-10-12:
Les feuilles suivantes sont incomplètes (archive vide ou fichier .thf manquant):
151120000D02
13036000DL01
77327000ZS01
391030000F01

Sur le millésime 2018-01-02:
Les feuilles suivantes sont incomplètes (archive vide ou fichier .thf manquant):

151120000D02
13036000DL01
77327000ZS01
391030000F01

(Ces archives semblent être correctes sur le millésime 2017-10-12)
59391000ZC01
593910000B02
59391000ZD01
593910000C03
59391000ZI01
59391000ZB01
59391000ZE01
59391000ZH01
59271000AA01
594020000A08
59256000AB01
59256000AI01
59256000AH01
59256000AD01
59256000AE01
59183460AO01
594750000A03
596660000B03
593400000A09
595790000B01
59153000AD01
594780000C02
594780000D02
591500000A02
59650000BP01
59512000AM01
593970000A03
593200000A02
593200000A08
596060000M01
593870000B01
59172000AC01
59092000ZC01
590920000C04
590920000B03
590920000D06
590920000C01
59092000ZA01
595860000A09
59447000ZE01
59589000ZA01
59589000ZE01
59589000ZB01
59589000ZC01
59589000ZH01
59589000ZI01
59564000AL01
59564000AE01
59564000AM01
59131000AE01
59359000AT01
59653000AR01
59592000AE01
591230000C05
595881540B03
595880000B12
13023000BC01
63207000AX01

Cf datagouv/cadastre.data.gouv.fr#48

Actuellement la géométrie d'une commune est écrite à chaque fois qu'une planche de cette commune est rencontrée.
Il faudrait gérer leur unicité par département.

Constaté dans le GeoJSON des sections sur le département 59 : le code section n'est pas toujours cohérent avec l'id renseigné.

Exemple sur 3 sections de 3 communes différentes :

{"id":"590440000A","code":"0A","created":"2003-06-13","updated":"2014-03-04"}
{"id":"590410000A","code":"A","created":"2014-10-29","updated":"2014-10-29"}
{"id":"590650000A","code":"OA","created":"2003-03-19","updated":"2014-03-04"}

Sondage en cours :
https://twitter.com/jdesboeufs/status/988349006236585984

Doit-on maintenir l'archivage *.tar.bz2 tel que fournit par la DGFiP.
Quel est la livraison habituelle ? À quoi sont habitué les communes et leurs prestataires ?

Bonjour,

Il manque la propriété "contenance" dans pas mal de commune du département 67, par exemple la commune 67119 et la propriété type dans pas mal de commune du même département.

J'ai fait un script pour importer toutes les données vers une bdd postgis, je suis obligé de zapper tout le département pour éviter ces problèmes.
https://github.com/PierreNansot/cadastre-scripts

Peut-être que l'information manque dans vos fichiers edigeo. Il faudrait au moins rajouter la propriété avec une var null ou simplement 0.

J'ai aussi tenté de scripter directement à partir des fichiers départementaux, sans succès. Je fais du 25000 entité par 25000 pour ne pas y passer la semaine mais le script finit par sauter. J'ai pas encore creuser pourquoi mais ça ne métonnerait pas qu'on retrouve ce même problème d'inconsistence.

Merci pour ces données en tout cas !

Je recopie un retour utilisateur :

Lors du montage des couches JSON du PCI de Janvier (dept 973), je me suis aperçu qu’il y avait des « trous » :

Classe PARCELLE :
Nous n’avons pas fait d’analyse détaillée mais il s’agit sans doute des communes 97352 – SAUL et (une partie de) 97306 – MANA.

Il y a du avoir un problème au niveau des très grandes parcelles qui ne sont pas les seules à ne plus exister.

En fond vert la couche de janvier, en contour rouge celle d’octobre :

Lorsque l'on décompresse une archive département au format EDIGÉO, un dossier racine avec le numéro de commande cadastre.gouv.fr est créé.

Inutile et peu pratique pour automatiser (le nom changera entre les livraisons).
Par ailleurs la présence d'un caractère accentué génère des problèmes sur certains outils.

Bonjour,

Je viens de faire un tour dans les données raw (niveau commune). Ce sont des données intéressantes. En l'état, elles sont parfaitement exploitables en concaténant les champs et en faisant des étiquettes. Python permet de faire pas mal de mise en forme assez facilement pour cela.
Le problème est le suivant: on a un besoin pour plus de 2500 communes. Et derrière un proxy d'entreprise, il est très compliqué pour moi de récupérer toutes les communes.
Pensez-vous faire ces jeux de données à l'échelle d'un département ?

Merci encore pour tous vos efforts.

Actuellement les lots EDIGÉO sont organisés exclusivement par département.
Il est difficile pour certains utilisateurs qui se fournissaient habituellement auprès des DDFiP ou DRFiP d'identifier les fichiers concernant leur commune d'étude.

Une approche serait de proposer une organisation des lots par commune, dans des dossiers à l'intérieur de l'archive.

Ajout d'un fichier lieux-dit pour chaque commune et chaque département.

Dans certains cas il est intéressant de ne récupérer qu'un seul lot EDIGÉO, pour affichage dans un outil. La packaging par département parait inadapté pour cet usage (volume à télécharger, nécessité de mettre en place un service intermédiaire).

Bonjour,
Une interrogation qui n'est pas forcément une 'issue':
Quelle est l'origine due la date du champ 'created' dans les parcelles ?
On trouve des dates très anciennes (en 1919 par exemple) et des dates plus récentes. S'agit-il de la date d'apparition de la parcelle dans les matrices, de la date de l'acte ? Cette date est-elle fiable ? Peut-on l'utiliser pour faire une recherche d'acte ou de titres dans des archives ?
Merci,

http://www.strasbourg.eu/ma-situation/professionnel/open-data/donnees/referentiel-geographique-open-data/bd-ref-2000

À intégrer dans les fichiers diffusés par Etalab.

Actuellement il faut télécharger une commune pour récupérer une planche unique.
Pour l'utilisation dans certains outils (comme JOSM), il semble pertinent de pouvoir ne récupérer que ce dont on a besoin (par rapport à sa zone de travail).

Le dépôt https://github.com/etalab/cadastre-builder-api réutilise une partie du code fs et codes tout en divergeant un peu.
Il faudrait mutualiser ce code.

Actuellement le lien entre un bâtiment et ses parcelles support n'est pas explicité dans les attributs.
Il peut habituellement être recréé géographiquement.

Néanmoins le lien sémantique existe dans les données du PCI Vecteur, et est probablement plus fiable que l'analyse géographique.

La métropole de Strasbourg a ouvert ses données cadastrales brutes, sans simplification.
Ces données doivent être intégrées à la place dans anciennes.

https://www.data.gouv.fr/fr/datasets/donnees-cadastrales-de-leurometropole-de-strasbourg/

Bonjour,
Nous avons quelques soucis avec la dernière livraison EDIGEO. J'aimerais savoir si les changements ci-dessous sont une régression de votre chaîne de traitement ou si les changements sont liés à des changements de structure du coté de la DGFIP.
Pour référence: (#39)

Les feuilles suivantes étaient corrompues (le THF, pas l'archive) en release 2018-01-02 et le sont toujours en release 2018-04-03 :
391030000F01.tar.bz2
77327000ZS01.tar.bz2

Les feuilles suivantes étaient fonctionnelles en release 2018-01-02 mais pas dans la release 2018-04-03:
edigeo-13002000DS01.tar.bz
edigeo-13002000HK01.tar.bz
edigeo-13002000DC01.tar.bz
edigeo-13002000DK01.tar.bz
edigeo-132028100K01.tar.bz
edigeo-132038120E01.tar.bz
edigeo-132108560C01.tar.bz
edigeo-132118680D01.tar.bz
edigeo-132118650I01.tar.bz
edigeo-132118670I01.tar.bz
edigeo-132128750R01.tar.bz
edigeo-132128750P01.tar.bz
edigeo-132128750N01.tar.bz
edigeo-132128750M01.tar.bz
edigeo-132128750S01.tar.bz
edigeo-132128750O01.tar.bz
edigeo-132128780O01.tar.bz
edigeo-132128750T01.tar.bz
edigeo-132128720A01.tar.bz
edigeo-132138790H01.tar.bz
edigeo-132138790E01.tar.bz
edigeo-132148900E01.tar.bz
edigeo-132148930D01.tar.bz
edigeo-132159000D01.tar.bz
edigeo-132169110C01.tar.bz
edigeo-491550000B05.tar.bz
edigeo-492050000D02.tar.bz

Les feuilles suivantes sont présentes dans la release 2018-01-02 mais elles sont absentes de la release 2018-04-03:
edigeo-10403000ZC10.tar.bz
edigeo-104030000D10.tar.bz
edigeo-13075000AI01.tar.bz
edigeo-14237000ZA09.tar.bz
edigeo-14237000ZB10.tar.bz
edigeo-14237000ZC11.tar.bz
edigeo-173070000C03.tar.bz
edigeo-173070000D01.tar.bz
edigeo-173070000B01.tar.bz
edigeo-173070000E03.tar.bz
edigeo-173070000A01.tar.bz
edigeo-173070000A02.tar.bz
edigeo-173070000D03.tar.bz
edigeo-173070000A03.tar.bz
edigeo-173070000E02.tar.bz
edigeo-173070000D02.tar.bz
edigeo-173070000C01.tar.bz
edigeo-173070000B02.tar.bz
edigeo-173070000E01.tar.bz
edigeo-173070000C02.tar.bz
edigeo-173070000B03.tar.bz
edigeo-19161000OC01.tar.bz
edigeo-19161000OC02.tar.bz
edigeo-21245000ZC01.tar.bz
edigeo-21245000ZB01.tar.bz
edigeo-21408000ZA01.tar.bz
edigeo-221582980A02.tar.bz
edigeo-221582980B01.tar.bz
edigeo-221600000A01.tar.bz
edigeo-24354469CD01.tar.bz
edigeo-24354469AE01.tar.bz
edigeo-26010000AB01.tar.bz
edigeo-26010000ZK01.tar.bz
edigeo-26010000ZD01.tar.bz
edigeo-26010000ZP01.tar.bz
edigeo-28022000ZN01.tar.bz
edigeo-28128000ZB01.tar.bz
edigeo-28154000ZK01.tar.bz
edigeo-28154000ZD01.tar.bz
edigeo-28154000ZL01.tar.bz
edigeo-28324000ZK01.tar.bz
edigeo-290210000C01.tar.bz
edigeo-290210000A02.tar.bz
edigeo-290620000A01.tar.bz
edigeo-291610000C02.tar.bz
edigeo-300920000B01.tar.bz
edigeo-300920000C01.tar.bz
edigeo-300920000A01.tar.bz
edigeo-30092000AB01.tar.bz
edigeo-314900000B02.tar.bz
edigeo-314900000B01.tar.bz
edigeo-314900000E02.tar.bz
edigeo-314900000A01.tar.bz
edigeo-314900000F01.tar.bz
edigeo-314900000D01.tar.bz
edigeo-314900000E01.tar.bz
edigeo-315920000H01.tar.bz
edigeo-315920000I02.tar.bz
edigeo-315920000H03.tar.bz
edigeo-315920000J05.tar.bz
edigeo-315920000J03.tar.bz
edigeo-315920000I01.tar.bz
edigeo-315920000J02.tar.bz
edigeo-315920000H07.tar.bz
edigeo-315920000H02.tar.bz
edigeo-315920000J04.tar.bz
edigeo-353380000C02.tar.bz
edigeo-353380000A01.tar.bz
edigeo-353380000D02.tar.bz
edigeo-353380000B01.tar.bz
edigeo-360970000B02.tar.bz
edigeo-360970000A02.tar.bz
edigeo-390400000B03.tar.bz
edigeo-390400000A01.tar.bz
edigeo-441190000D01.tar.bz
edigeo-441190000E01.tar.bz
edigeo-441190000F02.tar.bz
edigeo-441660000E04.tar.bz
edigeo-441660000G03.tar.bz
edigeo-441660000E02.tar.bz
edigeo-441660000G01.tar.bz
edigeo-44166000AB01.tar.bz
edigeo-442010000C01.tar.bz
edigeo-442010000C02.tar.bz
edigeo-442010000C03.tar.bz
edigeo-442010000C05.tar.bz
edigeo-442010000C04.tar.bz
edigeo-530220000E03.tar.bz
edigeo-53034000ZS01.tar.bz
edigeo-53054000ZM01.tar.bz
edigeo-53054000ZO01.tar.bz
edigeo-53054000ZL01.tar.bz
edigeo-531580000A01.tar.bz
edigeo-53201000ZA01.tar.bz
edigeo-53201000ZO01.tar.bz
edigeo-561820000K01.tar.bz
edigeo-561820000K02.tar.bz
edigeo-561820000K03.tar.bz
edigeo-56182000AB01.tar.bz
edigeo-591680000D03.tar.bz
edigeo-604940000A01.tar.bz
edigeo-614080000G01.tar.bz
edigeo-614080000D01.tar.bz
edigeo-614080000E01.tar.bz
edigeo-614080000C01.tar.bz
edigeo-614080000A01.tar.bz
edigeo-614080000F01.tar.bz
edigeo-614080000B01.tar.bz
edigeo-622420000B03.tar.bz
edigeo-62644000ZB01.tar.bz
edigeo-70179000YA01.tar.bz
edigeo-701790000A01.tar.bz
edigeo-70179000AC01.tar.bz
edigeo-701790000B02.tar.bz
edigeo-701790000C02.tar.bz
edigeo-701790000C01.tar.bz
edigeo-701790000B01.tar.bz
edigeo-711890000B04.tar.bz
edigeo-721690000E05.tar.bz
edigeo-741170000C51.tar.bz
edigeo-741170000C61.tar.bz
edigeo-804310000E01.tar.bz
edigeo-808340000C01.tar.bz
edigeo-808340000B02.tar.bz
edigeo-808340000B01.tar.bz
edigeo-831530000A01.tar.bz
edigeo-85034000YB01.tar.bz
edigeo-85034000YA01.tar.bz
edigeo-85034000YV01.tar.bz
edigeo-85034000YX01.tar.bz
edigeo-850970000G01.tar.bz
edigeo-860530000G01.tar.bz
edigeo-860530000E01.tar.bz
edigeo-86053000XD01.tar.bz
edigeo-860530000E03.tar.bz
edigeo-860740000B02.tar.bz
edigeo-860740000A21.tar.bz
edigeo-861660000D11.tar.bz
edigeo-862390000B02.tar.bz
edigeo-862390000D03.tar.bz
edigeo-862390000A02.tar.bz
edigeo-862390000D01.tar.bz
edigeo-862390000D02.tar.bz
edigeo-862390000A01.tar.bz
edigeo-862390000C01.tar.bz
edigeo-862390000B01.tar.bz
edigeo-912040000B01.tar.bz

Plusieurs couches extraites du PCI Vecteur, bien que non finalisées et expérimentales, peuvent être utilisées dans d'autres chaînes de traitement.

Il serait intéressant de les conserver sous forme d'artefacts.

En priorité :

• numeros-voie
• voies

Actuellement le traitement est parallélisé à la commune, mais le script attend que le département en cours se termine avant d'attaquer le suivant.

Lorsqu'en fin de département on a des communes complexes à extraire (grandes surfaces forestières, montagneuses ou agricoles, ou forte urbanisation), les autres processus attendent.

Le traitement actuel prend plus d'une heure.
Sur une machine avec 8 coeurs il pourrait tomber à une dizaine de minutes.

Remontée beta-testeur :

En ce qui concerne les identifiants des parcelles, j’ai trouvé 237 doublons dont un mauvais ID qui correspond à 8 lignes (04null):

04null
361070000A3140
361070000A3141
361200000C1495
361070000A3185
862530000B0001
862530000B0005
862530000B0006
862530000B0037
862530000B0038
862530000B0039
862530000B0042
862530000B0044
862530000B0045
862530000B0079
862530000B0080
862530000B0081
862530000B0082
862530000B0088
862530000B0491
862530000B0492
862530000B0519
862530000B0544
862530000B0545
041990000D0428
041990000D0429
100550000A0006
100550000A0007
100550000A0008
100550000A0009
100550000A0010
100550000A0011
100550000A0012
100550000A0013
100550000A0014
100550000A0015
100550000A0017
100550000A0019
100550000A0024
100550000A0042
100550000A0043
100550000A0044
100550000A0053
100550000A0068
100550000A0069
100550000A1148
100550000A1149
100550000A1150
100550000A1151
100550000A1152
100550000A1154
100550000A1155
100550000A1156
100550000A1158
100550000A1159
100550000A1163
100550000A1164
100550000A1165
100550000A1171
100550000A1173
100550000A1174
100550000A1177
100550000A1180
100550000A1181
100550000A1182
100550000A1185
100550000A1186
100550000A1189
100550000A1190
100550000A1211
100550000A1213
100550000A1221
100550000A1222
100550000A1223
100550000A1224
100550000A1231
100550000A1236
100550000A1237
100550000A1242
100550000A1243
100550000A1244
100550000A1247
100550000A1248
100550000A1250
100550000A1251
100550000A1293
100550000A1298
100550000A1299
100550000A1300
100550000A1301
100550000A1302
100550000A1303
100550000A1304
100550000A1305
100550000A1324
100550000A1330
100550000A1361
100550000A1364
100550000A1366
100550000A1369
100550000A1370
100550000A1374
112910000A0708
122690000C0664
163100000D1106
164240000A0811
164240000A0812
220140000A0771
220140000A0773
220140000A0774
220140000A0775
220140000A0776
220140000A0778
220140000A0779
220140000A0780
220140000A0781
220140000A0782
220140000A0783
220140000A0784
220140000A0785
220140000A0787
220140000A0788
220140000A1041
220140000A1071
220140000A1114
220140000A1115
220140000A1116
220140000A1192
220140000A1193
220140000A1206
220140000A1207
220140000A1478
220140000A1479
220140000A1480
220140000A1481
220140000A1482
220140000A1483
220140000A1485
220140000A1504
220140000A1505
220140000A1506
220140000A1533
220140000A1534
220140000A1535
220140000A1536
292670000B0795
312010000A0608
400500000B0728
400500000B0729
400500000B0730
400500000B0731
531900000C1181
581400000F0747
626460000A0488
626460000A0489
626460000A0490
626460000A0491
626460000A0492
626460000A0493
626460000A0494
626460000A0495
626460000A0496
626460000A0497
626460000A0498
626460000A0499
626460000A0500
626460000A0501
626460000A0502
626460000A0503
626460000A0505
626460000A0506
626460000A0507
626460000A0509
626460000A0511
626460000A0596
626460000A0597
626460000A0598
626460000A0599
626460000A0600
626460000A0601
626460000A0603
626460000A0604
626460000A0605
626460000A0606
626460000A0608
626460000A0609
626460000A0610
626460000A0611
626460000A0612
626460000A0613
626460000A0614
626460000A0615
626460000A0616
626460000A0622
626460000A0623
626460000A0624
626460000A0625
626460000A0626
626460000A0627
626460000A0661
626460000A0689
626460000A0692
626460000A0693
626460000A0894
62861000AB0123
62861000AB0135
644270000A0769
710710000C0155
710710000C0156
710710000C0157
710710000C0165
710710000C0166
710710000C0183
710710000C0184
710710000C0196
710710000C0198
710710000C0199
710710000C0200
710710000C0213
710710000C0214
710710000C0216
710710000C0217
710710000C0269
710710000C0284
740850000C0744
742760000E0327
762380000B1492
772440000E0975
773590000B0035
773590000B0038
773590000B0043
773590000B0044
773590000B0778
773590000B0779
773590000B0782
773590000B0783
773590000B0784

Ajout les lieux-dits issus du cadastre dans la livraison Etalab.
Pas de rapprochement FANTOIR pour cette première passe.

Le nom de la commune 44041 (La Chevrolière) est manquant.
Il est aussi manquant dans le PCI.

1. Ne plus ranger les communes dans les départements :

departements/XX/communes/YYYYY/ZZZZZ.json.gz => communes/YYYYY/ZZZZZ.json.gz

2. Et un dossier différent pour chaque mode :

geojson-default et geojson-raw

Bonjour,
j'ai vu que vous avez créé vos propres parser edigeo et je souhaite savoir pour quelle raison, en sachant que gdal, via le binding nodeJs proposé ici, fait très bien l'affaire et propose mêmes plusieurs formats vectoriels en entrée et en sortie (je pense même qu'il serait possible de rasteriser les données vectorielles).

Bien que les sections et les feuilles ne soient pas parfaitement calées les unes par rapport aux autres, on s'attend néanmoins à une couverture pleine, hors domaine public.

Sur le département de l'Indre, le rendu laisse présager quelques anomalies dans les données.

À investiguer.

Bonjour,

Merci pour le gros travail que vous faites sur le cadastre!
J'ai remarqué que pour pas mal de nouveaux développements, les bâtiments sont sur une subdivision fiscale, dans une très grande parcelle cadastrale, pensez vous qu'il soit possible de récupérer les subdivisions sur le cadastre?

Merci!

Lorsque la fusion par département est appelée sur Paris (75), elle ne se termine jamais car elle essaie de regrouper les lieux-dits de toutes les communes.
Or, il n'y a pas de lieux-dits à Paris.
Le script devrait être capable de traiter ce cas particulier.

Saint-Martin :

Saint-Barthelemy :

Bonjour et bravo pour tout le travail que vous menez autour de ce thème du cadastre.

Même si la topologie des données est plus qu'aléatoire, il pourrait être intéressant de mettre à disposition un assemblage national des données administratives dérivées du cadastre : limites de communes et de sections, voire limite des communes anciennes.

Je m'apprêtais à le faire dans le cadre d'un projet de cartographie des "communes anciennes".
En effet, on peut retrouver leur périmètres grace aux références des identifiants de sections cadastrales (en lien avec cette issue #21 )

Comme je suppose que vous avez accès aux données à l'échelle nationale, peut-être ce traitement serait-il plus rapide à lancer de manière centralisée ? (plutôt que nous lancions ce genre d'assemblages après avoir téléchargé les données de tous les départements)

Informations intéressantes à extraire :

• Liste des parcelles d'une section non vectorisée
• Localisation du centre des parcelles quand c'est possible