Personnellement je suis plus en faveur du rendu bitmap des surfaces colorées de fond (avec un dégradé progressivement plus pâle pour les faibles niveaux de zoom afin de masquer un peu mieux les détails locaux): une seul rendu pour tout le fond en fait, sans aucun palissement, le palissement est fait par un "alpha blending selon le niveau de zoom, du coup une seule couche bitmap à calculer pour tout et la possibilité alors de recalculer dynamiquement et facilement les niveaux de zoom plus faible. C'est bien plus efficace et bien plus joli visuellement et plus rapide pour tout le monde, le remplissage de polygones complexes est une opération très couteuse en CPU qui marchera assez mal pour les mobiles si on veut préserver leur autonomie).
On peut aussi faire une composition alpha-blending pour le rendu en l'ombrage de la topographie d'altitude (mais pas pour les lignes d'iso) En revanche ça ne marche mal pour les éléments linéaires (l'épaisseur des traits doit changer, et on doit masquer plus de choses en dézoomant sinon on superpose trop de choses), et pas du tout pour les éléments icônes et textes posées encore par dessus : ces deux parties sont destinés à un rendu vectoriel, y compris les lignes d'iso de topographie d'altitude). Et pour les textes, bien séparer les textes localisables afin d'avoir une sélection possible de la langue et un basculement facile: ce sera la couche supérieure au dessus de la couche vectorielle des traits et des icônes (les icônes sont aussi en format vectoriel afin de pouvoir tenir compte de la résolution réelle pour les écrans HiDPI, mais elles ne posent pas de problème car leur rendu bitmap pour la composition est facilement mise en cache local pour économiser de la ressource locale de rendu, de la même façon que se fait *déjà* le rendu bitmap des polices de textes dans tous les moteurs de rendu de texte, ce ne sera donc pas répétitif et coûteux en batterie. La composition (blending) des couches est une opération de base de toutes les cartes graphiques modernes (y compris tous les appareils mobiles) et sinon c'est très optimisé au niveau de l'OS ou du navigateur pour un rendu CPU (pour bureaux ou serveurs qui de toute façon sont aujourd'hui bien plus rapides et pas trop limités en capacité de batterie), mais elle demande un peu plus de mémoire: ce n'est aujourd'hui un problème que pour les appareils mobiles très bon marchés ou anciens avec un vieil OS, ou un affichage assez basique (mais ils sont aussi des tailles d'écran et résolutions plus limitées, avec aussi une moins grande profondeur binaire des couches colorimétriques, et c'est ce qui limite en pratique la mémoire nécessaire). Le sam. 24 oct. 2020 à 19:21, Yves P. <yves.prat...@gmail.com> a écrit : > Concernant les rendus spécialisés, François avait démarré une version > vectorielle du rendu CyclOSM (limité aux infrastructures uniquement), > cf. https://2metz.fr/blog/cyclosm-vector-tiles/. > > > > Pourrait-on capitaliser dessus ? > > > Je viens de voir un rendu vélo Polonais > <https://en.mapy.cz/turisticka?x=19.5730799&y=49.6004347&z=16> (bitmap). > > En modifiant seulement le style, il doit être possible de réutiliser les > tuiles CyclOSM vectorielles. > > __ > Yves > _______________________________________________ > 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
