[OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[osm.sanspourriel at spamgourmet.com]

Bonjour Christian,

J'ai fait des essais assez exhaustifs afin d'avoir une modélisation de
place avec une zone pour confirmer tes dires : il faut ceinture et
bretelles, place sur la relation (logique) et place sur le nœud label
(ou admin_centre).

https://www.openstreetmap.org/relation/10060749

Oui ici ça n'avait pas de sens de dire admin_centre pour un lotissement,
mais c'est aussi valable pour admin_centre.

 > je sais, je suis lourd
Pas toi, c'est le modèle qui est lourd.

Reste qu'on a des admin_centre de niveaux 8 et 9 pour les communes
déléguées et assimilées.

Si on force municipality comme type de place, on indique bien que la
valeur porte sur l'ensemble de la commune et non sur une des
communes/zone agglomérée. Heu, quoique : Audierne-Esquibien (niveau 8) a
pour admin centre l'admin centre d'Audierne (9).

Comment sait-on si la population du nœud Audierne concerne Audierne ou
Audierne-Esquibien ?

population:admin_level= 8 ou 9 pourrait le résoudre.

Est-ce qu'il y a mieux en stock dans vos méninges ?

Jean-Yvon

Le 11/02/2020 à 17:18, Christian Quest - cquest at openstreetmap.fr a écrit :
> J'ai l'impression que le rendu osm.org ne prends en compte que les
> noeuds place=*, pas les boundary.
>
> Il fut une époque où il utilisait les deux, mais cela donnait des noms
> en double.
>
> Dans le rendu FR, j'ai une requête compliquée pour éviter ça... elle
> prends le place=* en priorité (car mieux positionné) et le centroid du
> boundary en second quand il n'y a pas de place pour un même nom.
>
>
> Un noeud place=municipality avec un population pour prioriser quand on
> manque de place (je sais, je suis lourd) permettrait de s'en sortir à
> moindres frais.
>
>
> Le 11/02/2020 à 15:32, marc marc a écrit :
>> Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :
>>> ne pas les repérer par un nœud place=* contrairement aux communes
>>> d'avant 2010
>> je pense qu'il y a une erreur de modélisation dans ta vision
>> place=town/city représente un village/ville, peu importe que la commune
>> où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
>> un polygone ou une relation boundary administrative admin_level=8
>> représente une commune, peu importe qu'elle ai jamais fusionné ou
>> fusionnée jadis ou récemment.
>> il n'y a aucune différence de traitement selon leur origine.
>>
>> il se fait qu'il y a des villages/villes qui portent le même nom que la
>> commune et d'autre pas, c'est le choix des intéressés de garder
>> (fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
>> cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
>> fusion.
>>
>> cela ne va pas du tout de créer un faux place=town/city juste pour faire
>> apparaître le nom d'une commune parce que invisible sur un rendu donné.
>> cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
>> un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
>> avec le même nom.
>>
>> si tu veux vraiment créer un objet place=* dupliqué ce serrait
>> place=municipality qui serrait lui aussi tout aussi invisible par le
>> rendu que tu critiques (et je partage ton avis sur le côté pas génial
>> de ne pas voir les communes de manière + claire qu'un nom à la
>> frontière).
>>
>> une piste de solution : rendre les (toutes) communes + visible sur le
>> rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>