Annonce
L'appel à participation est ouvert jusqu'au 19 janvier 2025!
Pages: 1
- Sujet précédent - utilisation comme référentiel pivot du code Insee des communes - Sujet suivant
#1 Mon 30 November 2020 14:29
- BDavid
- Participant occasionnel
- Lieu: Paris, France
- Date d'inscription: 24 Nov 2008
- Messages: 40
utilisation comme référentiel pivot du code Insee des communes
Bonjour,
En lien avec les travaux de l'Insee (https://api.insee.fr/) et de la Dinum (https://geo.api.gouv.fr/), je vous fais part d'une réflexion et d'un prototype de référentiel communal historique.
L'objectif est d'améliorer l'utilisation comme référentiel pivot du code Insee des communes.
Pourquoi ce projet ?
De nombreuses bases de données, appelées par la suite bases métier, par exemple des bases de décisions administratives, utilisent le code Insee des communes pour géoréférencer leur contenu, c'est à dire, dans l'exemple, chaque décision administrative.
Or, ces codes Insee évoluent, notamment en raison de la volonté de réduire le nombre de communes, par fusion de communes et par création de communes nouvelles.
Pour en tenir compte, ces codes devraient donc être modifiés dans les bases métier.
Cependant ces modifications ne sont généralement pas effectuées et en conséquence les codes Insee ainsi contenus dans ces bases perdent leur signification car ils ne peuvent plus être croisés avec un référentiel à jour des communes, comme le code officiel géographique (COG) de l'Insee, ou une base géographique IGN, comme Admin-Express.
Finalement, ils ne remplissent plus leur fonction de géoréférencement.
Or, sur le fond, le code Insee d'une commune abrogée, par exemple fusionnée, reste un localisant à condition de disposer de l'historique des codes Insee.
De plus, il peut être dans certains cas préférable dans une base de conserver un code Insee périmé car le géoréférencement peut être plus précis et peut redevenir valide en cas de rétablissement.
La conservation du code périmé dans la base évite ainsi des erreurs ou des approximations de géoréférencement.
Enfin, il n'existe pas de méthode simple et fiable pour actualiser dans une base métier un référentiel comme celui des communes.
Par exemple, si une commune est soumise à une réglementation et qu'elle fusionne avec une autre qui ne l'est pas, il est impossible de conserver l'information en gérant l'information au niveau des communes.
Proposition
La présente proposition consiste donc à créer un nouveau référentiel, appelé "Référentiel communal historique simplifié" (ComHisto), contenant tous les codes INSEE des communes ayant existé depuis le 1/1/1943 et leur associant les versions successives géoréférencées permettant de retrouver l'état de l'entité à une date donnée.
Ainsi les codes Insee intégrés dans une base après le 1/1/1943 restent valables et peuvent être utilisés, par exemple pour géocoder l'information ou pour la croiser avec un référentiel à jour des communes, à condition cependant de conserver dans la base métier la date de validité du code Insee utilisé.
Plus d'infos sur https://github.com/benoitdavidfr/comhisto
Benoit DAVID
Hors ligne
#2 Tue 01 December 2020 15:15
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3199
- Site web
Re: utilisation comme référentiel pivot du code Insee des communes
Bonjour,
Une très bonne idée.
Ceci dit plusieurs remarques.
Géoréférencer un document, une commune étant un multi-polygone (n'oubliez pas les îles 
) quel référentiel allez vous choisir ?
Le cadastre dispo sur data.gouv.fr permet grâce à l'attribut IDU de l'objet subsection d'obtenir le code insee, le code de commune fusionnée et la géométrie.
Ensuite et ce n'est pas relatif au projet, utiliser un attribut comme clef primaire d'un objet c'est vraiment pas une bonne pratique.
Dans nos bases métier la commune id : 321678 reste la commune 321678 et s'il lui prend l'envie de fusionner avec 456789 pas grave la nouvelle commune 654852 en sera le résultat et chacun conserve son numéro insee d'origine, le fusionné d'origine, et la nouvelle ben un nouveau il a même le droit de changer de formatage ... Et en matière de commune et de document, nos bases gèrent 240 ans de cadastre et les fusion acquisitions, les changements de limites, il y en a eu quelques unes ... Imaginez si nos bases dépendait des décisions administratives !!! Faut être un peu sérieux quand on fait ce genre de choses, avec humour, certes, mais sérieux tout de même.
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#3 Wed 02 December 2020 18:35
- BDavid
- Participant occasionnel
- Lieu: Paris, France
- Date d'inscription: 24 Nov 2008
- Messages: 40
Re: utilisation comme référentiel pivot du code Insee des communes
Une très bonne idée.
Ceci dit plusieurs remarques.
Merci.
Géoréférencer un document, une commune étant un multi-polygone (n'oubliez pas les îles
Le cadastre dispo sur data.gouv.fr permet grâce à l'attribut IDU de l'objet subsection d'obtenir le code insee, le code de commune fusionnée et la géométrie.
Un objectif que je n'ai pas mentionné est de disposer d'un référentiel national pas trop lourd.
J'ai donc utilisé Admin-Express COG dont j'ai simplifié la géométrie avec une résolution de 100 mètres.
Les communes sont bien décrites comme des multi-polygones. Le référentiel produit zippé en GéoJSON pèse environ 6 Mo.
Il serait aussi intéressant, sur le même principe, de construire une base versionnée des parcelles du cadastre, mais c'est un autre chantier.
Je crois que la Dinum y réfléchit.
Ensuite et ce n'est pas relatif au projet, utiliser un attribut comme clef primaire d'un objet c'est vraiment pas une bonne pratique.
Dans nos bases métier la commune id : 321678 reste la commune 321678 et s'il lui prend l'envie de fusionner avec 456789 pas grave la nouvelle commune 654852 en sera le résultat et chacun conserve son numéro insee d'origine, le fusionné d'origine, et la nouvelle ben un nouveau il a même le droit de changer de formatage ...
C'est un débat permanent mais j'ai considèré que le code Insee est une bonne clef pour les communes et, de plus, c'est le moyen normalement utilisé pour les désigner ; en ajoutant une date de début de version on obtient une bonne clef pour la version.
Et en matière de commune et de document, nos bases gèrent 240 ans de cadastre et les fusion acquisitions, les changements de limites, il y en a eu quelques unes ... Imaginez si nos bases dépendait des décisions administratives !!! Faut être un peu sérieux quand on fait ce genre de choses, avec humour, certes, mais sérieux tout de même.
Je ne comprend pas cette remarque.
Je suppose que l'on n'a pas le même type de décision administrative en tête.
J'avais en tête par exemple les arrêtés préfectoraux définissant les zones de répartition des eaux (au titre de l'article R211-71 du code de l'environnement) par des listes de communes. Ces communes évoluant, la définition des zones peut être mises en cause.
Je recommande de conserver la définition de ces zones par des listes de communes, ce qui est plus simple administrativement, et lorsque l'on veut traduire ces zones en SIG d'effectuer un géocodage des codes Insee en tenant compte de la date de l'arrêté.
Le principe proposé s'applique à toutes les décisions administratives localisées fondées sur le découpage communal et il me semble qu'il y en a un certain nombre dans l'administration.
Cordialement
Benoit DAVID
Hors ligne
#4 Thu 03 December 2020 13:20
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3199
- Site web
Re: utilisation comme référentiel pivot du code Insee des communes
Bonjour,
Il serait aussi intéressant, sur le même principe, de construire une base versionnée des parcelles du cadastre, mais c'est un autre chantier.
Je crois que la Dinum y réfléchit.
https://georezo.net/forum/viewtopic.php … amp;hl=dfi
Qui se couple parfaitement avec les bases confectionnées à partir des données EDiGéo avec ceci :
https://georezo.net/forum/viewtopic.php?id=110313
Pour le code insee vous faites comme bon vous semble, c'est juste un avis, vous gérerez la fusion de commune, les temps de requêtes et l'intégrité des données. Vous dites vous même qu'il évolue, prendre comme clef une chose qui évolue, vous devez faire attention à ce que la serrure évolue de façon synchrone.
Nota l'exemple de suivit des divisions parcelles (premier lien) vous montrera comment gérer l'historique. Car des communes peuvent fusionner mais elle peuvent se diviser aussi, de la même façon leur géométrie peuvent évoluer (sans obligatoirement fusion ou division avec une autre commune).
La structure représentant ce genre de choses est un graphe, le fil DFI permet de voir comment gérer dans une base de données.
Je suppose que l'on n'a pas le même type de décision administrative en tête.
Fusionner deux communes est une décision administrative par exemple, virer la référence à l'acte dans les données DVF aussi, il ne faut rien supposé du producteur de données.
J'ajoute que souvent la simplicité première est lourde de maintenance plus tard. Et si je me permet ces quelques remarques, insistantes, c'est pour vous donner le point de vue d'une équipe qui gère ce genre de choses au quotidien depuis douze ans et sur un gros volume de données. Et j'ajoute que votre projet nous y avons un intérêt, une demande de la DRAC portait chez nous sur le foncier des périmètres des sites classés, les arrêtés géolocalisés déjà à la commune ce serait bénéfique ... (à la parcelle beaucoup mieux) .
Je me fais la voix d'un retour d'expérience en quelque sorte.
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#5 Sat 05 December 2020 18:45
Re: utilisation comme référentiel pivot du code Insee des communes
La démarche me paraît très intéressante. Je vais regarder votre doc.
Hors ligne
#6 Mon 07 December 2020 10:58
- benulti
- Participant assidu
- Lieu: là-bas
- Date d'inscription: 5 Sep 2005
- Messages: 332
Re: utilisation comme référentiel pivot du code Insee des communes
ChristopheV a écrit:Ensuite et ce n'est pas relatif au projet, utiliser un attribut comme clef primaire d'un objet c'est vraiment pas une bonne pratique.
Dans nos bases métier la commune id : 321678 reste la commune 321678 et s'il lui prend l'envie de fusionner avec 456789 pas grave la nouvelle commune 654852 en sera le résultat et chacun conserve son numéro insee d'origine, le fusionné d'origine, et la nouvelle ben un nouveau il a même le droit de changer de formatage ...
C'est un débat permanent mais j'ai considèré que le code Insee est une bonne clef pour les communes et, de plus, c'est le moyen normalement utilisé pour les désigner ; en ajoutant une date de début de version on obtient une bonne clef pour la version.
Bonjour,
ce commentaire me fait réagir. Je ne crois pas qu'il s'agisse d'un débat permanent mais plutôt d'une erreur fréquente… mettre des clés primaires qui ont un sens sémantique pour les métiers et qui sont intimement liées à un objet est une très mauvaise pratique, point de débat sur le sujet.
Nous sommes confronté à ce type de mauvaise pratique sur une base de données (pourtant progiciel du marché) et c'est un bazar à gérer quand les objets évoluent dans le temps, fusionnent ou autre.
Il ne faut pas confondre la vision métier des objets dans une base de données et son modèle "technique".
Cdt
Benoit
Hors ligne
Pages: 1
- Sujet précédent - utilisation comme référentiel pivot du code Insee des communes - Sujet suivant
