Bonjour,
je me heurte à une difficulté et je me dis que je ne suis peut-être pas le premier, aussi je viens chercher un peu de retour éventuel de votre part.
Je cherche à rattacher chaque autorisation d’urbanisme de Sitadel à sa (ou ses) parcelles cadastrales, avec une jointure attributaire (Sitadel n’ayant pas de géométrie).
L’idu parcellaire DGFiP (14 car.) se décompose en :
code_insee (5) + préfixe (3) + section (2) + n° de plan (4)
- Le préfixe (3 chiffres, dit préfixe de section / code de l’ancienne commune) vaut
000pour la grande majorité des communes, mais ≠ 000 dès qu’une commune en a absorbé une autre. - Pour Paris/Lyon/Marseille (PLM), le
code_inseede l’idu est celui de l’arrondissement (13201–13216, 69381–69389, 75101–75120), et le préfixe encode le quartier / l’ancienne commune. - Exemple réel (Marseille) :
132018010A0403= arrondissement13201+ préfixe801+ section0A+ n°0403.
Or Sitadel ne fournit, pour localiser le terrain, que :
COMM= code commune officiel (COG). Pour Marseille c’est13055, pour Paris75056— jamais l’arrondissement.SEC_CADASTRE1..3/NUM_CADASTRE1..3= section + numéro de la (des) parcelle(s), renseignés à ~96,6 %.- Aucun champ préfixe ni arrondissement.
Or l’idu cadastral PLM a besoin de l’arrondissement ET du préfixe , tous deux absents de Sitadel. On ne peut donc pas reconstruire l’idu par simple assemblage pour PLM. Pour les communes standard (préfixe 000 ), l’assemblage COMM + '000' + section + numéro fonctionne — c’est bien PLM (et, marginalement, les communes ayant absorbé d’autres communes) qui posent problème. Pour Paris et Lyon , le code postal du terrain donne l’arrondissement (mapping 1:1), et (arrondissement, section, numéro) est unique à 100 % (préfixe 000 uniforme) : on a donc une résolution déterministe. Mais pas pour Marseille…
En repliant toutes les parcelles des 16 arrondissements de Marseille sur la commune officielle 13055 et en regroupant par (section, numéro), voici ce qu’on observe :
| Variable | Valeur |
|---|---|
| Parcelles Marseille (cadastre) | 126 200 |
| Clés (section, numéro) distinctes | 11 200 |
| Clés uniques (→ 1 seule parcelle) | 2 943 (26 %) |
| Clés en collision (→ ≥2 parcelles) | 8 257 |
| Parcelles dans une clé ambiguë | 123 257 (97,7 %) |
| Pire cas observé : clé 0C/0034 | 79 idus distincts |
Donc (commune officielle, section, numéro) est non identifiant à ~98 % à Marseille.
Plus surprenant : la collision persiste même à l’intérieur d’un seul arrondissement à Marseille (à cause des préfixes de section, qui encodent les 111 quartiers de Marseille !) :
| Arrondissement | Parcelles | Clés (sec, n°) |
Collisions |
|---|---|---|---|
| Marseille 13201 | 4 374 | 1 781 | 1 116 |
| Marseille 13208 | 9 833 | 3 724 | 2 288 |
| Paris 75108 | 3 239 | 3 239 | 0 |
| Lyon 69382 | 2 530 | 2 530 | 0 |
Par conséquent, à Marseille, même en connaissant l’arrondissement (via le code postal), (arrondissement, section, numéro) reste ambigu à ~79 % (les préfixes réutilisent les mêmes sections/numéros). Sitadel ne portant pas le préfixe, l’idu marseillais n’est pas reconstructible par attribut.
La manière dont j’essaie de résoudre ce problème : je procède au géocodage de l’adresse → point → point-dans-polygone parmi les parcelles candidates de l’arrondissement partageant (section, numéro) . ~70 % des permis peuvent être rattachés ainsi.
Est-ce que vous connaissiez ce problème ? Avez identifié d’autres solutions ?
Merci d’avance !