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

[Philippe Verdy]

Le 6 juillet 2013 20:29, Christian Quest <cquest at openstreetmap.fr> a écrit :

> La solution: placer les noms des rues courtes (plus difficile à placer
> donc) en premier...
>
Problème : une fois qu'on a placé toutes les petites rues traversales d'une
avenue, on n'a plus de place pour le nom de l'avenue coupé trop souvent.

Cela veut dire plutôt pouvoir placer les nom de l'avenue en ardant l'info
sur ses noeuds de début et sa fin sur le chemin, puis tenter de placer les
rues plus courtes (en commençant par les plus longues; seulement s'il reste
de la place pour couper davantage le nom du plus long segment de rue.

Chaque fois qu'on découpe une avenue plus longue rue en deux parties, on
s'assure de garder au moins un nom sur le premier et le dernier segment de
l'avenue.

Une fois que toutes les rues sont découpées par celles plus courtes qui les
traverse, on rebalaye la liste des segments composant une rue pour voir
ceux qui assez éloignés entre eux, peuvent reproduire le nom davantage: on
repère ceux des segments intermédiaires qui sont assez longs (on élimine
les autres segments intermédiaires, et on répartit ces noms autant de fois
que nécessaire pour éviter de trop grands écarts entre eux.

Tout ça ne peut pas se faire dans le SQL, et nécessiterait un code plutôt
du coté du client SQL du moteur de rendu. Donc quelque chose comme un
plugin gérant des règles supplémentaires de placement, que les options
actuelles de Mapnik ne peuvent pas gérer avec une requête SQL unique avec
une priorité unique et un simple tri ORDER BY fait en SQL, même augmenté
des fonctions d'extension GIS. Ce genre de traitement ne rentre pas dans le
langage compris par les extension GIS. Cela demanderait à Mapnik de
supporter des listes d'objets personnalisées modifiables par code. Sans
doute avec un langage de script, intégré par un plugin hôte de VM de type
Python, Lua, PHP, Javascript (voire Java si on y intègre la compilation de
classes à la demande), et muni des bindings nécessaires pour accéder à
l'API de Mapnik, ou permettant à Mapnik d'exposer ses objets au plugin hôte
du langage de script....

Toutes les listes d'objets manipulées par un tel plugin seraient
modifiables tant qu'elles sont dans le même "layer" de Mapnik, et
éventuellement le script exécuté par le plugin pourrait faire aussi
d'autres requêtes SQL complémentaires (pour éviter à la sélections initiale
de faire trop de traitements pour récupérer des données dont l'utilité ne
sera déterminée qu'à l'exécution du script selon ses propres règles.

Quand le script se termine, il reste des listes d'objets, auquel le script
a attribué des noms symboliques de classes, qu'on peut ensuite styler avec
le langage de style existant de Mapnik (un langage que le script peut aussi
contrôler en générant ses feuilles de style). Le script se termine, la
liste d'objet peut être conservée pour les layers suivants si le script le
demande. Le script pourrait aussi utiliser son propre stockage SQL dans des
tables complémentaires si cela facilite les requêtes SQL des layers
suivants.

Chaque layer Mapnik en fait ne serait pas obligé de tracer les objets
immédiatement sélectionnés, ils peuvent être gardés par le script propre au
layer qui peut les garder dans un état encore modifiable. Et il doit encore
être possible d'ajouter des layers Mapnik sans sélection SQL depuis les
données géographiques mais depuis les données complémentaires insérées lors
du travail des scripts dans la base SQL sur des tables de travail. On n'est
plus limité du tout alors par la division arbitraire en listes de priorités
basées sur l'ordre des layers, qui n'est plus qu'un ordre d'exécution des
requêtes de sélections de données, et plus un ordre d'affichage imposé.

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

Mapnik est conçu pour générer un rendu à une échelle bien définie. La
tailel de l'écran importe peu car ici on travaille dans le système de
coordonnées du rendu et non plus dans le système géographique. On a donc
des mesures en pixels (ou pixels logiques) y compris pour les tailles de
polices utilisées, les épaisseurs de traits, les tailles d'icônes. etc.
Mpanik devrait s'occuper déjà de changer la projection initiale (en
longitude, latitude WGS84) dans la projection 2D du rendu (voire 3D si on
lui doit convertir des tags comme ele=* spécifiés à prirori en mètres et
non dans l'unité du système de coordonnées de la tuile de rendu)

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


PostGis veut dire le calcul de géométrie intégré au système géographique.
Cela ne marche pas ici puisuq'on travaille dans la projection du rendu
final, dépendant directment de la résolution/l'échelle des tuiles.

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


mais un exemple déjà très compliqué à mettre en peuvre alors qu'il n'y a
strictement aucune règle de placement à gérer ni changement dans les listes
de priorités

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


C'est bien ce que je dis, PostGIS (intégré au SQL) ne marchera pas, alors
que Mapnik intègre lui aussi (déjà) sa propre bibliothèque de géométrie,
pour ce qu'on ne fait pas en SQL.


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


Oui en particulier ils font du tuning manuel de leur base pour leur propre
rendu. Ce qu'on ne fait pas dans la base OSM même importée via osm2pgsql.
Tout le prétraitement en amont nécessite pourtant un code complètement
séparé. Alors qu'un langage de script intégré à Mapnik permettrait de le
faire directement au sans du code pour chaque layer, et de bénéficier aussi
de l'accès aux règlages des feuilles de style pour un traitement plus
adaptatif, et certainement moins de prétraitements inutiles.


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


Mais on n'est pas seul. Google démontre sa capacité à adapter ses cartes
réellement en temps réel, et même utilisateur par utilisateur (mais certes
il a de gros moyens sur ses serveurs, et en tire des revenus pour les
financer tant en développement, qu'en déploiement et maintenance, et aussi
pour le promouvoir par des conférences couteuses, beaucoup de personnel et
beaucioup de dépenses marketing pompeuses pour rebaptiser ce qui existe
déjà ailleurs et faire croire qu'il y a une innovation).

Là dessus OSM doit pouvoir chercher à inventer des solutions nouvelles tant
dans ses outils que dans son infrastructure et ses coopérations évoutives,
au lieu de se retrouver prisonnier de solutiosn serveurs de plus en plus
étranglées et qui ont de plus en plus de mal à ternir la charge.

Je ne crois pas que Mapnik puisse résister longtemsp dans sa forme
monolithique actuelle, et qu'il faudra passer par des cotraitements ou des
moteurs de rendus multiples peuvent collaborer et se partager le travail
autrement que simplement en se répartissant les tuiles à calculer
(répartition horizontale seulement), mais aussi par un découpage vertical
du travail (séparation des couches, production des tâches secondaires,
déploiement non pas vertical mais en arbre, avec rendez-vous, caches
intermédiaires, redondance, etc. Permettant à de plus petits serveurs aussi
de produire une partie des résultats pour des unités de travail plus
limitées, adaptées à leur propre capacité, et eux-mêmes travaillant en
concurrence (par compariason des choix faits et des meilleurs résultats
obtenus, puis échange des codes libres et ouverts mis en oeuvre si on veut
un déploiement à plus grande échelle et bénéficier des retours d'expérience
des défauts actuellement constatés). On doit chercher tous les moyens de
résoudre les goulots d'étranglement actuels  (notamment en capacité de
calcul des serveurs, comme dans leur bande passante nécessaire, trop
centralisés et rendant le système très fragile).
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130707/4a55cd43/attachment.htm>