[OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

Lun 4 Déc 22:35:19 UTC 2017

On n'a toujours pas de serveur de tuiles vectorielles pour donner les noms
? Ce serait nettement plus pratique en n'ayant qu'à fabriquer les tuiles
bitmaps pour les fonds de couleurs, les traits... (resterait cependant le
problème du placement des libellés traduits : ce serveur de tuiles ne
donnant que les noms devraient pouvoir indiquer des priorités de placement
(calculé à partir de critères d'importance). Mais le rendu final côté
client devrait cependant tenir compte de la résolution effective du client
(pour tailler les polices convenablement et lisiblement, puis ensuite
déterminer leur taille, faire le découpage multiligne et les césures
éventuelles, calculer une bounding-box et une marge suffisante
d'occupation, pour ensuite arbitrer les libellés qui peuvent tenir à
l'écran : le serveur de tuiles vectorielles devrait indiquer un point
central de référence et une bounding box maximale permettant de décaler le
libellé pour qu'ua moins 50% de sa taille de rendu soit dans la
bounding-box, ce qui permet de les bouger un peu et faire de la place).

Mais autre problème: les libellés ne sont pas toujours horizontaux mais
alignés le long d'une ligne de base polygonale (noms de
rues/routes/chemins, fleuves/rivières, frontières) et soit centré dessus
(rues/routes/cours d'eau), soit au dessus soit en dessous (frontières).

Dernier problème de taille: pour les grands zooms, les noms affichés le
long des frontières sont préférables car on n'a pas de visibilité sur
l'emplacement central trop éloigné. Pour les niveaux de zoom fins, ces noms
le long des frontières ne tiennent plus et sont mieux rendus au point
central de la surface. Mais là encore cela dépend du style final de rendu
selon la résolution du client et le serveur ne peut pas le décider avec un
rendu client vectoriel.

On trouve ces implémentations côté client dans certains navigateurs GPS,
mais à cause de la complexité de ce rendu, il est en fait encore souvent
précalculé sous forme de bitmap compressé dans sa base de données interne
(la compression fonctionne bien car il y a peu de couleurs ou c'est
monochrome et la résolution est connue et les tailles de police sont alors
précalculées de même que leur placement, leur orientation. Les navigateurs
GPS modernes disponsant d'un rendu 3D font tout en vectoriel et permettent
de zoomer et un rendu 3D en perspective avec parallaxe, et même un rendu 3D
réorientable selon la boussole sans que les libellés tournent (sinon ils
sont difficiles à lire en conduisant) et tenant compte des préférences de
l'utilisateur en terme de taille de police et aussi en terme de contraste
et styles (ou d'éléments à afficher/cacher).

Ces navigateurs GPS restent des petits appareils légers et y arrivent. Un
rendu vectoriel optimisé devrait donc pouvoir fonctionner très bien dans un
navigateur en WebGL avec un peu de javascript: on a ça déjà dans les rendus
3D pour OSM (F4Map). On aimerait avoir ça maintenant en 2D partout (ce qui
est normalement bien plus simple qu'en 3D). Bref on attend tous un rendu
vectoriel (comme le font déjà Google ou MapBox) pour en finir avec les
vieilles et lourdes tuiles bitmap (si compliquées à raffraichir et qui
consomment beaucoup de bande passante à l'usage surtout pour les
applications mobiles).

Le 4 décembre 2017 à 22:08, Maël REBOUX <osm at breizhpositive.bzh> a écrit :

> Bonjour,
>
> Pour 1 et 2 : c’est un projet qui suit son cours.
> Des nouvelles 1er trimestre 2018.
> ;)
>
> Merci pour le pointage de ce compte.
>
> A galon / Cordialement,
>
> Maël  / www.openstreetmap.bzh
>
>
> Le 4 déc. 2017 à 01:36, Francois Gouget <fgouget at free.fr> a écrit :
>
>
> Je suis tombé sur un changeset qui ajoute des noms en Occitan dans
> name:oc, ce qui est bien, et dans le champ name avec un '/' ce qui est
> moins bien. Donc j'ai laissé un commentaire sur le changeset et pour ne
> pas perdre l'information, le voici :
>
> https://www.openstreetmap.org/changeset/52321720
>
>
>
> D'ailleurs à propos de serveurs dédiés pour telle ou telle langue
> régionale, plutôt que d'avoir chaque communauté qui monte son propre
> serveur et gère sa propre infrastructure en doublon, serait-il possible :
>
> 1. Soit de juste mutualiser les ressources entre les différentes
>   communautés.
>
> 2. Soit de carrément monter un seul serveur qui couvrirait la France
>   entière, et rien que la France, et qui ferait un rendu avec les noms
>   en Breton pour la Bretagne, en Alsacien pour l'Alsace, en Occitan
>   pour l'Occitanie, et en Basque pour le pays Basque.
>
>   Bon, je suppose que pour le Basque il faudrait aussi couvrir une
>   partie de l'Espagne. Voir couvrir toute l'Espagne et ajouter le
>   Catalan tant qu'on y est.
>
>   Mais est-ce qu'il y aurait des zones où on aurait des conflits entre,
>   par exemple, les noms Basque et Occitan ?
>
>   Et est-ce que cela conviendrait aux différentes communautés où est-ce
>   que leur but est aussi d'afficher les noms partout en France (par
>   exemple Paris) / dans le monde dans leur langue ? Je note que le
>   serveur Breton ne couvre que la Bretagne par exemple, et que donc
>   cette approche ne serait pas donc immédiatement vouée à l'échec.
>
>   Est-ce que cela simplifierait la gestion par rapport à l'option 1 ?
>
>
> --
> Francois Gouget <fgouget at free.fr>              http://fgouget.free.fr/
>      Any sufficiently advanced bug is indistinguishable from a feature.
>                            -- from some indian
> guy_______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://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/20171204/3ce2a962/attachment.htm>