Le 14 février 2012 18:32, <te...@free.fr> a écrit : > 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 ?
C'est à chaque moteur de rendu de définir le nombre de couches indépendantes de tuiles qu'il va générer, et dans quelle couche il va placer les éléments qu'il trouve. > - 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é ? Je penche plutôt pour la séparation complète (dans un même moteur de rendu) des libellés, notamment pour permettre de choisir dans quelle langue les afficher, ou même choisir de ne pas les afficher tout en affichant le reste. > - 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)... Là encore, si les tuiles sont servies par des moteurs dont le développement est séparé, il est impossible de s'assurer que ces textes ne se superposeront pas. Cependant, comme ces tuiles seront servies dans des couches séparées, on peut encore disposer d'une interface permettant de sélectionner laquelle de ces couches afficher. > 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 :) Je le pense aussi, car cela simplifierait énormément l'utilisation des cartes et le travail de modification ou création de données (vers quelquechose de bien plus utilisable que le "bordel" qu'on voit dans JOSM ou Potlatch, où tout se mélange et où il est difficile d'oublier des choses à créer ou corriger), tout en assurant une bien meilleure cohérence des données stockées dans la base (en permettant à chaque couche modifiable dans l'interface de restreindre le jeu de tags et de valeurs utilisables ou acceptables). D'ailleurs on s'en rends compte puisque justement Osmose sert aussi à offrir des vues séparées de plusieurs couches d'erreurs qu'il détecte. Si on a pu développer Osmose pour générer des couches séparées, on doit aussi pouvoir faire la même chose pour créer des couches destinées cette fois au rendu correct et utilisable des cartes, destinées cette fois non plus seulement aux contributeurs cartographes, mais à fournir un résultat clair montrant ce que l'auteur d'une carte veut réellement montrer (ce qui n'exclue pas pour autant que cette carte affiché ne puisse pas être modifiée dans la même interface sans avoir à charger toutes les autres données stockées dans la base OSM. Et j'imagine que si le développement de JOSM doit continuer, dans la mesure où il dispose DÉJÀ d'un mécanisme de gestion de calques, mais qu'il sous-utilise cette fonctionnalité : je suggérerais aux auteurs de JOSM de commencer à réfléchir à leur utilisation beaucoup plus systématique où les données chargées le seraient dans des sous-calques (même si ces sous-calques sont enregistrés ensemble dans un même fichier OSM et soumis ensembles à la base de données), classant automatiquement ces données dans les bons sous-calques. Dans certains cas (pas si rares en fait), il y aura des liaisons entre les sous-calques, notamment concernant la position de certains noeuds partagés qui doivent permettre de fixer des calques sur des positions qui devraient être identiques (voire même le seront de façon systématique avec le modèle de données actuelles) : * Par exemple, une couche "frontières administratives", elle-même découpée en plusieurs sous-couches pour chaque niveau différent, devrait pouvoir partager les positions des noeuds entre ces sous-couches. * De même avec une couche routière, les routes désignées comme "voies communales" devraient être découpées là où passe la frontière communale, puisque c'est le point (partagé par le chemin de la route et le chemin de la frontière) où cette route peut changer de numéro ou de nom; de même pour le découpage des autoroutes avec les frontières nationales, celui des routes départementales avec les frontières de départements... * Dans le cas des libellés, on a le cas des noms à traduire : on devrait pouvoir disposer aussi dans JOSM d'une vue langue par langue pour s'assurer de la cohérence ou la complétude des traductions. Chaque sous-couche n'affiche qu'une seule langue sélectionnée (mais si un libellé "name:*" ne mentionne pas de traduction dans la langue sélectionnée, il affiche le libellé par défaut "name", de sorte qu'on ne voit QUE "name" et "name:fr" par exemple dans la sous-couche française mais pas "name:en") : l'interface permettant de lister et sélectionner aussi les langues présentes dans les données à modifier. Les sous-couches de libellés par langue ne peuvent pas modifier la géométrie des objets, et se partagent les valeurs de l'attribut "name". Globalement, avoir moins de choses visibles en même temps (même si on peut toujours choisir de voir deux sous-couches en même temps pour fusionner des géométries qui doivent être liées d'une couche à l'autre) permettra une bien meilleure qualité des données cartographiques, facilitera le contrôle de cohérence, le travail des correcteurs et de ceux qui font des mises à jour, avec moins de risque aussi de casser d'autres objets qu'ils n'ont pas l'intention de casser (comme cela se produit encore trop souvent par accident à cause justement des difficultés de sélection dans les interfaces actuelles). _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr