<div class="gmail_extra"><br><div class="gmail_quote">Le 4 décembre 2012 09:50, Pieren <span dir="ltr"><<a href="mailto:pieren3@gmail.com" target="_blank">pieren3@gmail.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Quand tu auras réparé quelques frontières cassées par des débutants<br>
qui ne comprennent pas les 'relations', on en reparlera ;-) </blockquote><div><br></div>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 !</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">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).</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">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.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">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).</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">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.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">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.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">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).</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">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é).</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">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.</div>

<div class="gmail_quote"><br></div></div>