[OSM-talk-fr] Cartographier une zone industrielle

[Philippe Verdy]

Le 19 juin 2012 13:09, Pieren <pieren3 at 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).