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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
--
Christian Quest - OpenStreetMap France
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
