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 <o...@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 <fgou...@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 <fgou...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
