Re: [OSM-talk-fr] Nouveau rendu osm.fr

2020-10-24 Par sujet Philippe Verdy
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.  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
>  (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


Re: [OSM-talk-fr] Nouveau rendu osm.fr

2020-10-24 Par sujet Yves P.
> 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 
 (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


Re: [OSM-talk-fr] Nouveau rendu osm.fr

2020-10-24 Par sujet Yves P.
> Non, mon idée est de gardée une base commune à périmètre identique de ce que 
> ça fait déjà, pour garder ça léger et réutilisable.
+1

Exemple d'affichage sur 2 sites web différents :

++--++
| Couche ferroviaire | Couche Cyclo | Couche point d'eau |
++--++
|   Couche "fond de plan" (OpenMapTiles) |
++

 ++
 | Couche point d'eau |
+++
| Couche ferroviaire |Couche Cyclo|
+++
|  Couche "fond de plan" (OpenMapTiles)   |
+-+


> Mais d'avoir des layers de données que l'on peut rajouter et combiner. J'en 
> ai fait deux en ce sens, les arbres (1 layer) et l'infra vélo (2 layers).

ça pourrait donner ça :
+-+
|   Couche Arbres |
+-+
|   Couche  Cyclo |
+-+
|  Couche "fond de plan" (OpenMapTiles)   |
+-+

> 
> 
>> 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 ?
> 
> J'ai javais vu ça et le tien, le mien étant plutôt une expérience, mais je 
> trouve le résultat plutôt pas trop mal et je m'en sert moi même.

Plutôt que de faire une couche de tuiles par "POI", on pourrait avec les points 
d'eau inclus dans la couche cyclo.

Les points d'eau sont déjà dans la couche OpenMapTile 😀

Je viens de voir ça avec CyclOSM vector : cliquer sur l'icône carte en haut à 
droite. Tous les objets sont afficher et une bulle affiche les attributs

https://cyclosm.2metz.fr/static/index.html#19.11/48.8548288/2.3455783
https://projetdumois.fr/projects/2020-09_aed/map#map=19.11/48.8548288/2.3455783
https://www.openstreetmap.org/node/494251394


La couche OpenMapTile indique son nom, son type drinking_water, il manque 
essentiellement l'id OSM… et les autres tags (photos)

Il existe aussi un (plusieurs ?) serveurs de tuiles qui combine plusieurs 
couches à la volée.

__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr