Le 19 juin 2012 13:09, Pieren <pier...@gmail.com> a écrit : > On essaie d'éviter l'usage du "label" (je ne suis même pas sûr qu'un > logiciel quelconque en tienne compte pour le moment). D'habitude, le > centroïde calculé par les logiciels de rendu est suffisant.
Pas toujours suffisant quand des zones sont non connexes (avec des exclaves éloignées) ou fortement concaves (y compris celles dont une enclave couvre la position du centroïde calculé...) Le label sert alors à trouver un meilleur endroit (au moins pour centrer le label dans la plus grande exclave ou la plus représentative du lieu, parce que certaines zones ont leur centre administratif pas dans l'exclave la plus grande... Aucun algorithme ne pourra le deviner à partir de la géométrie globale de l'objet). Pour les communes, la position de l'admin_centre suffit pour positionner le label de cette commune. Pour les autres zones dont le centre adminitratif est au même endroit il est souvent plus approprié de positionner le label de cette zone ailleurs, plus proche du centroïde de l'exclave qui contient ce centre administratif commun. On peut voir aussi que des zones éclatées en plusieurs exclaves nécessitent autant de labels (identiques dans leur libellé affiché qui dans l'idéal serait le libellé provenant de la relation pour éviter les redondances) que d'exclaves. Un label ne sert donc finalement qu'à indiquer un seul noeud qu'il n'est pas nécessaire alors de taguer lui-même: seule la référence du/des labels en tant que membres (avec le rôle label) d'une relation suffira alors. A priori il n'y a non plus aucune raison de discriminer une exclave plutôt qu'une autre. Ensuite, si les moteurs de rendu tiennent compte ou non de la position du/des labels peut se débattre. A mon avis seules leurs positions en tant que nœud devrait suffire. Pourtant dans l'idéal, on devrait même pouvoir désigner comme "label" un chemin non fermé (pour que le label vienne s'afficher dessus en suivant le trait de contour voire aussi son orientation, ce qui permettrait de donner un espacement des caractères, et aussi d'indiquer une distance de "buffer" permettant de dimensionner les lettres. Cela produirait des labels esthétiques pour les massifs montagneux, dont les contours sont assez flous, les régions... Et dans tous ces cas, les moteurs de rendus auraient alors moins de contrainte pour positionner de façon lisible et claire ces labels couvrant des zones assez étendues, dans un style qu'ils veulent (ils peuvent jouer sur les polices, couleurs et transparences ou des effets sur le lettrage, sans qu'on ait à déterminer non plus à l'avance une taille en points ou en pixels (ce qui n'a pas grand sens car cela dépend du nveau de zoom et du rendu spécifique de ce niveau de zoom par un moteur donné). Le but du jeu étant seulement de fixer des contraintes acceptables et pas trop limitatives comme peut l'être la contrainte du nœud unique (qui n'est pertinent que pour positionner et centrer un symbole ou une icône comme un cercle ou une étoile, mais très peu pour positionner le lettrage du libellé dessiné à côté (mais on ne sait pas trop où sur la carte). Avec une contrainte davantage orientée vers la surface (contour orienté plus indication d'une distance de buffer) on donne assez de liberté au moteur de rendu pour qu'il puisse même couper un libellé sur plusieurs lignes, si cela occupe mieux la place indiquée. Classiquement on s'attend à ce que les noms de villes et lieux-dits soient écrits horizontalement dans une taille prédéterminée indépendante de la surface de la zone; mais pour libeller les baies, les massifs montagneux, les régions d'une carte des départements, les plages, les réserves naturelles, et les régions naturelles, plus de liberté de placement serait préférable (et ce n'est pas un centroïde calculé qui donne cette liberté, pas plus qu'un simple noeud désigné comme label. En revanche je suis plutôt opposé à ce qu'on tague dans OSM les noms de familles de polices, les tailles, styles et couleurs de caractères. Ca n'a pas grand sens et sera trop spécifique des choix de style d'un moteur de rendu particulier. Pas plus que les couleurs et styles de traits à donner pour les routes, voies ferrées et autres transports d'énergie et de n'importe quel autre libellé. Pas plus non plus que les icônes à utiliser (que ce soit par une URN ou une URL, ou par des données d'image encapsulées dans une chaine). _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
