[OSM-talk-fr] Rendu FR, bientôt en version 2017 !

Ven 23 Déc 17:23:20 UTC 2016

Au même endroit si on dézoome, on tombe sur l'Hebergement, dont le
placement semble vraiment trop à l'ouest sans que ce soit justifié.

Pourquoi par défaut les libellés ne sont pas centrés sur la commune mais
affiché à l'ouest (alignement à gauche) ou à l'est alors même qu'il n'y a
aps de collision en le plaçant au centre ? Cela donne un emplacement
contre-intuitif. A moins qu'il y ait des collisions à éviter, le centrage
devrait être l'option par défaut, avec un décalage possible vers l'ouest ou
l'est (ou un peu vers le nord ou le sud) tout en gardant le rectangle
occupé par le libellé si-possible à une position contenant le point central.

Si le libellé est accompagne d'une icone en revanche (un cercle, un disque,
une étoile...) ce libellé devrait être aussi placé de préférence au nord ou
au sud de cette icone (pour éviter autant que possible de la couvrir, mais
ce n'est pas une obligation: si le placement à l'ouest ou à l'est de
l'icone provoque et décentrage trop distant, il est possible malgré tout de
recentrer le libellé même si cela recouvre l'icone, s'il faut faire de la
place pour un libellé voisin.

Un bon moyen serait de procéder en deux passes: dans une première passe les
libellés sont calculés avec une taille correspondant à leur version non
abrégée générant le rectangle le plus grand on enregistre ensuite son point
central préférentiel (qui pourra être ensuite décalé pour le maintenir dans
son rectangle de définition. Si un libellé ultérieur a besoin de place, il
peut décaler le centre des libellés voisins pour qu'il reste dans leur
rectangle de définition, puis ce rectangle de définition est réduit pour
qu'il n'aille plus recouvrir la place prise par un autre libellé voisin
(noter que les icônes sont placées en premier pour occuper leur place)
chaque libellé a donc un rectangle préférentiel de placement qui de proche
en proche va se réduire. Si on manque encore de place, un libellé peut
ensuite être converti en version abrégée, en utilisant les "short-name" si
disponibles, puis les abréviations courantes de termes connus comme
"Saint(e)", "Général", "Avenue", "Boulevard" si cela permet de réduire leur
taille (tout en faisant que ce libellé ne sorte pas de leur actuel
rectangle de définition, doinc en faisant attention à conserver des sauts
de lignes suffisants).

Le tracé des libellés ne se fait que dans une seconde passe après les avoir
tous placés (là où il n'y a pas de collisions possibles dans la tuile
courante ou dans une tuile limitrophe où ce libellé serait partiellement
tracé: la zone, de calcul de placement des libellés est donc plus large que
la tuile que l'on est en train de tracer, mais ce n'est pas nouveau et ne
concerne pas que les libellés mais aussi le tracé des routes du fait de
leur largeur, ou des icônes de tout type qui peuvent être elles aussi à
cheval sur des limites de tuiles: les requêtes à la base doivent inclure
une marge plus grande autour de la tuile à tracer pour être certain d'avoir
tous les objets, y compris ceux qui pourraient être décalés de leur
position centrale idéale, ce décalage étant plus grand pour les libellés
que pour les icônes ou routes qui ont un placement fixe).

Autre chose à voir: les libellés non horizontaux qui suivent les noms de
fleuves ou les frontières (voire les noms de chaines de montagne si on veut
les voir ou les noms de petites mers): leur placement dynamique (le long
d'un chemin) est nettement plus compliqué car il se fait dans un polygone
calculé par un buffer autour du chemin dont on doit trouver des zones non
occupées par d'autres libellés... pour les noms de chaines de montagnes (ou
glaciers, parcs naturels...) toutefois une solution est de les afficher en
grand caractères mais semi-transparents et gras, qui peuvent alors entrer
en superposition avec les autres zones de remplissage ou les libellés et
icônes tracés par dessus; le système pourrait servir aussi à libeller les
grandes régions ou les pays en fonction de leur superficie relativement à
celle de la tuile à l'échelle de rendu donnée). Ce système de libellés
semi-transparents (en arrière-plan des autres libellés pourrait autant
servir à placer des noms de quartiers sur des échelles montrant les rues
d'une ville. Mais la question de lisibilité de ces libellés
semi-transparents dépend des choix de couleurs et tailles et graisse de
police utilisées: si la police est trop grande de tels libellés ne doivent
plus être utilisés et au passe aux libellés tracés en petits caractères le
long des frontières ou le long du chemin central d'un cours d'eau.

Le placement des libellés est encore non optimal et devrait faire l'objet
de recherches avec de meilleurs heuristiques (sans compter que pour des
libellés jugés "importants", s'il n'est pas possible de les afficher à
cause de collisions, il reste la solution des libellés "fléchés" pour leur
trouver une autre place sortant de leur cadre de définition initia, exemple
pour placer Monaco à côté de Nice, Nice étant beaucoup plus gros, mais
n'étant pas une capitale comme Monaco: cette solution de libellés fléchés
sert surtout pour les bas niveaux de zoom, et ne peut être utilisée que si
on a mis au point des critères "d'importance": qu'attend on de voir en
premier: le nom d'une ville ou le nom d'un pays? Cela dépend de l'échelle
et du rendu d'objets de même types mais de taille géographique très
différente)

Le 23 décembre 2016 à 17:15, Stéphane Péneau <stephane.peneau at wanadoo.fr> a
écrit :

> Je vois que le nom des communes fusionnées est visible, même s'il n'y a
> pas de node place dans la relation. Super !
> Par contre, on ne voit ce nom qu'à partir du zoom 14, bien après les
> "place" de la commune en question.
> Est-ce qu'il ne serait pas mieux que ça soit visible avant ?
>
> exemple : (il faut zoomer d'un cran pour voir "Montréverd")
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#13/46.8993/-1.4205
>
> Stf
>
>
>
> Le 23/12/2016 à 16:46, Tony EMERY a écrit :
>
> N'oublies pas le rendu des terrains de motoball...
>
> Le 23 déc. 2016 16:24, "Christian Quest" <cquest at openstreetmap.fr> a
> écrit :
>
>> Les derniers changements:
>> - les entrance=* ne sont rendus si ce sont des entrées de bâtiment ou si
>> ce ne sont pas des entrées de pièce... avec de la bidouille dans la requête
>> pour retrouver cette info !
>>
>> - les lignes des terrains de sport: plus de rendu si il ne s'agit pas
>> d'un leisure=pitch, et rendu possible de plusieurs sports (mais un peu
>> fouilli au final... à voir)
>>
>> - les shop=* en souterrain sont estompés, prise en compte du tag
>> location=underground en plus de level<0
>>
>> Et grosse refonte de fond du projet avec passage du format json au yaml
>> plus lisible (et maintenable)... qui ne devrait pas avoir d'incidence sur
>> le rendu sauf bug de conversion !
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> _______________________________________________
> Talk-fr mailing listTalk-fr at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20161223/3ee4e449/attachment.htm>