[OSM-talk-fr] le rendu mapnik at osm.org affiche si ou ça. Etait :place = locality / hamlet

[Philippe Verdy]

Plutôt que vouloir tout mettre ans Mapnik, je verrais plutôt le
développement de tuiles transparentes, superposables en couches
sélectionnables, et permettant d'afficher ou masquer ce que l'on veut
voir ou pas.

Bref des tuiles pour le fond topographique, des tuiles pour uniquement
les limites administratives, des tuiles semi-transparentes pour
colorer les "landuse", des tuiles transparentes pour la bâti, des
tuiles pour les libellés de chaque langue.

L'intérêt ? Moins compliqué de mettre à jour ces tuiles de façon
cohérente (malgré toutes les exceptions possibles qui peuvent
apparaître). Et une plus grande versatilité, et même des mises à jour
plus rapides (chaque jeu de tuiles pour un jeu de de données limité
peut être distribué sur des serveurs de rendu différents, qui ont
globalement moins de chose à faire).

Cependant le choix des couches de tuiles à visualiser demanderait une
interface plus conviviale que l'actuelle boite bleue déroulable, où ce
n'est qu'une simple liste, qui demanderait à devenir une liste
hiérarchique (un peu à la façon de ce qu'on voit dans Google Earth,
l'application "standalone", qui permet de sélectionner les couches qui
nous intéressent.

D'ailleurs ces tuiles spécialisées pourraient non pas être générées en
format bitmap (PNG, GIF, JPG), mais en SVG bien plus versatile, dont
le "stylage" peut être effectué sous le contrôle du client qui
pourrait encore dynamiquement changer les couleurs ou les épaisseurs
de traits, ou les polices utilisées, ou les styles et tailles de
police selon les préférences de chacun (et aussi ses propres options
d'accessibilité), simplement avec du CSS facile à maintenir en
Javascript. On peut noter que la prise en charge de SVG s'est
considérablement amélioré dans les navigateurs, et que SVG s'intègre
maintenant nativement dans le DOM pour HTML5, sans plugin
supplémentaire.

De quoi déprécier largement les tuiles bitmap actuellement distribuées
(et aussi faire gagner de la bande passante sur les serveurs de
tuiles), car dans bon nombre de cas, ces tuiles pourraient fonctionner
aussi de façon plus lisible pour des gammes étendues et non discrètes
d'échelles.

D'ailleurs Google se met aussi maintenant au rendu vectoriel de ses
tuiles (avec son option "MapGL" encore en beta-test), tout en
supportant maintenant le rendu multicouches (avec couches
sélectionnables) depuis longtemps dans Google Earth.

Une telle interface améliorée conviendrait aussi bien à ceux qui
veulent voir une carte lisible, que pour les contributeurs qui veulent
voir un maximum de choses, tout en facilitant aussi la sélection (par
clic sur la carte) des éléments à modifier, corriger, ou ajouter.

Je dirais même que cela améliorerait grandement la cohérence des tags
dans la base centrale OSM qui contient tous les objets servant de
source pour les différents moteurs de rendu (certes on ne "tague" pas
pour un rendu spécifique, mais tout rendu a besoin d'une cohérence des
données, et cela n'empêchera pas d'appliquer différents styles visuels
pour ce que chaque moteur décide ou non d'afficher dans ses tuiles).

A terme, cela pourrait même rendre l'utilisation de JOSM inutile (car
en fait bien trop complexe à utiliser quand il veut tout afficher en
même temps et ne facilite pas du tout la sélection d'objets superposés
ou qui partagent des noeuds ou traits communs, dans des zones très
denses en données de toutes sortes)...

Chaque moteur de rendu pourrait aussi rapporter ses propres anomalies
de cohérence dans une sous-couche de rendu qui est propre au jeu
sélectif de données qu'il utilise comme sources). Le système serait
bien plus collaboratif, et plus facile à maintenir (on s'en rend
compte déjà puisque le nombre de serveurs de rendus spécifiques à une
zone ou un domaine d'intérêt commence à exploser).

Pour que cela marche il faudrait disposer d'une base de données
permettant de rechercher et classer les rendus disponibles, afin qu'on
puisse les activer sélectivement sous forme de superpositions de
couches.

Le 13 février 2012 12:40, sly (sylvain letuffe) <liste at letuffe.org> a écrit :
> On dimanche 12 février 2012, yvecai wrote:
>> C'est vrai que Mapnik (enfin, la feuille de style d'osm)
>
> Pour lever l'ambiguité et tenter de rester le plus concis possible, j'aime
> écrire "mapnik at osm.org"
>
>> à une fâcheuse
>> tendance à marquer tout les tags 'name='.
>
> Est-ce vraiment fâcheux ?
> Le problème est sans doute que ce rendu, dont l'importance en tant que rendu
> par défaut du site osm.org ne peut être ignorer, est utilisé par différentes
> personnes aux objectifs divers et aux besoins divers.
>
> Avec la disparition programmée de osmarender, qui était un rendu avec
> l'avantage d'afficher un max de données osm. On va se retrouver selon moi
> avec un vide à combler, celui d'un rendu pour les contributeurs. Un rendu qui
> puisse afficher plein de donnée et permettre de contrôler, dans les minutes
> après sa contribution si on a pas oublié un truc, fait une erreur, dégommé
> une forêt, etc.
>
> Et, selon moi toujours, c'est le rôle du rendu "vitrine" du site osm.org.
> osm.org n'est pas google maps, les serveurs d'osm.org n'ont ni les moyens, et
> ses admins les envies d'en arriver là.
>
> Le fait que le rendu mapnik at osm.org soit visible sur de nombreux sites tiers
> dans une logique "consommation" est déjà, à mon sens, une erreur.
> Erreur dû au passé, avant, il n'y avait simplement pas le choix car il n'y
> avait que ça.
>
> Mais maintenant, les choses ont changées, je suis donc en faveur pour que
> mapnik at osm.org deviennent un rendu toujours plus moche, toujours plus à jour,
> toujours plus saturé d'info, bref toujours plus à destination du
> contributeur.
>
> Alors oui aux noms qui apparaissent à l'arrache, oui aux noms des communes en
> double des chef-lieu, en double des traits taggués pour le rendu et des
> relations type=route qui n'ont pas de rendu.
>
> Pourquoi ? pour qu'on puisse les voir ! Et qu'on puisse les vérifier, les
> zigouiller ou les améliorer.
>
>
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
> email perso : sylvain chez letuffe un point org
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr