Questions L'Oudon et défusions

[antuki]

Bonjour,

Tout d'abord merci pour ce travail sur les géographies communales. Je travaille moi-même sur ces questions depuis une petite année et ai pu développer quelques petits outils pour pouvoir transformer des bases de données d'un COG à un autre. Je suis donc enthousiaste de voir qu'Etalab s'est positionné sur ces questions et je compte donc regarder si vos résultats concordent avec mes propres conclusions.

1. Ma première question concerne la commune de L'Oudon dans le Calvados (14). Il me semble que dans towns.csv, vous identifiez la commune de l'Oudon comme étant codée "14472" du 1973-01-01 00:00:00 au 2016-12-31 23:59:59. Or, en réalisant le même type de travail de mon côté, j'avais noté qu'elle était codée tout d'abord "14697" puis avait changé de code devenant "14472" à partir du 07/01/2014 suite à un transfert de chef lieu (modification Insee = 500) cf. lien ci-dessous : 07/01/2014 : Transfert de chef-lieu de L'Oudon de Tôtes à Notre-Dame-de-Fresnay.
   https://www.insee.fr/fr/metadonnees/cog/commune/COM14472-oudon

2. Une deuxième question concerne deux éléments que j'avais pris en compte moi-même dans mes données et qui semblent être également identifiés sur le site de l'Insee mais qui ne semblent pas être identifiés dans towns.csv. Il s'agit des éléments suivants :

https://www.insee.fr/fr/metadonnees/cog/commune/COM55409-pretz
01/01/1973 : Pretz (55409) est rattachée à Triaucourt-en-Argonne (55517) (fusion association) qui devient Seuil-d'Argonne (55517).
=> Ligne COM55409@1942-01-01 me semble fausse car Pretz est notée comme existant jusqu'en 1989 au lieu de 1973

https://www.insee.fr/fr/metadonnees/cog/commune/COM73024-avanchers
18/07/1972 : Les Avanchers (73024) est rattachée à Aigueblanche (73003) pour donner Aigueblanche (73003) (fusion association).
=> Événement qui ne semble pas être présent dans la table towns

3. Une troisième question concerne la compréhension des variables "ancestors" et "successors" en cas de défusion. Prenons l'exemple de la défusion de Bois-Guillaume-Bihorel (76108) en Bois-Guillaume (76108) et Bihorel (76095) au 01/01/2014.
   Je ne comprends pas pourquoi la ligne identifiée COM76095@2014-01-01 (Bihorel) ne contient pas comme ancestors COM76108@2012-01-01 (Bois-Guillaume-Bihorel).
   Et pourquoi la ligne COM76108@2012-01-01 (Bois-Guillaume-Bihorel) ne contient comme successors que COM76108@2014-01-01 (Bois-Guillaume) mais pas COM76095@2014-01-01 (Bihorel).
   COM76108@2014-01-01 (Bois-Guillaume) contient bien, lui, comme ancestors COM76108@2012-01-01 (Bois-Guillaume-Bihorel) .
   Et cette situation semble être semblable dans tous les cas de défusions. Or, sans cette information, il ne m'a pas pouvoir voir apparaître dans votre table l'évènement indiqué au lien suivant : 01/01/2014 : Bois-Guillaume-Bihorel devient Bois-Guillaume suite au rétablissement de Bihorel.
   https://www.insee.fr/fr/metadonnees/cog/commune/COM76108-bois-guillaume-bihorel

Que pensez-vous de ces deux points ?

Merci pour vos réponses qui me permettront peut-être de voir si je peux intégrer votre travail dans mes outils.

Kim

[davidbgk]

Bonjour Kim,

Merci beaucoup pour ces retours détaillés !

1. la gestion des codes 500 n'est pas (encore ?) réalisée, c'est également le cas d'autres transformations (voir les commentaires sur le fichier en question)

2. il y a en effet un bug à ce niveau là en cas de code 330, je vais créer une issue dédiée et investiguer

3. il s'agit également d'un bug sur le code 210, je vais créer une issue dédiée et investiguer

Pour les futurs cas, ne pas hésiter à faire une issue par groupe de problèmes. Par curiosité, comment les avez-vous identifiés ?

PS : je découvre au passage COGugaison 👍 dommage que je ne sois pas utilisateur de R.

[davidbgk]

La suite sur #42 et #43

[antuki]

Bonjour David,

Tout d'abord merci pour ces réponses rapides !

Pour cadrer un peu l'origine de mes travaux et de mes réflexions :
Dans le cadre de mon job de statisticienne, je suis amenée à utiliser quotidiennement des bases de données communales issues de géographie différentes. Et, pour les comparer entre elles, j'ai été amenée à mener ma propre réflexion sur la manière dont je pouvais faire pour passer une table de donnée d'une géographie à une autre. C'est comme ça que j'ai travaillé à des tables de passage d'un COG à un autre (entre 1968 et 2017 pour le moment). Pour ce faire, j'ai eu besoin d'identifier les fusions et les défusions grâce aux fichiers de l'Insee à partir desquels vous avec pu construire geohisto. Afin de rendre mon travail utile au reste de mon équipe et pourquoi pas à d'autres personnes (c'est l'idée !), j'ai décidé de me lancer dans un package R (logiciel statistique que j'utilise au quotidien) sur github. Ce package COGugaison vient de naître, n'est pas complet en termes de COG et comporte encore des imperfections ! Je n'ai d'ailleurs pas encore commencé à en parler autour de moi, ce qui fait que vous le découvrez en avant-première !

Et pour vous, comment est né le besoin de créer cet outil geohisto ?

Sinon, pour les réponses à vos réponses :

1. Je pense que la gestion du code 500 est utile pour comprendre ce qui est arrivé à la commune de L'Oudon (notamment) et indispensable pour reconstruire l'historique de cette commune. Je peux déjà témoigner en disant que cela me serait utile ! En effet, c'est à partir de la liste des communes à une date précise (a priori pris en compte dans geohisto sauf bugs identifiés) et de l'identification de tous les cas de fusions, de défusions (idem) mais également de changement de codes ou de noms de communes (pas tous identifiés dans geohisto) entre deux dates que le travail de passage d'une table de données d'une géographie à une autre peut être réalisé. Pour tout ce qui est cessation de parcelles, ce sont des cas plus spécifiques qu'il n'est en effet pas nécessaire de traiter dans un premier temps.
   Bref, j'étais donc en train d'analyser si votre travail pouvait contribuer à l'amélioration des tables présentes dans COGugaison mais sans gestion de tous les cas cités précédemment (notamment le 500), je ne pense pas pouvoir entièrement le faire à ce stade et c'est dommage car votre table de données a une forme intéressante qui pourrait m'être très utile (et sûrement pas uniquement à moi !) !

2 et 3) Entendu, bon courage pour la résolution de ces bugs.

Pour répondre à la question de savoir comment j'ai pu identifier ces bugs, c'est justement en comparant la liste des communes à certaines dates de geohisto et de COGugaison que j'ai remarqué ces différences.

PS : Je découvre github depuis peu un peu en autonomie donc il m'arrive peut-être de ne pas poster les bonnes choses au bons endroits (j'en suis encore dans l'apprentissage de ce que sont les issues, les branches, etc !) mais à l'avenir, je penserai à segmenter mes envois ...!

[davidbgk]

Bonjour Kim,

Merci pour ces informations, j'ai l'impression que nos travaux avec la combinaison de geohisto et geozones rejoignent ce besoin. Notre objectif est de pouvoir proposer des zones pertinentes lorsque l'on renseigne des jeux de données sur http://www.data.gouv.fr/fr/ à la fois en terme de géométries et de noms dans le temps. Ce n'est pas encore en production mais j'y travaille à travers la pull-request sur geozones et celle sur udata (qui est le moteur de data.gouv.fr).

Pour l'instant, nous ne gérons que les géométries récentes sans remonter jusqu'à 1968 mais peut-être que nous pourrions combiner nos efforts, au moins dans la recherche des données sources. Nous utilisons principalement les sources issues de OpenStreetMap pour ce qui est du niveau communal.

1. je comprends le besoin, est-ce qu'il est possible de se limiter au code 500 ou est-ce qu'il faut aussi traiter tous les 5XX pour que ce soit pertinent pour vous ?

2. en cours d'investigation, 3 cas on été identifiés correspondant à ce problème

3. le cas a été traité, ce qui correspond à la release 8.1.3

Merci d'avoir pu identifier tout ça, n'hésitez pas à soumettre de nouvelles issues !

PS : OK, pas de soucis :)

[antuki]

Bonjour David,

Merci pour ces informations sur les projets geozones et geohisto. Même si j'ai du mal (à première lecture rapide) à comprendre le mode de fonctionnement du repo geozones. Si l'idée est également de passer d'un niveau commune à un niveau supra-communal (besoin également que j'ai commencé à tenir compte dans COGugaison) que ce soit au niveau bases de données ou shape carto, ces données de l'Insee vous seront peut-être également utiles : Table d'appartenance géographique des communes. Si l'idée est de recomposer des shapes historiques des différents zonages notamment communaux, alors vous pouvez vous inspirer de geohisto pour générer les shapes anciens à partir des shapes récents en fonction des modifications communales ayant opéré.

Concernant mes besoins, j'ai reparcouru la liste des différents cas et ai identifié les cas qui permettent de suivre de manière complète l'historique des communes tel qu'il est utilisé pour les changements de COG de bases de données (en gras les cas pas encore traités dans geohisto, unique cas commençant par 5XX que j'ai donc identifié à ce stade) :
fusions :
300,310,311,320,321,330,331,332,333,340,341,350,351,360.
défusions :
200,210,230
changements de code :
410,411,500
changements de nom :
100,110,111,120,130,140,150
+ un cas particulier qui pourrait également avoir son utilité je pense : Commune associée devenant déléguée (hors création commune nouvelle)
700

A bientôt pour la suite des évènements ;)

[davidbgk]

Bonjour Kim,

Il faut que l'on améliore la documentation au sujet de geozones, c'est en court. L'idée initiale était de pouvoir avoir les différentes zones administratives valides à un instant t. Ces zones pouvant être région/départements/communes/EPCI/cantons/etc. Avec les différentes actions sur les communes et régions en 2016 est né le besoin d'avoir une gestion de ces zones dans le temps de façon à rester pertinents sur les jeux de données soumis sur data.gouv.fr. Ainsi est né geohisto qui retrace ces historique avec à la fois les relations d'ancêtres/descendants sur un même niveau mais aussi les relations parentales entre régions, départements et communes.

Ces relations ont ensuite été exploitées dans geozones en conservant ces hiérarchies et en utilisant les exports récents d'OSM pour avoir les shapes des (dé)fusions récentes. Nous ne sommes pas allé plus loin pour le moment dans le temps car nous n'avons pas ce besoin et qu'il est délicat de le faire de manière automatisée compte-tenu de la valse des parcelles entre communes au risque de se trouver avec un gruyère.

Concernant les codes manquants :

• 500: correspond à 18 cas ;
• 130: correspond à 4 cas ;
• 140: correspond à 0 cas ;
• 150: correspond à 0 cas ;
• 700: correspond à 6 cas.

Cela me semble intégrable et j'ai créé les issues dédiées : #48 #49 #50

[antuki]

Merci pour cette explication de geozones, j'avais à peu près compris l'idée dans votre dernier message.

Je crains en effet que vous vous heurtiez à un mur concernant la reconstitution des géographies très anciennes en termes de cartographie en raison des transferts de parcelles. Mais peut-être que l'IGN suit également (de la même manière que l'Insee) les géographies communales en termes de cartographie depuis plusieurs dizaines d'années ? En tous cas, si vous avez des pistes sur ces sujets à l'avenir je serais intéressée de les connaître 👍

Merci pour ces nouvelles issues.

Je profite de cet échange pour vous demander s'il vous semble pertinent de valoriser COGugaison sur data.gouv ou bien si ce n'est pas le lieu ? Je souhaiterais en effet que mon travail serve au plus grand nombre mais mon réseau se limite hélas quasiment à mes collègues de bureau !!!

[davidbgk]

J'ai tenté d'être plus clair sur la documentation de geozones avec une documentation en français des spécificités françaises, j'espère que c'est plus compréhensible. Toujours difficile de prendre suffisamment de recul lorsqu'on documente son propre travail.

[davidbgk]

Je profite de cet échange pour vous demander s'il vous semble pertinent de valoriser COGugaison sur data.gouv ou bien si ce n'est pas le lieu ?

Je pense qu'il est tout à fait légitime d'ajouter une réutilisation au jeu de données du COG de l'INSEE au même titre que celle que j'ai ajoutée pour geohisto.

[antuki]

Merci pour cette nouvelle documentation. Ce n'est pas qu'elle est mal faite, c'est que le sujet est tellement technique que même quand on baigne un peu dedans on a du mal à s'y retrouver !!!

En tous cas, quand vous aurez corrigé les différentes issues que je vous ai fait ajouter (désolée !!! :) ) je m'engage à refaire des comparaisons avec mes tables de passage et à voir si je n'identifie pas d'autres différences entre nos travaux !

[antuki]

Je réponds ici à vos remarques sur vos issues qui s'adressent plutôt à vos collègues anglophones je pense !

#49 : Deal with code 130 for modifications : As of today, we do not keep track of chef-lieux for towns so this change will not introduce any visible modification which can be confusing. Do we want to introduce that data in our exports?

Il y aurait une modification de nom de commune (name) non ? De la même manière que toutes les autres modifs de type 1XX dont certaines dont vous avez déjà tenu compte

#48 : Deal with code 500 for modifications : Same issue as #49 (comment) we can hardly handle that code without logging the chef-lieu for each town.

Il y aurait une modification du insee_code cette fois-ci. Ne pas en tenir compte fait que Oudon n'a pas le bon code officiel géographique pendant 30 ans dans geohisto.

Pour l'issue #50 (MOD=700), c'est plus complexe en effet. Il y aurait au moins une modification de insee_modification (qui ne compte pas vraiment) et l'ajout d'un successor supplémentaire mais la modification ne sera pas visible sans interpréter la variable insee_modification en effet. L'utilité serait d'ajouter une variable dans towns sur le statut de la commune (commune absorbée, commune absorbante, commune associée, commune pôle, commune nouvelle déléguée, commune nouvelle non déléguée, commune déléguée simple...) mais c'est peut-être un peu trop complexe à mettre en oeuvre pour vous à ce stade.

Edit : Après réflexion, l'issue #50 me semble en effet à ce stade difficile à mettre en œuvre puisqu'une commune qui devient déléguée "disparaît" de votre historique puisqu'elle étant rattachée à la commune nouvelle qui l'absorbe. Ainsi, dans ses successors n'apparaît que la commune nouvelle. Il n'est donc pas vraiment possible de suivre l'évolution de cette commune déléguée. Je pense que vous pouvez donc, comme pour les transferts de parcelles, mettre ce cas de côté pour le moment.