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

[Christian Quest]

Le 7 juillet 2013 00:13, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>
>
>
> 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é.

Yaka


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

Mapnik fonctionne déjà comme ça. On raisonne en pixels et pas en
coordonnées qui en général ne sont même plus stockées en WGS84 mais
reprojetées par osm2pgsql en Google Mercator, justement pour
simplifier le travail de mapnik.
Donc pour une répétition de nom, on indique tout les combien de pixels
elle doit se faire... afin qu'on ai un bout de nom à l'écran (d'où le
rapport avec la taille d'affichage).

Tes réflexions sont intéressantes, mais tu devrais étudier un peu plus
sérieusement le fonctionnement d'une chaine classique osm2pgsql/mapnik
plutôt que de réinventer ce qui existe déjà.


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

Pareil que ci-dessus


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

Oui, c'est juste un exemple. Un autre basique alors... le fait de
trier les objets de la façon la plus cohérente possible via la requête
SQL permet d'avoir un placement plus cohérent.
Certe, les objets ne sont pas repositionnés, mais c'est un truc auquel je pense.


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

Mapnik gère juste de moins grand paquets de données à la fois, c'est
la principale différence.
Si on optimise côté postgres, ça marche plutôt bien aussi. Exemple, le
zoom 5 est passé de 52' à moins de 2 en créant quelques index et en
revoyant les requêtes SQL pour en tirer partie.


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

Rien n'empêche de le faire, c'est juste que personne ne s'y est
intéressé jusqu'à maintenant.

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

L'avantage du prétraitement, c'est que le résultat est stocké en base.
Un scripting fait au moment du rendu devrait être refait à chaque
génération de la même tuile... ce qui me semble moins efficace.
L'autre avantage c'est que le résultat du traitement est facilement
vérifiable, il suffit d'interroger la base, alors que pour le
scripting je vois la complexité actuelle à comprendre pourquoi on
obtient tel résultat au lieu de celui attendu. C'est vrai que pour ça,
il faut avoir mis les mains dans le cambouis pour y être sensible.

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

Yaka



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