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

[Philippe Verdy]

Le 14 février 2012 18:32,  <teuxe at 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).