TL;DR (intéresse ceux qui travaillent sur un rendu) Plusieurs points : === 1. maillage pour les "RN" ===
Avec une disposition à mailles carrées orientées à 30 ou 60 degrés on a encore des textures régulières disposables en pavés rectangulaires. c'est souvent un angle pratique pour éviter cet aspect trop mécanique. == 2. Polices de caractères == Autre reproche à faire dans le rendu fr : déjà les polices sont toutes petites, mais en plus les libellés sont pour la plupart en italique. C'est très peu lisible à la résolution utilisée, même avec un rendu anticrénelage du texte, utilisant des pixels à niveau de transparence variable. Pour nos yeux, ce serait bien de soit éviter les italiques (qui ont tendance à condenser horizontalement les textes), soit agrandir un peu les libellés qui sont pratiquement tous trop petits. Ne réserver les italiques que pour les lieux-dits, ou les régions peu géolocalisées (qui devraient s'afficher avec des lettres assez grandes mais transparentes et plus dans des polices plus grasses), pas pour les libellés de points. Pour les fleuves et rivières, les libellés en italique marchent bien car on peut zoomer pour les voir en plus grand et sinon ils disparaissent. Mais pour les noms de communes (niveau 8), même si ils sont dans des polices de taille variable en fonction du type (capitale/chef-lieu administratif ou population ou classification place=city/town/village/hamlet/locality, c'est le rendu qui adapte les tailles), ce serait bien d'éviter les italiques totalement. Et n'utiliser les italiques que pour le niveau 9 ou plus. == 3. Densification des toponymes visibles et autoadaptation selon le zoom == Enfin il faudrait faire quelque chose pour densifier le nombre de libellés de communes visibles dans les faibles niveaux de zoom. L'idée est de faire une sélection de tous les libellés et classer ces noms dans une liste de priorité à plusieurs critères : - le premier niveau de tri de cette liste plus important est le niveau administratif dont la commune est le chef-lieu/la capitale. - le deuxième niveau est la classification (city/tow/village/hamlet/locality) - le troisième, optionnel, est la population indiquée Ensuite le rendu affiche les libellés dans l'ordre de la liste, en les sautant si cela génère des recouvrements ou si un critère de densité maximal est atteint. Pour éviter des recouvrements, le rendu calcule des bounding box pour chacun et les combine en vérifiant que le libellé suivant ne vient pas empiéter dedans (l'algo pourra parfois chercher à les abréger en cas de besoin pour les faire tenir s'ils y a des collisions en utilisant le libellé non abrégé, comme il sait le faire pour des termes communs comme "Rue" => "R.", "Boulevard" => "Bd"). Selon le niveau de zoom, ces libellés doivent aussi n'apparaître que le long de la frontière (si la surface incluse dans la frontière est assez grande, sinon uniquement au "centre" de la zone (qui est soit la position du membre "label" de la relation, sinon la position de son membre "admin_centre", si c'est un noeud, soit le centroïde calculé de son membre "admin_centre" si c'est une surface (ce cas ne semble pas arriver encore en France mais existe dans d'autre pays), sinon le centroïde calculé de la surface. Selon la méthode ou l'autre (le long de la frontière ou uniquement centré dans la zone), les tailles de polices doivent être adaptées (le cas du rendu centré autorise le libellé à déborder largement de sa zone, d'autant plus si le libellé est "important", c'est-à-dire mieux classé dans la liste triée précédente, car il aura une police plus grande qu'un libellé le long d'une frontière, qui doit malgré tout rester lisible aussi avec une taille minimale suffisante). Mais Mapnik permet-il d'inclure un tel algorithme (qui fonctionne pas à pas et non de façon globale sur une liste d'objets présélectionnés et rendus en totalité) ? En SQL on peut générer le tri (avec une requête certes compliquée à faire pour aller chercher les infos sur les statuts de chef-lieu/capitale car l'info est à chercher dans d'autres objets; au pire si le premier niveau est difficile à calculer on peut en SQL le supprimer, mais ce ne sera pas idéal), mais Mapnik peut-il sélectivement "sauter" certains éléments de cette liste triée? En attendant je me désespère de voir les cartes à faible niveaux de zoom aussi vides d'informations utiles, particulièrement en France ou dans les pays avec de larges espaces ruraux (c'est moins un problème pour l'Allemagne, la Belgique ou le Royaume-Uni, ou même l'Espagne, qui sont moins concernés que la France, le Canada, et bon nombre de pays africains). L'algo (très sommaire, je ne code pas pour Mapnik) que je propose est suffisamment adaptatif pour pouvoir avoir une densité suffisante mais pas excessive, permettant de garder des cartes utilisables à tous les niveaux de zoom, et pour rester aussi consistant (Un libellé visible au niveau de zoom N le sera aux niveaux N+1, N+2, etc... au moins sur les frontières s'il disparait du centre de la zone. Ce qui n'est trop souvent pas le cas). Globalement c'est pourtant un tel algo qu'utiliserait (dans sa tête) un cartographe humain, même s'il sait faire des adaptations locales comme : - le rendu avec une flèche, ou jongler avec les sauts de ligne et abréviations pour faire tenir deux libellés proches - modifier l'orientation du libellé (tant pis s'il n'est plus horizontal comme les autres) - voire même en les décalant légèrement (un algo pourrait le faire en utilisant un critère de "tolérance", basé sur la géométrie des surfaces, notamment concernant les "centres" précalculés qui peuvent être décalés tant qu'on reste dans la zone que représente ce libellé, mais même aussi pour les liebllés le long des frontières qui peuvent être décalés sur toute la longueur de la boucle interne). Le 7 juin 2013 11:14, Yves Pratter <yves.prat...@laposte.net> a écrit : > Des RN, mais moins denses... ça doit aller mieux non ? > > Ok, mais alors nettement moins dense, avec une teinte plus transparente, > et disposé si possible en quinconce pour donner un aspect moins "mécanique". > Faire un essai avec un angle un peu différent au texte de la texture ?? > > Il n'y a pas des graphistes / designers sur cette liste ? > > De plus il faudrait les écrire en bleu pour les zones d'eau. > Ok pour le vert pour les zones Verdy ;-) > > > -- > Yves > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
