[OSM-talk-fr] Amélioration rendu "FR" sur les zooms faibles...

[Christian Quest]

Le 6 juillet 2013 20:12, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
> Le 6 juillet 2013 19:07, Christian Quest <cquest at 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.

La solution: placer les noms des rues courtes (plus difficile à placer
donc) en premier...

ainsi que de fusionner les différents ways qui portent le même nom de
rue (je le fais aussi)


> - 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.


Logiquement, le nom doit être répété à intervalle régulier, ça se
règle aussi, comme pour les noms des rues / routes qu'on répète, en
tenant compte aussi de la taille d'un écran qui sert à consulter la
carte, car c'est ça qui dicte la fréquence à laquelle il faut répéter
les noms.


> - 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.
>

Oui, ça serait un plus et ça peut se générer via postgis.

Beaucoup de choses peuvent être pré-calculées, ce qui donnera plus de
latitude que le fichier de config mapnik.

L'exemple du rendu des terrains de sport est un bon exemple, tout le
boulot est fait en amont, dans postgis (et à la volée).


Pour le reste... mapnik n'a pas de problème de performances.
C'est essentiellement postgres et le très gros volume de données à
traiter qui rend les choses compliquées.

Mappy utilise mapnik et en est très content. Ils ont par contre un
gros boulot de prétraitement.

Ce que nous faisons est assez peu courant: une carte qui se met à jour
en temps quasi réel... et avec des données de toutes échelles.
On ne s'en sort pas si mal.

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/