<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">Le 6 juillet 2013 20:29, Christian Quest <span dir="ltr"><<a href="mailto:cquest@openstreetmap.fr" target="_blank">cquest@openstreetmap.fr</a>></span> a écrit :<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">La solution: placer les noms des rues courtes (plus difficile à placer<br>
donc) en premier...<br></blockquote><div style>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.</div><div style>

<br></div><div style>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.</div>

<div style><br></div><div style>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. <br><br></div><div style>

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

</div><div style><br></div><div style>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....</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>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é.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Logiquement, le nom doit être répété à intervalle régulier, ça se<br>
règle aussi, comme pour les noms des rues / routes qu'on répète, en<br>
tenant compte aussi de la taille d'un écran qui sert à consulter la<br>
carte, car c'est ça qui dicte la fréquence à laquelle il faut répéter<br>
les noms.<br></blockquote><div> </div><div style>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)</div>

<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> - pour les zones naturelles désignant des surfaces étendues comme les noms<br>
> de massifs montagneux ou d'archipels, ou les noms de mers, on aimerait<br>
> pouvoir calculer un squelette filaire afin d'orienter le libellé et le<br>
> tailler de façon proportionnelle, et même pouvoir jouer sur l'écartement des<br>
> caractères. Le rendu utilisant des lettres assez grandes et grasses pour<br>
> qu'ils restent lisibles même si on y superpose des libellés plus petits.<br>
><br>
<br>
</div>Oui, ça serait un plus et ça peut se générer via postgis.</blockquote><div><br></div><div style>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.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Beaucoup de choses peuvent être pré-calculées, ce qui donnera plus de<br>
latitude que le fichier de config mapnik.<br>
<br>
L'exemple du rendu des terrains de sport est un bon exemple, tout le<br>
boulot est fait en amont, dans postgis (et à la volée).</blockquote><div><br></div><div style>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 </div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Pour le reste... mapnik n'a pas de problème de performances.<br>
C'est essentiellement postgres et le très gros volume de données à<br>
traiter qui rend les choses compliquées.</blockquote><div><br></div><div style>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Mappy utilise mapnik et en est très content. Ils ont par contre un<br>
gros boulot de prétraitement.</blockquote><div><br></div><div style>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ce que nous faisons est assez peu courant: une carte qui se met à jour<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


en temps quasi réel... et avec des données de toutes échelles.<br>
On ne s'en sort pas si mal.</blockquote><div><br></div><div style>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).</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>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).</div>

<div style><br></div></div></div></div>