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 <[email protected]> a écrit : > Le 19 décembre 2012 15:25, Ab_fab <[email protected]> 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 >
_______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
