<div><br></div><br><div class="gmail_quote">Le 15 février 2012 08:05, Philippe Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
</div>C'est à chaque moteur de rendu de définir le nombre de couches<br>
indépendantes de tuiles qu'il va générer, et dans quelle couche il va<br>
placer les éléments qu'il trouve.<br>
<div><br></div></blockquote><div>C'est le genre de choix pour lequel je considère que l'humain possède un discernement plus efficace que la machine.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
> - 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é ?<br>
<br>
</div>Je penche plutôt pour la séparation complète (dans un même moteur de<br>
rendu) des libellés, notamment pour permettre de choisir dans quelle<br>
langue les afficher, ou même choisir de ne pas les afficher tout en<br>
affichant le reste.<br></blockquote><div><br></div><div>Déjà fait !</div><div><a href="http://toolserver.org/~osm/locale/__all.html">http://toolserver.org/~osm/locale/__all.html</a>
</div><div><br></div><div>Autre exemple réussi, mais là avec des fonds et des calques : <a href="http://francetopo.fr/">http://francetopo.fr/</a></div><div><br></div><div>C'est pas mal, mais en regardant de près il y a des télescopages possibles entre le texte et les éléments de la carte. Ils restent limités quand le rendu de toutes ces couches est fait par la même machine.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> - 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)...<br>
<br>
</div>Là encore, si les tuiles sont servies par des moteurs dont le<br>
développement est séparé, il est impossible de s'assurer que ces<br>
textes ne se superposeront pas.<br>
<br>
Cependant, comme ces tuiles seront servies dans des couches séparées,<br>
on peut encore disposer d'une interface permettant de sélectionner<br>
laquelle de ces couches afficher.<br></blockquote><div><br></div><div><a href="http://francetopo.fr">francetopo.fr</a> est le meilleur exemple.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> 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 :)<br>
<br>
</div>Je le pense aussi, car cela simplifierait énormément l'utilisation des<br>
cartes et le travail de modification ou création de données (vers<br>
quelquechose de bien plus utilisable que le "bordel" qu'on voit dans<br>
JOSM ou Potlatch, où tout se mélange et où il est difficile d'oublier<br>
des choses à créer ou corriger),</blockquote><div><br></div><div>Si tu veux filtrer / atténuer / occulter des éléments de la base osm "perturbateurs" pour ta contribution, il existe un super outil de filtrage pour JOSM.</div>
<div>Côté rendu, JOSM fonctionne avec une feuille de style au format mapcss. Rien ne t'empêche de l'ajuster pour que l'affichage colle mieux à ton "profil de contribution"</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
tout en assurant une bien meilleure<br>
cohérence des données stockées dans la base (en permettant à chaque<br>
couche modifiable dans l'interface de restreindre le jeu de tags et de<br>
valeurs utilisables ou acceptables).<br></blockquote><div><br></div><div>Le mode de stockage des données dans la base principale OSM suit une logique qui parait bordélique, mais qui vise surtout à arriver à un haut niveau de "robustesse".</div>
<div><br></div><div>Restreindre le jeu de tags et de valeurs ? </div><div>Et pourquoi pas demander un diplôme pour avoir le droit de contribuer à Wikipedia ?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
D'ailleurs on s'en rends compte puisque justement Osmose sert aussi à<br>
offrir des vues séparées de plusieurs couches d'erreurs qu'il détecte.<br></blockquote><div><br></div><div>Là je ne comprends pas bien où tu veux en venir.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Si on a pu développer Osmose pour générer des couches séparées, on<br>
doit aussi pouvoir faire la même chose pour créer des couches<br>
destinées cette fois au rendu correct et utilisable des cartes,<br>
destinées cette fois non plus seulement aux contributeurs<br>
cartographes, mais à fournir un résultat clair montrant ce que<br>
l'auteur d'une carte veut réellement montrer (ce qui n'exclue pas pour<br>
autant que cette carte affiché ne puisse pas être modifiée dans la<br>
même interface sans avoir à charger toutes les autres données stockées<br>
dans la base OSM.<br>
<br>
<br>
Et j'imagine que si le développement de JOSM doit continuer, dans la<br>
mesure où il dispose DÉJÀ d'un mécanisme de gestion de calques, mais<br>
qu'il sous-utilise cette fonctionnalité : je suggérerais aux auteurs<br>
de JOSM de commencer à réfléchir à leur utilisation beaucoup plus<br>
systématique où les données chargées le seraient dans des sous-calques<br>
(même si ces sous-calques sont enregistrés ensemble dans un même<br>
fichier OSM et soumis ensembles à la base de données), classant<br>
automatiquement ces données dans les bons sous-calques.<br>
<br>
Dans certains cas (pas si rares en fait), il y aura des liaisons entre<br>
les sous-calques, notamment concernant la position de certains noeuds<br>
partagés qui doivent permettre de fixer des calques sur des positions<br>
qui devraient être identiques (voire même le seront de façon<br>
systématique avec le modèle de données actuelles) :<br>
<br>
* Par exemple, une couche "frontières administratives", elle-même<br>
découpée en plusieurs sous-couches pour chaque niveau différent,<br>
devrait pouvoir partager les positions des noeuds entre ces<br>
sous-couches.<br>
<br>
* De même avec une couche routière, les routes désignées comme "voies<br>
communales" devraient être découpées là où passe la frontière<br>
communale, puisque c'est le point (partagé par le chemin de la route<br>
et le chemin de la frontière) où cette route peut changer de numéro ou<br>
de nom; de même pour le découpage des autoroutes avec les frontières<br>
nationales, celui des routes départementales avec les frontières de<br>
départements...<br></blockquote><div><br></div><div>Ce que tu dis revient souvent en discussion sur les divers canaux de communication liés à OSM. Mais ce qui paraît être une bonne pratique pour organiser les données aboutit en pratique à une usine à gaz.</div>
<div><br></div><div>Il n'en demeure pas moins que tu peux tout à fait te lancer dans l'aventure, et générer un extrait, organisé selon tes souhaits, en partant de planet.osm, voire de sa version intégrale (full history) ou bien d'un extrait régional, pour ensuite en démontrer les bénéfices.</div>
<div>le fichier planet n'est qu'un vulgaire fichier XML. Ce ne sont pas les outils qui manquent pour le manipuler.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Dans le cas des libellés, on a le cas des noms à traduire : on<br>
devrait pouvoir disposer aussi dans JOSM d'une vue langue par langue<br>
pour s'assurer de la cohérence ou la complétude des traductions.<br>
Chaque sous-couche n'affiche qu'une seule langue sélectionnée (mais si<br>
un libellé "name:*" ne mentionne pas de traduction dans la langue<br>
sélectionnée, il affiche le libellé par défaut "name", de sorte qu'on<br>
ne voit QUE "name" et "name:fr" par exemple dans la sous-couche<br>
française mais pas "name:en") : l'interface permettant de lister et<br>
sélectionner aussi les langues présentes dans les données à modifier.<br>
Les sous-couches de libellés par langue ne peuvent pas modifier la<br>
géométrie des objets, et se partagent les valeurs de l'attribut<br>
"name".<br></blockquote><div><br></div><div>Tu peux au moins tirer profit des rendus disponibles sur Toolserver (voir plus haut)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Globalement, avoir moins de choses visibles en même temps (même si on<br>
peut toujours choisir de voir deux sous-couches en même temps pour<br>
fusionner des géométries qui doivent être liées d'une couche à<br>
l'autre) permettra une bien meilleure qualité des données<br>
cartographiques, facilitera le contrôle de cohérence, le travail des<br>
correcteurs et de ceux qui font des mises à jour, avec moins de risque<br>
aussi de casser d'autres objets qu'ils n'ont pas l'intention de casser<br>
(comme cela se produit encore trop souvent par accident à cause<br>
justement des difficultés de sélection dans les interfaces actuelles).<br></blockquote><div><br></div><div>Jette un oeil sur l'outil de filtrage de JOSM.</div><div><a href="http://josm.openstreetmap.de/wiki/Help/Dialog/Filter">http://josm.openstreetmap.de/wiki/Help/Dialog/Filter</a>
</div><div>C'est une vraie bénédiction pour l'édition dans les zones congestionnées.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><a href="http://wiki.openstreetmap.org/wiki/User:Ab_fab" target="_blank">ab_fab</a><br>"Il n'y a pas de pas perdus"<br>