Le choix du tag place=village c'est le consensus pour une commune de
moins de 10000 habitants, cela n'indique pas un "village".
Pour la position, je l'ai pifométriquement mis au centroid de la commune
nouvelle, tout comme on positionne le place=state correspondant à une
région plus ou moins au milieu de celle-ci avec un rôle label dans la
relation. D'ailleurs, je ne l'ai pas mis en admin_centre, c'est le
place=* du chef-lieu qui porte ce rôle dans la relation
boundary=administrative.
Le positionner à l'emplacement du chef-lieu n'est pas à mon avis une
bonne idée:
- cela masquera potentiellement sur les rendus le nom de la commune
délégué qui devient le chef lieu de la commune nouvelle
- cela donnerai une "préférence" géographique qui n'a souvent pas de
réalité pour ces communes nouvelles. Dans le cas présent le chef lieu se
situe totalement au sud (Aillant-sur-Tholon) des 4 communes fusionnées
- rien dans le wiki n'indique où positionner le noeud place=*, son
placement est du coup plus ou moins libre et à adapter selon les cas
Je ne pense pas qu'on soit dans "tagguer pour le rendu", c'est à dire
utiliser de mauvais tags pour quelque chose apparaisse sur le rendu. On
est ici dans un choix qui facilite le rendu et qui sépare bien les roles
de chaque place=* dans la relation de la commune nouvelle.
Si vous avez mieux à proposer, n'hésitez pas.
Le 13/07/2016 à 21:52, Jérôme Amagat a écrit :
Je n'aime pas bien ça , créé un noeud place= avec le nom de la
nouvelle commune juste pour le rendu! Ici Montholon n'est pas un
village et a cette endroit il n'y a rien, (en plus ici le nom apparaît
sur le rendu alors que la commune nouvelle n'existe pas encore). Le
nom est sur la relation commune et ca suffit pour avoir des données
justes. Ce qui s'appelle Montholon c'est tout le territoire de la
commune est pas un point ou un village quelquepart. Si ca n'apparait
pas sur le rendu, c'est pas de la faute aux données mais au rendu qui
n'affiche pas le nom des communes. Soit il faut changer le rendu soit
laissé comme ça sans le nom des commune. Est ce que ses nom sont bien
important? c'est pas nouveau des communes avec un nom qui n'est pas un
nom de village (ou accumulation de plusieur nom)
Le 13 juillet 2016 à 18:23, Philippe Verdy <verd...@wanadoo.fr
<mailto:verd...@wanadoo.fr>> a écrit :
Bof... recule un peu tu ne vois plus que les communes déléguées.
Et ce placement n'est pas celui du chef-lieu de la commune, c'est
posé un peu n'importe où, en fait plus là pour taguer pour le
rendu. Ce noeud devrait être cependant un rôle label, pas un noeud
place=*, ni avoir le rôle admin_centre (dont le noeud garde le nom
et le placement de la commune déléguée).
Le 13 juillet 2016 à 18:07, Christian Quest
<cqu...@openstreetmap.fr <mailto:cqu...@openstreetmap.fr>> a écrit :
Un noeud place=* fait le job, exemple:
http://www.openstreetmap.org/node/4284576845
Le 13/07/2016 à 17:55, Stéphane Péneau a écrit :
Hello !
Une note laissée sur osm.org <http://osm.org> m'a fait
remarqué que lorsqu'une commune nouvelle a comme chef-lieu
une des anciennes communes - ce qui doit être la majorité
des cas - elle ne s'affiche pas sur le rendu par défaut,
ni sur le rendu osm-fr. C'est plutôt ennuyant.
Pourtant, il me semble qu'il y a quelque temps, on voyait
le nom de la commune au centroïde des limites admin ET le
nom de la commune du tag place. Ce n'était pas très
heureux lorsque les 2 noms étaient identiques, mais dans
le cas présent, ça aurait son utilité.
J'ai rêvé ou pas ?
Actuellement, le tag name du noeud "place" semble être
prioritaire sur le name de la relation.
Une solution serait le tag label dans la relation, mais il
semble ne toujours pas être supporté par mapnik.
À part demander des changements sur le rendu, quelqu'un
voit une solution ?
La note en question :
http://www.openstreetmap.org/note/626633#map=12/47.1389/-1.9281
Stf
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
--
Christian Quest - OpenStreetMap France
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
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
