[OSM-talk-fr] Suppression des tirets cadratins

[Philippe Verdy]

Le 4 décembre 2012 09:50, Pieren <pieren3 at gmail.com> a écrit :

> Quand tu auras réparé quelques frontières cassées par des débutants
> qui ne comprennent pas les 'relations', on en reparlera ;-)


Je te rejoins là dessus ! Combien de fois j'ai déjà vu un commentaire de
modification dans la base par quelqu'un qui supprime un chemin de frontière
avec l'idée suivante : il n'y a aucune route à cet endroit là, ce trait me
gène pour retracer autre chose qui est bien visible, allez hop ! je vire ce
truc qui ne sert à rien !

Et voilà il envoie SES objets et n'a rien à faire des autres relations que
de toute façon il n'a même pas chargées; il vagabonde sur la carte dans
JOSM en ne chargeant presque rien de la base (il ne pouvait donc rien voir
du tout, la seule chose qui l'intéresse c'est l'image Bing, et ce ne sont
pas les hacuures par dessus l'image qui le gênent, il sait très bien qu'il
n'a pas chargé toutes les données de la zone mais n'a pas non plus chargé
les relations dépendantes des objets qu'il supprime ou scinde en plusieurs
parties, ou bien qu'il remplace par d'autres en traçant d'abord SON chemin,
puis en virant l'autre).

Et cela ne concerne pas QUE les débutants, un oubli est vite arrivé. Un
champ name en revanche est toujours visible, partout chaque fois qu'on
sélectionne le moindre objet. Sur un chemin frontière il n'indique aucune
priorité droite-gauche, juste une association de deux noms, même si pour
clarifier les choses et stabiliser la présentation on peut fixer une règle
simple : l'objet le plus peuplé vient en premier.

Pour rendre les modifs claires, également, on trie les objets, même si dans
la base ou pour le rendu ce n'est pas nécessaire. On précise aussi les
rôles inner/outer afin aussi de permettre de recoller les morceaux en cas
de casse ultérieure : on voit vite ce qui a été cassé et comment réparer,
et on laisse un schéma propre (ceux qui utilisent Potlatch n'ont pas cette
option de tri, mais eux ils voient TOUS les objets dépendants (mais sont
contraints de travailler sur des zones de plus en plus petites : ils sont
incapables de regarder quelquechose de la taille d'une commune entière, les
relations frontalières plus grandes qu'un quartier ou un petit village ne
sont donc pas créées par eux, ni même les routes les plus longues, ils ont
même du mal à charger et voir toute une rue dans une ville dense).

Bref Potlatch c'est bien pour des modifs très locales (c'est même plus
précis et plus facile et rapide à faire dans Potlatch que dans JOSM : par
exemple affiner un tracé pour justement ajouter d'autres détails autour).
Les deux éditeurs sont donc complémentaires plutôt que concurrents. Mais la
plupart des utilisateurs ne savent utiliser que l'un ou l'autre et ont du
mal à se faire à la différence d'interface.

Mais même dans Potlatch, il est difficile de savoir à quoi correspond un
trait : tous les traits se ressemblent, et le dialogue affichant un nom est
souvent masqué. Si quelquechose apparait dans la vue "Simplifiée", ce ne
sera JAMAIS une "note=", mais le "name=" au moins y sera. On ne verra pas
les types de boundary ou admin_level.

Le name est la meilleure balise permettant de savoir qu'il y a quelquechose
et que c'est une frontière. De plus l'éditeur de relations de Potlatch est
très pénible à utilisé tellement il est minimaliste et mal foutu : on a tôt
fait de se tromper car on ne voit que des identifiants numériques et pas
grand chose d'autre (aucune analyse de connexité ou des membres en doublons
ou manquants).

Il n'y a pas d'outil idéal, mais JOSM maitrisé permet d'aller plus loin que
Potlatch. JOSM fonctionnera bien pour tracer rapidement la structure de
quelque chose qu'on affinera ensuite dans Potlatch. Et j'utilise aussi
rawedit pour certaines modifs directes en XML (dans Osmose), limitées
seulement à quelques attributs (non géométriques et non relationnels comme
les listes de membres, mais éventuellement pour corriger un rôle erroné)
dans le même objet et faciles à éditer sans erreur dans le XML (Osmose
revérifiera derrière si on marque même si on marque "corrigé", car l'ovjet
a changé alors de version, Osmose ne signale plus rien sur un objet marqué
"faux positif" tant que l'objet lui-même n'a pas changé de version depuis
l'analyse qui l'avait signalé).

Osmose est rapide : quelques minutes après la modif (avec les minute diffs
quand elles sont actives), l'objet est à nouveau analysé (mais les erreurs
non marquées corrigées dessus persistent toutes car la modif peut avoir été
faite sans tenir compte de l'anomalie précédente, ce qui peut là encore
induire en erreur les modificateurs (qui vont alors aggraver le problème en
supposant que c'était correct avant leur passage et que si erreurs ils font
ce n'est pas de leur faute). si on a corrigé comme il fallait, il ne
signalera rien derrière la modif.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20121204/254e8a25/attachment.htm>