Bonjour, Alors en lisant tout ça, et en partageant le point de vue, j'aurais tendance à dire +10...
C'est vrai, ça permet de découper le travail de création des cartes, ça permet de créer des combinaisons de layers plus facilement avec un client, des layers qui peuvent être customisables en SVG, etc. Après réflexion, il y a des problèmes majeurs qui se posent comme toujours, dans le rendu : - C'est bien quand il s'agit de dessiner des zones colorées d'arrière-plan, genre landuse/natural, ou des délimitations qui se superposent bien au reste, genre frontières, mais ça devient moins pratique pour tous les aspects de superposition (tag "layer") car l'information disparaît dans la séparation des tuiles. - Comment définir quel tag va dans quelle couche ? - Où placer les textes ? Sur la même tuile que les surfaces ? Sur une tuile à part, avec tous les textes ? Sur une tuile à part, dédiée càd ne contenant que les textes d'un layer donné ? - Comment assurer que deux textes ne vont pas se superposer si les calculs des tuiles deviennent indépendants ? A moins que le rendu ne prenne en compte toutes les données affichables (càd le maximum de tuiles superposées)... Cependant, si on trouve des réponses pratiques à toutes ces questions, les moteurs de rendu OSM auraient grand intérêt à mettre en place ce principe :) Teuxe ----- Mail Original ----- De: "Philippe Verdy" <verd...@wanadoo.fr> À: "Discussions sur OSM en français" <talk-fr@openstreetmap.org> Envoyé: Lundi 13 Février 2012 20h44:39 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet 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) <li...@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 "map...@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 map...@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 > map...@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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
