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

[Philippe Verdy]

Le 17 juillet 2013 18:48, Christian Quest <cquest at openstreetmap.fr> a écrit
:

> > Il reste à unifier les styles de polices pour que villes et régions ne
> > mélangent pas caractères italiques et droits sans règle établie (qui
> varie
> > en plus selon le zoom). a mon avis toutes les villes devraient avoir des
> > caratèes droits (n'utiliser les italiques qu'au delà du niveau 8 ou pour
> les
> > noms de pays et régions (en caractères plus grands mais moins contrastés,
> > plus gras aussi mais plus transparents).
> >
>
> Il est normal et souhaitable de faire évoluer la feuille de style pour
> chaque zoom y compris sur les textes.
>

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?

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.

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

-----

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

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

----

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

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.

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.

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

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

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).
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130717/a4ccba86/attachment.htm>