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

[Philippe Verdy]

Le 15 février 2012 11:28, Ab_fab <gamma.gts at gmail.com> a écrit :
>
>
> Le 15 février 2012 08:05, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>
>>
>> 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.
>>
> C'est le genre de choix pour lequel je considère que l'humain possède un
> discernement plus efficace que la machine.
>
>>
>> > - 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.
>
>
> Déjà fait !
> http://toolserver.org/~osm/locale/__all.html
>
> Autre exemple réussi, mais là avec des fonds et des calques
> : http://francetopo.fr/
>
> 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.
>
>>
>> > - 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.
>
>
> francetopo.fr est le meilleur exemple.
>
>>
>>
>> > 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),
>
>
> 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.
> 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"
>
>>
>> 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).
>
>
> 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".
>
> Restreindre le jeu de tags et de valeurs ?
> Et pourquoi pas demander un diplôme pour avoir le droit de contribuer à
> Wikipedia ?
>
>>
>>
>> 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.
>
>
> Là je ne comprends pas bien où tu veux en venir.
>
>>
>>
>> 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...
>
>
> 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.
>
> 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.
> le fichier planet n'est qu'un vulgaire fichier XML. Ce ne sont pas les
> outils qui manquent pour le manipuler.
>
>>
>> * 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".
>
>
> Tu peux au moins tirer profit des rendus disponibles sur Toolserver (voir
> plus haut)
>
>>
>>
>> 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).
>
>
> Jette un oeil sur l'outil de filtrage de JOSM.
> http://josm.openstreetmap.de/wiki/Help/Dialog/Filter
> C'est une vraie bénédiction pour l'édition dans les zones congestionnées.

Sauf que ces filtres sont d'un compliqué à utiliser ! Et qu'on ne peut
toujours pas créer deux vues superposables ou masquables des mêmes
données, chacune avec un filtre différent.

Enfin le gestionnaire de conflits de modifications de JOSM est
réellement "nul à chier" (désolé pour le terme !). En cas de conflits,
la donnée de la base et celle de notre modif devraient être simplement
dans des calques séparés.

La liste des conflits ne sert pas à grand chose actuellement (d'autant
qu'elle est aussi boguée et ne tient pas compte des objets en conflit
qu'on vient de modifier, fusionner ou supprimer). En cliquant sur un
conflit de la liste, cela ne sélectionne que notre objet au milieu de
toutes les autres données en cours de modif ou chargées et pas encore
modifiées, là où cela devrait créer deux mini-calques ("Ma version de
l'objet", et "Version OSM de l'objet") visibles tous les deux en
superposition semi-transparente tandis que le reste des données est
dessiné de façon atténuée, et la liste de sélection devrait référencer
les objets de chaque calque.

En cas de conflit, il n'y a rien pour réellement comparer une version
par rapport à l'autre, là où ce serait hyper facile en comparant un
calque à l'autre et en modifiant dans le calque sélectionné, jusqu'à
ce que les deux objets soient fusionnables sans conflit.

Enfin JOSM s'arrête sur des conflits qui n'ont plus lieu d'être car
ils sont déjà corrigés, et peut bloquer la totalité du reste des
objets qui ne sont pas en conflits mais qui auraient du être transmis
après celui en conflit, à un point tel que si on ne peut pas résoudre
simplement un conflit spécifique sans risque de casser (ou parce qu'on
n'a pas moyen de décider quoi en faire), ce sont toutes les autres
modifications qu'on doit abandonner...