P
Le 6 juillet 2013 14:56, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Le 6 juillet 2013 13:44, Yves Pratter <yves.prat...@laposte.net> a écrit : > > > > Mais pourquoi "North Rona", "Sule Skerry", "Sule Stack", "Sula Sgeir"… > > n'apparaissent-elles pas ? > > > > > > Je ne prend en compte que place=island sur les polygones > > > > C'est bien le cas de Chemin : North Rona (28220976) > > > > > > Elle est trop petit pour être sélectionnée. J'ai été obligé de mettre > une limite en superficie sinon des îles non maritimes étaient rendues > (comme celle à Avignon). > > Pas simple ! > > Un solution serait de chercher si des noms de villes se trouvent dans > les environs. Si c'est le cas, on élimine, sinon on garde... mais ça > va nettement alourdir les requêtes. Peut être plus simple: sélectionner les îles ou archipels en fonction de la surface de leur boundingbox et les traiter en catégories différentes. Mettre les grandes iles ou archipels puis les villes puis les autres noms d'îles. Ou alors carrément : sélectionner toutes les iles/archipels et toutes les villes applicables, et les trier ensemble en fonction de la taille de leur bounding box (taille de label incluse). Et commencer par afficher les labels des plus grands objets, et tracer les autres quand il y a de la place non déjà occupée pour leur label. Le problème est toujours d'éviter les collisions de labels. Souvent même s'il y a collision, on peut éventuellement déplacer un label déjà placé pour qu'il reste dans une place encore libre dans sa bounding box (plus grande), en évitant la collision avec le label à placer, sinon on peut chercher s'il y a moyen de déplacer le label du nouvel objet à placer dans un espace encore libre dans sa petite bounding box, et sinon ce label est éliminé. A étudier aussi la possibilté d'abréger un label à placer qui ne tiendrait pas, ou de voir si on peut lui insérer un saut de ligne (sur une espace ou après un trait d'union) pour voir s'il y a encore collision. Idéalament un bon algorithme devrait aussi pouvoir chercher une orientation du libellé lui permettant de tenir en entier dans la surface auquel il est associé. C'est délicat à faire par une requête SQL (qui ne diot servir qu'à sélectionner des listes d'objets candidats), mais plus facile si on peut intégrer des modues géométriques dans le code client. Tout cela n'est en fait pas un algorithme mais une heuristique adaptative (et qui concerne aussi le placement des icônes qu'on ne veut pas superposer à d'autres ou dont on veut qu'elle reste visibles et pas masquées par des libellés). Mapnik travaille actuellement en procédant uniquement par des listes d'objets classées en couches successives sur lesquelles on ne revient jamais ensuite, pourtant au lieu de tracer immédiatement l'objet, il pourrait rester dans une structure en attente conservant des infos sur les contraintes de placement acceptable (notamment sa surface de référence, ou un rectangle d'extension maximum autour d'un point de référence (cela permettrait ensuite de les déplacer après un placement provisoire ou de les réduire par abréviation. L'ennui c'est que plus on accumule d'objets dans une liste d'attente, plus la liste des surfaces occupées se complexifie et prend du temps CPU à tester pour les détections de collision avec les objets suivants. Malgré tout, on n'est pas obligé de tout mettre en attente, car il y a d'évidence des objets qui seront toujours derrière les autres : - les surfaces bleues des mers et rivières toujours derrière les surfaces de landuse ou natural=* et similaires, - eux-même toujours derrière tous les surfaces de bâtiments, - eux-mêmes toujours derrière les tracés linéaires (qu'on peut gérer par un ordre de priorité simple entre clôtures et similaires, puis routes et voies ferrées, puis frontières), puis les noms de rivières et petits libellés affichés discrètement le long des frontières (qu'il est acceptable de masquer partiellement si on peut les répéter plus loin à des distances de rendu raisonnables) - puis les icônes - puis seulement à la fin les autres libellés qui nécessitent un traitement spécial (mais qu'on peut éliminer malgré tout si le libellé tient le long des frontières où il est supposé être déjà présent, ce qui réduit la liste des libellés complexes à placer). Pour réduire la charge du serveur de rendu, il serait même souhaitable qu'il puisse s'épargner du travail en stockant les couches complètement séparables dans des fichiers de rendu en cache séparé (cela pourrait aussi permettre d'avoir dans l'affichage web des cases de sélection des couches qu'on veut voir, par exemple la sélection de la langue des libellés), même si en fin de compte une couche de rendu unique combiné est aussi fabriquée pour faire un fond de carte unique. Cela permettrait aussi de modifier des styles de rendu touchant seulement à une partie, sans avoir à tout replacer, avec des requêtes SQL plus rapides demandant moins de données et de traitements. Souvent le cache en couches séparées pourrait alors utiliser des métatuiles plus grandes en format vectoriel, permettant ce rendu final combiné d'une présélection de couches vectorielles à superposer dans une métatuile bitmap, le cache local pourrait devenir plus efficace car le rendu final d'une superposition de couches vectorielles précalculées séparément est peu gourmand en ressources I/O et CPU, ce qui devrait alors permettre de réduire la taille du cache côté serveur en format bitmap. Il devrait alors même être possible alors d'interroger le serveur de rendu en format vectoriel (il superposerait les couches vectorielles réduites sur une petite boundingbox de clipping, pour produire le SVG combiné transférant peu de données vers Internet, et pourrait le faire à la demande aussi selon les couches sélectionnées dans le client qui ne sait pas faire ce travail). Nombre de smartphones ou petites tablettes savent par exemple rendre des SVG pas trop gros en données rapidement; sur un rendu de 256x256 pixels, le nombre d'objets vectoriels qui y tiennent sera de toute façon limité. pour chaque niveau de zoom, mais il devient alors possible d'avoir des zooms intermédiaires où les libellés gardent leur taille mais s'écartent facilement ou se réorientent aussi selon la direction demandée pour observer la carte. Mais là ce n'est plus du Mapnik comme maintenant (même si Mapnik sait aussi générer du SVG, rapidement en plus sans avoir besoin d'accélérateur graphique, ce dont vos serveurs manquent souvent). On n'exploite pas assez les capacités locales de calcul et de rendu du client web, à l'heure où HTML5 devient de plus en plus omniprésent, alors que les frameworks javascript peuvent déjà demander et afficher des rendus vectoriels (même sans aller jusqu'à demander WebGL pour un rendu 3D, le rendu vectoriel 2D côté client en HTML5 forme déjà une base bien établie et c'est ce que font déjà les petites tablettes spécialisées vendues comme navigateur GPS pour automobile qui font tous du rendu vectoriel depuis longtemps, avec des processeurs pourtant simples et peu de mémoire de travail).
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
