[OSM-talk-fr] Noms de communes et de chef-lieu / Mapnik bégaye

[sylvain letuffe]

> Les tags place sont tagués de façon homogène depuis 1 an et demi. Je
> préfère voir le code INSEE et le code postal sur le noeud qui
> symbolise la municipalité plutot que sur un polygone.

J'ai pas mal réfléchis en lisant :
http://wiki.openstreetmap.org/wiki/Proposed_features/add_center_in_Relation:boundary

( je vais intervenir sur ce sujet qui déborde sur la question d'écrire le nom 
d'un lac, d'une forêt, d'un massif )

ça soulève quelques bonnes questions, pour autant cette solution ne me semble 
résoudre un problème que de façon détourné.

Tentons de nous rapprocher de ce que le code INSEE et le code postal veulent 
dire.
- Le code INSEE, c'est celui de la commune, pas du chef-lieu de cette même 
commune
- le code postal, lui, est applicable non seulement au chef-lieu, mais à toute 
la commune voire des communes environnantes. (voire des irrégularités)

Présenté comme ça, il me semble alors logique que ce soit la commune qui 
contienne ces informations. Le chef-lieu peut lui aussi les contenir, car ce 
ne serait pas non plus faux, mais imprécis.

> Si je lance une recherche sur namefinder en tapant le code insee ou le
> code postal, je préfère que le lien m'indique les coordonnées de la
> place et pas vaguement le milieu d'un polygone.

Il y a la deux choses :
- l'usage que l'on veut faire de cette base.
De même qu'il est préférable d'éviter de tagger pour le rendu, il me semble 
aussi préférable d'éviter de tagger pour namefinder. C'est sur une base 
propre que l'on peut faire des outils propres. De mon coté, si je cherche un 
code insee de commune, alors il me semblerait logique de trouver la commune 
et plutôt qu'une flêche, une manière d'indiquer qu'il s'agit du polygone.

- Deuxièmement il y a les manières de représenter le nom d'une surface, et 
cela déborde sur ce qu'on peut lire sur la page précitée : Un logiciel ne 
peut pas, uniquement à partir d'un polygone, déterminer où le texte de 
description du polygone doit se trouver. Ceci est un problème de rendu, mais 
qui ne peut être résolu sans l'aide d'une donnée. Il n'en reste qu'il s'agit 
d'un problème de rendu.
On pourrait alors imaginer un point "label de polygone pour le rendu" qui 
permettrait de choisir où se trouve le texte. Mais hors mis la valeur de ce 
point pour le rendu, il n'a aucune autre valeur de donnée, je ne trouverais 
pas logique qu'il contienne un code insee ou postal ou nom.

> > This is seulement my avis
> > --
> > sly
>
> Pas seulement puisque tu viens de changer le rendu de ta carte en
> ligne. Avant de changer les règles, il faudrait voir à chercher un
> minimum de consensus.

Ma faute, "with power comes responsability". J'ai pû laisser penser que 
j'allais influencer la manière de tagger, mais c'était inconscient. Je 
répondais à mon besoin du moment :
- j'ai trouvé une commune dont le script d'alban n'avais pas rajouté le 
chef-lieu et je me suis demandé comment je pouvais ajouté au mieux code insee 
et code postal. Je me suis ensuite construit un outils pour visualiser 
rapidement si d'autres avaient fait comme moi.

Mais ma réflexion m'a amené à ce que j'ai dis plus haut : Me semble plus 
logique sur le polygone que sur un point.

Discutons ;-) J'ai retiré le rendu des code insee de mon rendu, je/nous n'en 
sommes pas à un stade où il faudrait laisser penser que c'est la meilleure 
manière de faire.

>
> Je sais que tu fais partie des gens qui veulent mettre le maximum de
> choses dans les relations et au final, n'avoir que des noeuds ou des
> polylignes sans tags. 

C'est aussi quelque chose qui m'a traversé l'esprit et qui se rapproche de 
l'avis de Frederik Ramm : 
http://wiki.openstreetmap.org/wiki/Maritime_borders#Voting

Il paraît que ça revient un peu sur l'idée de l'api 0.4 que je n'ai pas connu 
avec les "segments".

Les questions restant que les editeurs/rendus supportent mal les relations, 
qu'elles sont obscures à manipuler et que le concept est un peu hardu pour un 
débutant. 
Ce en quoi je suis d'accord, ce qui fait qu'on ne peut pas avancer trop vite 
dans cette direction.

Cependant, je ne me décrirais pas comme un "relations" only. Des critères 
physiques peuvent très bien être attachés au way directement. Le fait qu'une 
route soit goudronnée ne nécessite pas l'utilisation d'une relation. En 
revanche, que la référence D 212 s'applique à 100 ways et soit dupliquée me 
semble une perte d'energie et surtout un démembrement de l'objet "D 212"

Si par exemple, je veux déterminer la longueur de cette D 212, il n'y aura pas 
de manière fiable de le faire sans un moyen de dire que les 100 ways sont 
regroupés.

> Mais ça n'est pas une tendance de fond sur OSM. 
Tout peut s'inverser, si la preuve est apportée qu'elles apportent la 
possibilité de représenter des choses impossible jusqu'a maintenant où si 
elles aident à l'entretient de la base.
( non redondance, homogénéité,...)

> N'oublie que beaucoup de gens sont encore allergiques aux relations et
> que les éditeurs n'offrent pas encore d'interface satisfaisante pour
> les modifier.

Exactement. Mais comme beaucoup de choses, il faut taper un peu dans la 
fourmilière pour que les choses (éditeurs) évoluent si le jeu en vaut la 
chandelle.

--
sly