[OSM-talk-fr] Proposition de mise à jour : la population des communes

Ven 17 Jan 08:25:24 UTC 2020

Le plus simple c'est de modifier les deux en même temps (seulement pour les
noeuds admin_centre des communes au niveau 8, ou 9 pour les communes
déléguées ou arrondissements) ou sinon virer la population du noeud.

Pur les grosses communes divisées en IRIS, y compris à Paris avec ses
arrondissements groupant des quartiers, sous-quartiers et IRIS ; le noeud
Paris ne devrait avoir aucune population d'arrondissement mais ce n'est pas
clair si cela désigne la population départementale/municipale, ou celle de
la préfecture de Paris avec la petite couronne, ou le Grand Paris, de toute
façon ce n'est pas un IRIS Insee et c'est une totalisation partielle en
retirant les double-compte : on ne peut pas déduire cette population par
une simple somme arithmétique, la source est différente, les critères
d'inclusion dans une commune ou une autre sont un peu différent, et ce
n'est pas la somme des populations communales mais celle établie ensuite
par l'Insee qui a retiré les double-compte (notamment la population légale
par département, publiée par le décret de janvier 2020).

L'insee passe un temps fou à détecter les double-comptes mais certaines
communes exigent et obtiennent un droit à tenir compte de certaines
populations (dont les étudiants ou les touristes qu'elle héberge de façon
non permanente ou rapatrier chez elles les personnes à charge de personnes
situées dans d'autres communes, la population hospitalisée, celle
temporairement en prison n'importe où au moment du recensement mais ayant
encore un "domicile" officiel qu'elle ne peuvent pas occuper, tous ceux en
service extérieur commandé pour les armées, et la capacité d'accueil
moyenne dans les casernes en France à qui les communes ou communautés
doivent aussi rendre certains services, et certains autres résidents
quasi-permanents à l'étranger qui ont un droit de retour ou de rapatriement
permanent et immédiat en France à leur domicile déclaré.

Pour les communes non subdivisées en IRIS, donc de moins de 5000 habitants
(donc des noeuds de type place=town, village, voire hamlet dans quelques
cas) le noeud chef-lieu devrait afficher une population égale à celle de sa
relation de niveau 8 ou 9.

Moi je suis convaincu que la population au niveau du noeud n'est pas liée à
celle de la relation, le noeud ayant plus la signification associée à la
classification OSM (place=city/town/village/etc.) mais c'est significatif
si cela désigne l'agglomération. Mais dans les agglos multicommunales la
population de l'agglo ne marche plus.

De même des communes rurales et certaines communes urbaines récentes sont
créées pour grouper des villages formant des agglo différentes; ce n'est
pas clair si le noeud admin_centre devrait être la population totale de la
commune incluant ces villages périphériques dans des agglos séparées, ou la
population de l'agglo centre contenant le noeud (et parfois le noeud
communal n'est même pas fixé dans une des agglos mais entre elles, c'est le
cas pour les communes nouvelles à moins qu'on ait choisi le chef-lieu de la
commune déléguée membre, mais il y a encore des exceptions avec les
communes insulaires).

Bref Osmose peut dire ce qu'il veut. La population du noeud est difficile
voire impossible à vérifier par un moyen automatique, elle n'est pas
réellement sourçable elle donne jutse un indicateur estimé. Ce qui compte
c'est la population des relations qu'Osmose peut alors vérifier de façon
limitée (pas question de faire des cumuls à cause des double-compte, mais
la somme des membres devrait être supérieure ou égale à celle du contenant;
il vaut mieux sourcer séparément la population de chaque relation
contenante, et laisser à part celle des membres à gérer séparément)

Le ven. 17 janv. 2020 à 08:33, Jacques Lavignotte <jacques at lavignotte.org>
a écrit :

> Bonjour,
>
> Osmose râle sur mes récentes modifs d'hier soir (selon le mode op
> indiqué par Vincent )  :
>
>   Attribut “population” inconsistant entre la relation et son membre
> “admin_centre”
> Population du rôle “admin_centre” (309) supérieure à celle de la
> relation (305)
> relation 146525
>
> Qu'ai-je fait de mal ?
>
> Merci de me guider vers les corrections
>
> J.
>
>
>
> Le 14/01/2020 à 12:02, Vincent de Château-Thierry a écrit :
> > Bonjour,
> > Après l'échauffement avec la mise à jour des cantons il y a quelques
> jours, je vous propose un nouveau chantier, d'une autre ampleur mais à
> peine plus long.
> >
> > L'INSEE vient en effet de publier les chiffres de population légale par
> commune pour 2017 [1]. C'est l'occasion de mettre à jour le tag population
> de nos 35000 relations communales. Ca peut effrayer au premier abord car ça
> signifie écrire 35000 fois un chiffre relevé sur un listing, sans se
> tromper... pas sûr d'avoir envie. J'ai donc essayé de nous économiser, en
> proposant une interface de saisie que j'espère efficace.
> >
> > En allant ici :
> http://dev.cadastre.openstreetmap.fr/fantoir/maj_population_2017.html
> vous visualisez la liste des départements, et pour chacun le % de communes
> dont le tag population est à jour, avec les valeurs de 2017. A droite de
> chaque ligne, le lien fait accéder au détail des communes pour un
> département. Ici sur chaque ligne, on retrouve le code INSEE, le nom de
> commune, le nouveau chiffre de population, et un lien JOSM. Ce lien charge
> dans JOSM la relation administrative de la commune ET se propose de mettre
> à jour le tag population avec la bonne valeur, et le tag source:population
> avec la valeur 'INSEE 2020'. Pour info on a pour l'instant 29964 tags
> source:population = 'INSEE 2013' [2].
> >
> > A aucun moment du processus on est censé renseigner manuellement la
> population, c'est le clic sur le lien JOSM qui fait le boulot, grâce aux
> chouettes fonctionnalités de la telecommande JOSM :). C'est pour ça que je
> pense que cette mise à jour peut se faire rapidement, d'autant plus si
> chacun en fait un petit morceau, dans sa zone de confort.
> >
> > Ce chantier peut au passage être l'occasion d'un petit bilan de santé de
> nos relations communales :
> > - est-ce que la relation a bien des ensembles de way formant des boucles
> fermées ?
> > - est-ce que la relation a bien un node avec le rôle 'admin_centre' ?
> > - est-ce qu'on tombe sur un tag addr:postcode=* ? Si oui ça peut être
> l'occasion de le convertir en postal_code=* sachant qu'on l'a sous la main,
> ça homogénéise notre modèle de données des polygones postaux
> > ...et toute autre 'opération de maintenance' que vous trouverez à faire
> sur les relations administratives (n'hésitez pas à les proposer dans le fil)
> >
> > Les tableaux d'avancement sont mis à jour toutes les 2mn donc il est
> recommandé de produire de petits changesets et de les envoyer souvent, pour
> minimiser le risque de conflit d'édition. Et un bémol : je n'avais pas sous
> la main les populations 2017 des arrondissements municipaux pour Paris,
> Lyon et Marseille, ça se fera donc à la main en piochant ici [3].
> >
> > Merci pour vos retours et vos quelques clics :)
> >
> > vincent
> >
> >
> > [1] https://www.insee.fr/fr/statistiques/4265439?sommaire=4265511
> > [2] https://taginfo.openstreetmap.org/search?q=insee+2013#values
> > [3] https://www.insee.fr/fr/statistiques/zones/4269674?debut=0
> >
> > _______________________________________________
> > Talk-fr mailing list
> > Talk-fr at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> --
> GnuPg : 156520BBC8F5B1E3 Because privacy matters.
> On mangera ? (c) (tm)
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20200117/95046a3d/attachment.htm>