[OSM-talk-fr] Label et rendu linguistique

Philippe Verdy verdy_p at wanadoo.fr
Mer 19 Déc 22:42:18 UTC 2012


Pas vraiment, fixer un label pour qu'il se place correctement SUR la zone
qu'il désigne et pas aritrairement en un seul point (souvent mal placé et
parfois en dehors si on n'utilise que le centroïde) donne une
information fausse sur la carte. Déterminer un endroit qui couvre bien la
zone est facile à faire indépendamment du type de rendu : cela ne fixe rien
concernant l'obligation de placer le label uniquement à un seul point
arbitraire, c'est indépendant de l'échelle de rendu.

La seule alternative ce sont les labels le long de la frontière, mais là le
label est encore plus flou sur ce qu'il désigne puisqu'on les affiche tous
mélangés (à droite ou à gauche.

La seule chose qu'on cherche à déterminer c'est une zone convexe située
dans la surface et qui n'en déborde pas. Si la surface est concave, que
faut-il couper pour que cela devienne convexe ?

(1) Il existe bien un algo simple, déterminant un UNIQUE surface convexe
MINIMALE englobant une surface concave (cette surface est la surface donnée
elle-même si elle est convexe, c'est visiblement à partir de lui qu'on
détermine le centroïde qui sort trop souvent des surfaces concaves,
notamment des surfaces constituées de plusieurs parties exclavées — ce qui
n'est acceptable que si le label qu'on centre dessus couvrira une partie
"essentielle" de la surface qu'il désigne, ce qui ne se produit à faible
niveau de zoom où on ne voit pratiquement pas que la surface est concave et
s'assimile à un seul point central visible)

(2) Mais il n'y a pas d'UNIQUE surface convexe MAXIMALE inscrite dans une
surface concave : c'est pourtant là qu'on devrait y placer un label, qui
devrait être le plus "couvrant" possible. On peut chercher à couper du
polygone concave la plus petite aire possible (pour que la surface convexe
restante ait l'aire la plus grande possible), mais dans certains cas, on
aura encore le choix (si deux découpes possibles pour rendre la surface
convexe ont la même aire). Si on n'a pas d'algorithme, où veux-tu placer le
label, et comment le placer qu'il soit le plus représentatif possible de la
zone qu'il recouvre et de celle qu'il désigne ?



Le 19 décembre 2012 23:02, Vincent de Chateau-Thierry <vdct at laposte.net> a
écrit :

>
> Le 19/12/2012 19:22, Philippe Verdy a écrit :
>
>  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.
>>
>>
> Rien de plus subjectif que les objets "label" : ils sont clairement là
> pour la représentation de l'information, et en premier lieu pour la carte
> ("placer le label", comme tu dis). Ce sont des objets cartographiques plus
> que géographiques, dont la position n'est pas déterminée par la situation
> géographique de ce qu'ils nomment, mais par l'anticipation d'une
> représentation carto. Autrement dit : je place le point label ici plutôt
> que là parce que j'ai en tête comment cela rendra sur une carte. Pour
> l'objectivité...on repassera.
>
>
>  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.
>>
>>
> C'est déjà limite avec les points labels, ça devient flagrant avec des
> lignes label : on n'est plus dans la description du terrain mais dans la
> mise en forme d'une représentation, et par suite, en dehors d'OSM. Ce que
> tu décris a sa place sur une carte (la ligne de base d'un texte, etc.) mais
> pas dans la base _géographique_ OSM. Sans parler du fait qu'une telle ligne
> sera adaptée à une représentation à une échelle (ou plage d'échelles)
> donnée. On est bien là les deux pieds dans la carte.
>
> vincent
>
>
> ______________________________**_________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr<http://lists.openstreetmap.org/listinfo/talk-fr>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20121219/23b5a9a8/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr