[OSM-talk-fr] Label et rendu linguistique

[Philippe Verdy]

Dans ce que j'ai compris la valeur qu'on donne à place=* sert :

- à guider le style d'apparence du label (taille de police, gras, italique,
grandes capitales ou petites capitales, voire soulignement... pour
différencier les communes des lieux dits, des zones commerciales ou
quartiers, noms de parcs ou autres entités géographiques comme les îles, ou
archipels, sommets de montagne ou nom de massifs)

- ou a guider son apparition ou non sur la carte (selon l'échelle de rendu)
car on ne peut pas tous les afficher : il faut faire des choix arbitraires
basés sur "l"importance" relative (mais avec un critère pas clair :
s'agit-il de la population su lieu seul, ou de son agglomération entère, ou
de son statut adminsitratif par rapport à un niveau administratif donné ?)

Souvent ce n'est pas clair et pas toujours objectif (par exemple entre
place=island et place=islet : on passe à la comparaison des surfaces mais
on ne sait pas toujours ce qui est inclus dans la surface : seule la partie
toujours émergée ou le plateau attenant avec ses rochers et plages
découvertes à marée basse).

La valeur de ce place=* est donc assez qualititatif et très subjectif (et
trop souvent guidé en fonction du rendu attendu sur un moteur de rendu
particulier)...

En revanche le membre de rôle "label" dans une relation est non subjectif :
il décrit d'abord une position adéquate dans la surface où il est approprié
de placer le label pour qu'il ne puisse pas être confondu avec la
désignation d'autre chose. Là où il se justifie le plus c'est pour nommer
des surfaces fortement convaves, ou enserrant des enclaves, ou éclatées en
pusieurs sous-zones écartées les unes des autres : le label doit se
positionner dans la zone effective et le calcul d'un centroïde est faux.

En théorie le membre de rôle "label" n'est pas nécessairement restreint à
désigner un seul noeud et pourrait prendre la forme d'un chemin continu,
permettant d'indiquer comment orienter un label au lieu de ne pouvoir
l'afficher par défaut qu'horizontalement, et à préciser la longueur selon
laquelle il devrait "s'étaler" (au lieu d'utiliser des caractères avec une
"approche" normale et de restreindre arbitrairement la largeur de rendu de
ce label en urilisant des sauts de ligne) : ce serait utile pour les
massifs de montagne, dont les relations ont aussi des frontières "floues",
à condition que la feuille de style l'autorise (c'est généralement le cas
pour les labels qui devraient recourir une zone très étendue de la carte
affichée, avec des polices très grandes et des caractères assez gras pour
rester lisibles mais semi-transparents pour ne pas cacher le reste en
dessous.

Les noms indiqués dans le label n'ont souvent guère d'importance : mais ils
peuvent cependant être différents du nom classique utilisé pour désigner
(hors du contexte de la carte elle-même) une région. En effet la carte
fournit un contexte qu'il n'est pas nécessaire de rappeler, au contraire du
nom utilisé pour désigner une région toute seule (ce nom doit être assez
précis et descriptif, même si on a ôté de ce nom des éléments qui sont
rappelés dans d'autres attributs, notamment le type générique d'objet).
L'exemple typidque de simplification du nom dans un "label" est la
suppression des prévisions qui lèvent l'ambiguité sur une homonymie simple.

Pour ces raisons, les noms indiqués dans un "label" sont prioritaires sur
ceux de la relation quand on devra choisir un nom signifiant pour un rendu
cartographique (où ces noms seront aussi spatialement géolocalisés, et donc
déjà différenciables sans ambiguïté par leur position). Les noms indiqués
dans un "label" n'ont en revanche aucune utilité dans un rendu de type
"tableau de données" (où figure ensuite un lieu vers la carte, ou bien une
minicarte où les noms de zones sont remplacés par un petit numéro d'index
dans chaque zone, le tableau de données référençant ensuite ce numéro, mais
donnant le nom assez précis (sans homonymie) de la relation.

Mais dans la plupart des cas, le label et le nom de la relation n'ont pas à
être différents : si une relation a un membre label nommé, les noms données
à la relation deviennent redondants, et il vaut mieux alors le mettre (avec
ses traductions) dans le label.

Attention : certains noms peuvent être homonymes dans une langue et pas
dans une autre : il ne faudrait pas créer de nouvelles homonymies en
transférant systématiquement les noms de relations vers leur label, et
supposer alors que la relation est clairement (et uniquement) nommée
d'après seulement son label (ce sera vrai pour un rendu cartographique, pas
pour un rendu de ces noms dans un tableau de données) : on peut y copier
des noms de la relation vers le label mais pas faire l'inverse du label
vers la relation.


Le 19 décembre 2012 15:59, Christian Quest <cquest at openstreetmap.fr> a
écrit :

> Le 19 décembre 2012 15:25, Ab_fab <gamma.gts at gmail.com> a écrit :
> > osm2pgsql traite les noeuds avant les relations
> >
> > Le noeud a le rôle label dans la relation, mais c'est avant tout un
> noeud de
> > type place
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20121219/b0d37220/attachment.htm>