Le 6 juillet 2013 19:07, Christian Quest <cqu...@openstreetmap.fr> a écrit :
> > 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 > > Et non, on ne peut pas... mapnik ne fonctionne pas comme ça. Je le savais déjà et c'est une limite du modèle de Mapnik dont les "layers" une fois formées sont définitives et ne conservent rien des objets qui ont été placés dans les couches précédentes (notamment pas des infos sur les zones de placement possibles) pusiqu'il en fait le rendu immédiat par dessus les couches précédentes et que c'est définitif (au mieux il peut générer des couches séparées non superposées, mais ne garde rien des tolérances de placement, ce qui rend impossible la résolution ultérieure des priorités par des placements plus judicieux). C'est bien à cause de ça que Mapnik fournit des zones totalement vierges de certaines infos (qu'on a du arbitrairement limiter à des seuils figés indépendamment du contenu réel, pusiqu'on ne sait pas ce que contiendront les couches suivantes). Mapnik a donc ses limites. Mais comme ici on parle des couches finales de libellés (celles tracées en dernier par dessus les autres), on se demande s'il est pertinent d'utiliser Mapnik pour les libellés, et si Mapnik ne devrait être utilisé que pour les couches d'avant (pour produire un fond vierge), quitte à utiliser autre chosie pour générer séparément des couches de libellés utilisant des méthodes de placement améliorées. On pourrait cependant encore utiliser le langage des feuilles de styles actuelles, en y ajoutant aussi d'autres choses comme la possibilité de calculer côté client SQL (et non sur le serveur SQL) des géométries dérivées. Quelques exemples: - le long des rues ont un placement figé alors qu'on devrait pouvoir éviter certaines intersections où ils entrent en collision. Pour résoudre ça, idéalement c'est le segment de rue le plus long qu'il faufrait scinder pour que le libellé de la rue plus courte franchissant le carrefour puisse apparaître, et alors la rue la plus longue aura deux libellés, un avant et un après le carrefour. - le long des frontières, qui sont souvent longues, on n'est pas obligé de se placer exactement au milieu, on doit même pouvoir jouer sur les espaces. De plus à niveau de zoom élevé, on cherche assez loin où est le libellé, s'il y en a un. Les libellés devraient pouvoir être reproduits plusieurs fois à distance raisonnable, et au moins pas trop loin des points triples (point d'intersection de 3 frontières) pour savoir ce que sépare la frontière, en commençant par chercher à placer plus près du point triple les libellés plus locaux qu'on ne pourra pas reproduire plusieurs fois, avant les libellés de zones plus grandes qui ont plus d'opportunités de placement le long de la frontière. - pour les zones naturelles désignant des surfaces étendues comme les noms de massifs montagneux ou d'archipels, ou les noms de mers, on aimerait pouvoir calculer un squelette filaire afin d'orienter le libellé et le tailler de façon proportionnelle, et même pouvoir jouer sur l'écartement des caractères. Le rendu utilisant des lettres assez grandes et grasses pour qu'ils restent lisibles même si on y superpose des libellés plus petits. Actuellement on n'utilise qu'un seul moteur qui est surtout fait pour le rendu des surfaces ou des traits. on pourrait s'arrêter là, et utiliser un rendu exécuté aulleurs. Les serveurs de pavages bitmap pourraient aussi bien demander à télécharger des couches précalculées ailleurs pour créer les pavages et les mettre dans leur propre cache. Ayant peu de choses à faire, leur cache serait plus réactif et prendrait en compte des modifs calculées plus facilement sur plusieurs serveurs. La charge de travail étant distribuée, on augmente la capacités de calcul à moindre frais, on favorise les collaborations, il est possible de distribuer la charge avec des serveurs moins puissants n'ayant pas à gérer le flot de demandes des utilisateurs finaux. Les utilisateurs finaux passent ensuite par des formes de proxy Squid qui interrogent les serveurs faisant l'assemblage des tuiles à la demande avec leur cache local réduit. Et il devient possible d'avoir des cartes OSM affichant de nombreuses langues (on peut dédier des serveurs spécialisés pour faire les rendus de libellés dans des langues différentes. Les possibiltés de réutilisation et de combinaison des contenus sont multiples, OSM devient une offre pléthorique supportée par de nombreux acteurs ayant des moyens différents. Les personnalisations d'apparences et de contenus sont plus nombreuses, et il n'est alors même pas nécessaire de complexifier le code côté client web, qui n'a qu'à choisir parmi pléthore d'offres de rendus précombinés ou pas. Un objet > placé (label, symbole) ne sera plus déplacé, même si on avait une > certaine tolérance de placement d'indiquée. > C'est bien dommage car cela ouvrirai de sacrés progrès, mais c'est à > mon avis pas simple du tout à coder... mais ça vaut le coup de s'y > pencher ! yaka ! Yaka en effet. C'est pourtant ce que doivent utiliser les services carto commerciaux, qui au passage peuvent aussi chacun garder en plus une base locale contenant des préférences de placement réglées manuellement (des préférences qui ne seront utilisées que pour résoudre des conflits automatiques ou pour modifier certains styles, ou adapter localement le contenu du libellé, ou pour indiquer qu'on peut s'écarter de la zone de préférence de placement par défaut en utilisant des flèches ou traits de pointage, ou qui gardent une trace d'un changement manuel de priorité entre deux labels candidats (dont les références sources ont été gardées) dont l'un devra être éliminé du rendu final. Evidemment pour avoir ce genre de base il faut aussi un outil d'édition permettant de visualiser les options possibles et les tolérances précalculées. certaines de ces données seront indépendantes du niveau de zoom exact (par exemple l'orientation du libellé le long d'un tracé précalculé et réglé manuellement, et une série de libellés alternatifs de longueur variable, classables manuellement permettant un choix automatique selon le zoom (certaines abréviations ne sont pas évidentes à calculer automatiquement, c'est très contextuel, l'abréviation étant signifiante selon la zone couverte par le libellé rendu). D'autres critères plus fins permettent de jouer sur les centrages ou alignements des lignes de libellés multilignes. On n'a pas obligation à ce que ces lignes restent toutes centrées, et on peut aussi jouer sur l'interlignage. Concernant les libellés affichés au centre des surfaces, à niveau de zoom élevé, on ne les voit plus ni même le long des frontières trop loin. On ne veut pas non plus surcharger la carte en les répétant plusieurs fois de façon trop rapprochée (exemple : le libellé "RN" de nos zones naturelles issu d'un motif de remplissage). Pourtant il serait parfois utile d'afficher ce libellé en entier au moins une fois dans chaque "métatuile" affichée à son échelle normale; puis rendre ce libellé de plus en plus transparent à mesure qu'on zoome pour qu'il disparaisse progressivement sur des zooms rapprochés (pas le peine de voir "France" partout par exemple, mais on doit le voir au moins à un niveau de zoom où celle-ci est visible en entier à une taille de police suffisante pour que le libellé respecte le style général. Tout ce qu'on reproche souvent à OSM c'est son manque de travail jsutement sur les libellés et c'est là qu'on le distingue des rendus "pro" de type Michelin ou IGN (et même Google lui-même se met à personnaliser les placements selon les échelles de rendu, il a plein de capacité de stockage dans ses bases pour pouvoir le faire à tous les niveaux de zoom, même si ça ne se voit pas dans son interface de "contribution ouverte" proposée à ses utilisateurs à qui on cache la complexité du système, Google employant des personnels formés à ce type de tuning de ses cartes, et des informaticiens pour concevoir des algos de placement plus performants et plus personnalisés selon le visiteur de ses sites web qui depuis juin n'affichent plus les mêmes cartes pour tout le monde). Mapnik c'est très bien mais ça ne suffit plus, et ça demande des ressources trop élevées et trop coûteuses que trop peu de serveurs peuvent offrir. On a eu la tenttive de rendu distribué (@Home) mais cela a échoué parce que les clients le supportant étaient trop peu nombreux mais surtout ne se synchronisaient pass assez ou n'avaient pas la apacité de calcule suffisante pour faire trop peu dans le rendu final, tout en en faisant trop tuile par tuile, ou parce que le travail n'était pas assez bien réparti ni fiabilisé pour que les trop gros retards soient comblés par d'autres contributeurs ou par des serveurs aidant à faire ce travail ou à le maintenir à jour de façon à peu près homogène. Le calcul distribué aurait eu plus de succès en divisant le travail couche par couche et en demandant moins de données sources à traiter. Mais finalement on est revenu au point de départ en reconcentrant le travail sur un tout petit nombre de serveurs à qui on demande de plus en plus alors que les moyens n'évoluent pas aussi vite pour les maintenir à la hauteur des demandes en pleine explosion. Et TOUS les rendus actuels (d'OSM .org ou .fr ou ailleurs, même chez uMap) ont des latences importantes qui rendent le système inutilisable par le grand public hors de zones prédéfinies (avec un support assez pauvre pour les zones rurales). L'homogénéité des cartes en souffre, les anomalies sont alors nombreuses et très longues à corriger le retard ne faisant que s'accentuer un peu partout (on a eu le cas dramatique des lignes de côtes de Bretagne, encore visible sur le rendu Mapnik de Wikimedia des mois après que la correction ait été faite sur la base et même des mois après mise à jour du rendu Mapnik d'OSM; les côtes sont toujours un gros problème lié à un fort goulot d'étranglement de l'architecture générale).
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
