Mise à jour automatique des population=* depuis les données INSEE

Sur la ML talk@ (pas fr), quelqu’un a signalé un outil qui contrôle la cohérence des population=* entre les différent niveaux admin_level.

https://disaster.ninja/active/reports/osm_population_inconsistencies

Du coup, j’ai regardé sur les données françaises et comparé avec les derniers chiffres officiels de l’INSEE de 2021, qui concernent la population en 2018.

Conclusion… il y a une mise à jour globale à faire en France où l’on a des population=* disparates, rarement mises à jour, avec la date non indiquée en population:date=*

Plus de 32000 mises à jour à faire et comme il s’agit juste de reporter une donnée officielle et rien de plus, je propose de faire ça automatiquement plutôt que d’abuser de clics de souris et provoquer des TMS inutiles.

Je scripte tout pour pouvoir le reproduire à chaque nouvelle parution des population officielles de l’INSEE (la prochaine c’est dans un mois).

  • D’accord :slight_smile:
  • Pas d’accord :frowning:

0 votant


Premier changeset de test: Changeset: 114584640 | OpenStreetMap

Articulation avec les éditions automatiques sur le wiki, la liste talk-fr, …
C’est pour discussion, car le forum peut
présenter une vrai facilité, c’est sûr :rofl:

Une catégorie édition automatique ?

Question indépendante du fait que je trouve cela pertinent

J’ai ajouté mon compte « cquest_bot » dans le tableau : Bot - OpenStreetMap Wiki

Et commencé un peu de documentation: Automated Edits/cquest bot - OpenStreetMap Wiki

1 Like

Excellente idée, je suis pour à 1000 %.

Je m’interroge juste sur les potentiels pièges, les communes ayant fusionnées/défusionnées par exemple. @cquest aurais-tu repéré de tels cas qui mériteraient une attention particulière ?

1 Like

A priori OSM reflète les communes actuelles et l’INSEE aussi. Mais effectivement pour les communes fusionnées entre 2018 et 2021, on peut avoir des codes INSEE ne représentant plus les mêmes frontières.
Pour 2019 : Liste des communes nouvelles créées en 2019 — Wikipédia.
Par exemple Plouigneau 29199 a été fusionné avec Plouigneau 29199 - Le Ponthou 29219.
Du coup si Le Ponthou existe dans les données 2021, c’est Plouigneau canal historique^^.

Les données INSEE de 2021 correspondent aux communes 2021, mais à la population 2018.

Il n’y a que Plouigneau dans le fichier INSEE, comme dans OSM.

Relation: ‪Plouigneau‬ (‪9165401‬) | OpenStreetMap = commune nouvelle
Relation: ‪Plouigneau‬ (‪290120‬) | OpenStreetMap = ancienne commune
Relation: ‪Le Ponthou‬ (‪290119‬) | OpenStreetMap = commune déléguée

Tout a fait OK pour l’édition de masse.
D’après Wikipédia, il n’y a pas eu de communes fusionnées au cours de l’année 2021 seulement 2 au 1 janvier 2021 qui doivent être pris en compte par l’INSEE :

Par contre, sur Wikipédia, ils ont repéré 4 fusions pour le 1 janvier 2022, et je viens de regarder, elles sont déjà dans OSM avec start_date=2022-01-01 et les anciennes communes qui ne sont pas encore ancienne ont été passé en admin_level=9

Les éditions ont été fait sous le pseudo chabe01, le même pseudo sur Wikipédia a créé les pages des 4 communes nouvelles donc je pense qu’il n’y a que ces 9 communes qui en deviendront 4 qui sont concernées.

Je n’y touche pas, je laisse le dresseur de bot voir comment il veux géré ces communes :slight_smile:

Bonjour.
J’entends bien ce que vous dites mais.
Mais comment gérer la mise à jour des communes fusionnées qui n’ont plus de numéro INSEE (celui indiqué dans OSM est obsolète), et dont on ne connaît pas les chiffres de population sauf en consultant directement la commune mère… si elle y a fait un recensement séparé ce qui n’est pas obligatoire.

On supprime la donnée de population pour ces anciennes communes ?

On peut conserver la dernière connue, la date étant indiquée sur population:date=*

C’est une erreur ça, c’est en janvier (ou le 31/12) qu’il faut faire le changement, pas avant, car ces communes aujourd’hui sont bien en admin_level=8 et pas 9.

Et hop, un premier changeset de test: Changeset: 114584640 | OpenStreetMap

Et un second plus ambitieux, qui a mis à jour les régions: Changeset: 114586315 | OpenStreetMap

Deux changeset de plus:

Le premier a mis à jour les départements, le second est un premier changeset sur un petit département complet (le 94).

Je pense que c’est bon maintenant pour lancer ça sur l’ensemble des départements, avec un changeset par département pour conserver une taille raisonnable.

Mise à jour appliquée sur les départements d’Île-de-France, avec un changeset par département (comme ça Jersey est épargnée).

Merci pour Lee Carré, comme ça c’est à l’image de son patronyme… carré :wink:

Carré ou obtus, c’est selon. On est déjà au moins 3 à s’être fait stricker par lui.

Terminé !

RDV pour les données 2019 qui seront disponibles début 2022 :slight_smile:

2 Likes

Salut,

Il m’intéresse ton script! Dans le sud et peut-être généralement il y a beaucoup de hameaux, lieu-dit, villes et villages qui sont mal renseigné (ex un hameau tagué en village). Selon le wiki, un village c’est à partir de tant d’habitants jusqu’à tant, pareil pour les villes, etc.

Ton script modifie le type ville/villages/etc en fonction du nombre d’habitants en même temps qu’ils renseigne la population ?

Il n’y a que 3 tags qui ont été mise à jour par le bot :

  • population=*
  • population:date=*
  • source:population=*

Il y a eu un choix fait il y a plusieurs années de ne pas utiliser place=hamlet sur les toute petites communes françaises. Les niveaux de population de place=* sont en effet assez arbitraire et pas forcément adaptés pour tous les pays. Les limites de population sont une indication, plus qu’une règle dure… et comme on précise la population officielle, par ailleurs tout va bien.

Il est question de communes. Les hameaux n’étant pas des communes, tu ne peux que constater si une commune a moins de X habitants, c’est au plus un village. Et pour ça Overpass Turbo est ton ami.

Si les gens du sud exagéraient, ça se saurait^^.