Le 12 février 2012 13:10, Hélène PETIT <h...@free.fr> a écrit : > ...où en est la modif de mapnik qui n'écrit pas le nom de la commune au > barycentre de la zone quand il y a un admin-centre dans la relation, merci ?
Mapnik ne le fait plus... sauf si la zone est éclatée en plusieurs parties séparées, auquel cas il continue de mettre un label au centre de chacune des sous-zones contigues incluent dans la même relation. De plus ce n'est pas l'"admin_centre" qui détermine ça, puisque le nom de l'admin_centre est très souvent différent de celui de la zone définie par la relation, l'admin_centre mentionne le plus souvent le nom de la commune chef-lieu, et ne correspond à la relation QUE quand la relation est une commune (admin_level=8) : il n'y a que dans ce cas-là que les deux noms font alors (éventuellement) doublons. Enfin la position du chef-lieu ou siège (admin_centre) d'une zone plus grande que la commune n'est franchement pas idéale non plus pour positionner le nom de la zone, pour laquelle Mapnik a raison de placer le label de chaque sous-zone au centre de la zone. Là où je suis moins d'accord, c'est quand Mapnik mentionne le nom de la relation EN MÊME TEMPS avec un label central (ou repositionné avec un rôle 'label" dont les tags de nom n'a aucune importance et est inutile, sachant qu'il n'est alors pas idiot d'avoir plusieurs noeuds membres avec le rôle "label", si une zone contient des exclaves), ET tout le long des frontières. Il devrait pouvoir choisir directement en fonction de l'échelle, selon la place prise par un label central (préférable à faible niveau de zoom quand il est illusoire de vouloir représenter des contours trop petits, le label recouvrant alors une zone plus grande que la zone) par rapport à celle prise par le label affiché sur la frontière (préférable si la représentation de cette frontière est assez longue pour y afficher un libellé). " D'ailleurs le choix des labels multiples qui apparaissent sur les frontière est actuellement complètement stupide, de même que Mapnik ne sait toujours pas placer ces labels du bon côté et insiste pour les mettre tous au milieu de cette frontière, en choisissant parmi eux de façon complètement aléatoire... De même Mapnik ne sait toujours pas dimensionner ou orienter correctement ses labels "centraux": on peut l'aider à le placer avec le rôle "label", mais uniquement sur un noeud "central" et pas le long d'un chemin éventuellement oblique ou courbe. Tous les labels sont alors affichés avec la même taille, horizontalement, sur une largeur "idéale" à priori arbitraire pour couper les mots sur plusieurs lignes. Pour moi, le rôle "label" ne sert qu'à ça : mieux positionner les labels, mais même pas pour désigner le ou les noms à afficher. Ces rôles "labels" devraient être stockés dans la base Mapnik (pas dans la base OSM principale), et y avoir des attributs de taille, couleur, style, et de sélection (ou non) selon le niveau de zoom rendu (un label central apparaitra à un niveau de zoom d'un certain intervalle, mais pas à niveau de zoom trop faible, où rien du tout ne sera affiché, ni à niveau de zoom élevé, où le label central et de position ajustée sera remplacé par des labels de frontières). De ce point de vue-là, Mapquest fait nettement mieux ! La seule motivation pour qu'un "label" (stocké dans la base associée au moteur de rendu) utilise un nom différent des noms de relations OSM, serait qu'un moteur de rendu particulier ait besoin d'une version abrégée des noms stockés dans une relation OSM (avec les tags "name" et "name:*" pour les traductions, "alt_name:*" pour les trouver un noms alternatifs par exemple avec Nominatim, "official_name:*" pour les noms formels rarement représentés sur une carte mais parfois utile au rapprochement de bases de données externes, "old_name:*" pour les anciens noms, etc...), et pour y ajuster la position des sauts de ligne en cas de besoin, voire représenter ces labels sous une forme enrichie par exemple en HTML (sous-éléments en exposants, ou en plus petits caractères...). C'est dans ce cadre là qu'il va vouloir ajuster (et stocker) des préférences de placement, ou vouloir afficher un label le long d'une courbe, ou avec des caractères plus ou moins espacés. Alors je veux bien qu'on ne tague pas pour le rendu, pourtant un moteur de rendu a bel et bien besoin de calculer et conserver ses tags bien à lui pour produire une carte lisible, et permettre d'altérer ce que le placement automatique a mal déterminé : la base OSM ne suffit pas, MÊME avec les meilleurs heuristiques de placement automatique (car il n'existe PAS d'algorithme dès qu'il y a des collisions possibles de labels pour des objets voisins différents ou d'étendues géométriques très différents, ou d'importance relative différente, les critères de sélection et de placements dépendant ce chaque type de rendu de carte et de chaque échelle). _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
