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


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> Il reste à unifier les styles de polices pour que villes et régions ne<br>
> mélangent pas caractères italiques et droits sans règle établie (qui varie<br>
> en plus selon le zoom). a mon avis toutes les villes devraient avoir des<br>
> caratèes droits (n'utiliser les italiques qu'au delà du niveau 8 ou pour les<br>
> noms de pays et régions (en caractères plus grands mais moins contrastés,<br>
> plus gras aussi mais plus transparents).<br>
><br>
<br>
</div>Il est normal et souhaitable de faire évoluer la feuille de style pour<br>
chaque zoom y compris sur les textes.<br></blockquote><div></div></div><br></div><div class="gmail_extra">Peut-être mais quand on commence à avoir des libellés dans un niveau de zoom donné pour des noms de villes, ou de départements ou de régions, les styles mutuels se confondent et se mélangent, les libellés deviennent incohérents entre eux. Si en plus on ajoute des "sous-communes" (comme des quartiers ou lieux-dits), qu'est-ce qui les différencie entre eux?</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">Je veux ben qu'on veuille donner plus d'importance à une grosse ville ou une capitale, mais pas en jouant sur le style droit/italique qui en grande partie sert à indiquer en grand les régions ou départments et plus petits (aux zooms plus avancés où ils apparaissent) les lieux dits et sous-communes. L'importance donné à un libellé doit plutôt jouer sur la taille de police (préférable même aux caractères gras qui ne devraient servir QUE pour quelques capitales administratives, quel que soit leur importance en population.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">LA couleur est aussi une information: les noms de villes et lieux-dits étant en noir non transparent, les objets beaucoup plus grands auront des tailles de police plus grandes mais on peut aussi jouer pour eux sur l'interlettrage, et utiliser une couleur grise plus claire (pour éviter de trop les mettre en évidence), la graisse permettant de garder leur lisibilité, et la semiransparence permettant de garder visible des détails de l'arrière-plan que cacherait trop la mise en gras (ne pas oublier que la lisibilité est aussi maintenue par le halo plus clair qu'on met autour, la semi-transparence n'est pas un problème quel que soit les couleurs en arrière-plan, puisque c'et le halo clair qui contraste déjà avec les caractères).</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">-----</div><div class="gmail_extra"><br></div><div class="gmail_extra">Sinon le bot de mise à jour des admin_level peut se faire aussi en amont avant le rendu Mapnik, même sur ta base locale hors OSM. LE prétraitement toutefois demanderait d'importer les relations frontières différemment : repérer les segments communs de frontière pour ne les tracer qu'une fois et associer alors le min(admin_level) des relations importées à ces traits</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">Attention à certains pièges concernant des frontières qui ne sont pas du tout administratives, mais politiques: cantons, et circonscriptions) car elles ne sont pas toujours alignées sur des frontières administratives et n'ont pas d'admin_level défini non plus, et pourtant elles sont aussi des séparations entre deux zones de même type avec un segment partagé tracé lui aussi deux fois, mais qu'on ne trace pas du tout si le segment est partagé comme frontière administrative (qui prend la priorité).</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">----</div><div class="gmail_extra"><br></div><div class="gmail_extra">Un autre problème est qu'actuellement les frontières sont importées comme des polygones fermés, sinon comme des ways ouverts (anomalies de frontières brisées dans OSM). et qu'ensuite ce sont les polygones qui sont "simplifiés" indépendamment des uns des autres : des segments au départ communs ne le sont plus en passant à l'étape simplification car la simplification ne retient pas les mêmes noeuds (elle part pour chaque polygone d'une noued aribtraire, et parcours les chemins dans un sens ou dans un autre, là où la simplification devrait toujours partir du noeud d'un point trple (extrémité d'un segment partagé), qui doit être gardé, et yojours parcourir les segments dans le même sens (quel que soit le polygone qui l'utilise, alors que les polygones importés sont systématiquement dans le sens trigonométrique, donc les segments sont parcourus en sens opposé par la simplification propre à chaque niveau de zoom).</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Bref ce n'est pas qu'une question de ce qui est dans la base OSM mais de ce qui est importé dans la base locale de rendu: les frontières à dessiner ne devraient pas être importées comme des polygones mais comme des chemins, avec une direction imposée indépendante des (multi)polygones qui les référencent. </div>

<div class="gmail_extra"><br></div><div class="gmail_extra">On peut facilement imposer un sens arbitraire répondant au problème en comparant les coordonnées des deux extrémités, et imposant une direction d'abord nord-sud, sinon ouest-est pour les rares segments exactement horizontaux, et sinon pour les chemins fermés restants (pas de direction déterminable)il suffit de les garder dans le sens antihoraire et imposer que le premier-et dernier point à garder soit celui le plus au nord (sinon le plus à l'ouest). Alors seulement la simplification des tracés donnera un résultat cohérent et peut se faire dans le système de coordonnées du rendu mesuré en pixels.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Et là on peut éliminer les effets indésirables de "pâtés" qui apparaissent par l'accumulation de points trop proches qui zigzaguent autour des mêmes pixels, et qui alors produisent un tracé dont la graisse visible est aléatoire (le tracé visualisé est beaucoup plus gras/épais dans les zones où le modèle source est beaucoup plus détaillé, et fait plus de zigzags, notamment dans les zones de montagne, comme c'est le cas de l'est de la Suisse avec l'Autriche où ces "pâtés" de rendu sont très visibles, et issus directement de l'étape de "simplification" incohérente avant de faire des tracés superposés qui en plus ne passent pas par les mêmes points gardés puisqu'ils sont encore traités actuellement comme des polygones distincts).</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Quoi qu'on fasse dans OSM, le rendu ne pourra pas être idéal si on importe pour Mapnik les frontières comme des polygones fermés. On peut difficielemtn se passer d'importer les frontières toutes comme des polylignes partagées (comme cela devrait être déjà le cas partout dans la base OSM, mais que l'import dans la base de rendu avec osm2pgsql vient briser en compliquant encore plus les choses).</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">L'import des frontières comme (multi)polygones fermés a cependant du sens s'ils servent à remplir les polygones dans une couleur ou une texture donnée, mais les frontières à tracer restent des objets linéaires (sur lesquels les considérations de type "inner/outer" ne doit avoir aucun poids, sauf si on décide d'ajouter un rendu asymétrique tel que le halo vert du côté interne des parcs naturels, ou un halo du bleu au blanc de mise en relief des lignes de côte, l'asymétrie étant justifiée par le fait que les objets de chaque cpoté de la ligne sont différents, ce qui n'est pas le cas des frontières administratives terrestres).</div>

<div class="gmail_extra"><br></div></div>