Evolution des codes INSEE des territoires

[bchartier]

Au niveau de GéoPicardie nous sommes confrontés à un souci ennuyeux : l'évolution des codes insee des communes à la suite de fusions notamment. Les codes INSEE définis dans les fichiers fonciers sont ceux en date du millésime en question alors que ceux définis dans la carte des territoires de compétence sont ceux valables au moment où la requête d'extraction est lancée. Dans le cas d'une fusion, l'un des 2 codes INSEE disparaît. Le territoire des 2 anciennes communes, pour ldapadmin en tout cas, n'est plus connu que par un seul code INSEE. L'ancien code INSEE n'est pas présent dans la carte des territoires de compétence de ldapadmin. Il en résulte que les fichiers fonciers correspondant à l'ancien code INSEE ne peuvent plus être requêtés par l'extracteur de fichiers fonciers.

Nous réfléchissons donc à trouver une solution pour corriger cela. Deux solutions ont traversé nos esprits fertiles (si si) :

• modifier les codes insee dans la base des fichiers fonciers. Cette solution se heurtera probablement à des problèmes d'unicité et posera un problème car elle dénaturera les données. A éviter autant que possible.
• enrichir l'application de tables de correspondance qui permettraient d'indiquer quels codes INSEE actuels correspondent à quels codes INSEE pur chaque millésime. Cette solution est sans doute préférable et pourrait sans doute profiter à d'autres applications de geOrchestra. Se posera alors sans doute la question du meilleur endroit où intégrer ces tables de correspondance : directement sous le contrôle de l'appli "foncier" ou ailleurs.

[severo]

Le même besoin existe en Bolivie (et dans tous les pays j'imagine) : comment modéliser l'historique et la généalogie des territoires.

[bchartier]

Le même besoin existe en Bolivie (et dans tous les pays j'imagine) : comment modéliser l'historique et la généalogie des territoires.

Il existe peut-être des projets pour donner des éléments de réponse à ce problème pour la France (projets d'Etalab) :

• GeoZones : https://github.com/etalab/geozones
• GeoHisto : https://github.com/etalab/geohisto GeoZones n'est pas spécifique à la France.

Je n'ai pas eu le temps de les regarder pour voir si ça peut faire avancer les choses dans la bonne direction. Si ça fait avancer les choses il y a peut-être moyen d'adapter cela au cas Bolivien.

[landryb]

C'est un problème classique, il faut faire évoluer ta table de référence des codes insee (ie celle utilisée par la console) et la mettre à jour régulièrement. J'imagine que tout le monde utilise maintenant adminexpress, qui à remplacé geofla.. et qui est mise à jour tous les mois.

A chaque évolution, il faut du coup corriger les codes insee 'disparus' et les remplacer à gauche à droite... ici on le fait environ une fois par an, souvent ca coincide avec la mise à dispo des fichiers majic.

Je ne vois pas de solution parfaite à ce souci sans faire une usine à gaz, car tu n'auras jamais de correspondance parfaite à un instant T entre la liste des communes au sens de l'ign/du COG, au sens des impots pour le PCI, au sens des impots pour MAJIC, et que sais-je encore.. l'insee ?

Si tu as 3 données distinctes à mettre à disposition, et que dans une de ces 3 tu as encore des données pour un code insee 'disparu', tu ne peux pas considérer que si ce code insee est demandé, il faut obligatoirement le mapper vers 'le nouveau'. L'autre solution est de rassembler les données du code disparu avec celles du nouveau dans une archive correspondant au nouveau code (c'est ce que l'on a fait localement pour des incohérences dans le PCI)

[bchartier]

Merci pour ton avis détaillé sur la question.

C'est un problème classique, il faut faire évoluer ta table de référence des codes insee (ie celle utilisée par la console) et la mettre à jour régulièrement. J'imagine que tout le monde utilise maintenant adminexpress, qui a remplacé geofla.. et qui est mise à jour tous les mois.

[GEOFLA n'a pas encore disparu mais effectivement ADMIN EXPRESS (tiens, s'ils pouvaient arrêter de mettre des majuscules partout à l'IGN...) est plus intéressant et c'est ce qui est utilisé (après simplification des géométries) sur les plateformes que je suis.]

A chaque évolution, il faut du coup corriger les codes insee 'disparus' et les remplacer à gauche à droite... ici on le fait environ une fois par an, souvent ca coincide avec la mise à dispo des fichiers majic.

Les bases des communes utilisées pour définir les territoires de compétence sont à jour au niveau de geOrchestra. Ça se fait assez bien. Les administrateurs des données des plateformes sont vigilants de ce côté-là.

Je ne vois pas de solution parfaite à ce souci sans faire une usine à gaz, car tu n'auras jamais de correspondance parfaite à un instant T entre la liste des communes au sens de l'ign/du COG, au sens des impots pour le PCI, au sens des impots pour MAJIC, et que sais-je encore.. l'insee ?

Ce que nous envisagions de faire (la seconde solution identifiées dans mon message initial) est juste d'avoir une table de correspondance entre les codes INSEE actuels et les codes INSEE de telle et telle année. Je comprendrais que ce soit perçu comme une usine à gaz dans le sens où c'est une complexité dont on préfèrerait se passer. Néanmoins, j'imagine que ce serait très utile pour les collectivités qui manipulent sans cesse ce genre d'information.

Si tu as 3 données distinctes à mettre à disposition, et que dans une de ces 3 tu as encore des données pour un code insee 'disparu', tu ne peux pas considérer que si ce code insee est demandé, il faut obligatoirement le mapper vers 'le nouveau'. L'autre solution est de rassembler les données du code disparu avec celles du nouveau dans une archive correspondant au nouveau code (c'est ce que l'on a fait localement pour des incohérences dans le PCI)

C'est une reformulation de la première solution évoquée dans mon message initial. Elle à l'inconvénient de devoir modifier les données avec les risques ou inconvénients suivants :

• les données ne sont plus conformes aux spécifications du producteur entrainant ainsi la possibilité d'une exploitation erronée des données (si tant est que l'utilisateur normal prend connaissance des spécifications du produit et qu'il a conscience du problème d'évolution des codes INSEE)
• possibilité de rencontrer des problèmes de cohérences de la base de données (identifiant non unique)