<div dir="ltr">Les choses "propres" ça dépend des critères que tu veux utiliser. Il arrive souvent que les données soient incomplètement connues, ou que les sources soient discordantes.<div><br><div>Cependant à mon sens, "propre" veut dire que ce qui manque ou est imprécis devrait être documenté avec un FIXME pour savoir où on en est (et ces FIXME sont toujours utiles plus tard pour voir l'avancement ou planifier des vérifications sur place ou d'autres recherches qui peuvent être fastidieuses).</div><div><br></div><div>Et pourtant on a besoin de ces objets pour pouvoir construire ce qui est autour et en dépend assez fortement. En revanche mettre des donénes en vrac sans les qualifier comme imprécises ou peut-être ambigues (en oubliant de citer les alternatives discordantes trouvées), ne permet pas cette progression et à la longue cela pollue les cartes: on n'aide ni les utilisateurs, ni les contributeurs qui ne savent pas quoi faire de ces données: si elles sont douteuses, alors pourquoi pas tout le reste des données?<br><div class="gmail_extra"><br></div><div class="gmail_extra">On manque dans OSM de tags de qualification. Certes on a bien des tags "source:*=*" pour qualifier certaines données mais le tag source a malheureusement été "déprécié" (à tord à mon avis) en le transférant vers les tags du changeset. Hors ces changesets se cumulent et on ne voit en fait que le dernier changeset qui est passé sur un objet mais pas forcément sur tous ses tags. Le changeset en plus applique ses qualification à la totalité des objets et de leurs tags et membres de relations, même ceux qui n'ont pas été touchés du tout. Bref on se retrouve à devoir comparer les changesets sur des tonnes d'objets pour comprendre un peu, et rien pour indiquer que cette source s'applique réellement à tel ou tel élément.</div><div class="gmail_extra"><br></div><div class="gmail_extra">De fait le tag "source=*" du changeset se contente juste de mentionner les sources d'imagerie ou de fonds de cartes utilisés, mais rien concernant réellement les tags posés sur les objets individuels. De plus le tag "source=*" seul cumule tous les usages et s'applique à la totalité de chaque objet.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Il faut renouer avec les tags "source:<tag>=*" ou "source_ref:<tag>=<URL>" et autres "FIXME:<tag>=*" sur les éléments eux-mêmes pour mieux qualifier les données et mesurer l'avancement. Cela permettra de mieux mesurer l'avancement et planifier ce qui est à faire ou vérifier.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Dernier problème: on n'a pas de tag standard pour qualifier les *membres* de relation, le seul moyen étant de mettre un suffixe ":FIXME" sur le rôle, ou utiliser le rôle "FIXME" pour les membres de rôle anonyme. mais on ne peut pas mettre de source ou URL de référence sur chacun des membres inclus. Concernant les membres d'une relation à remplacer par un autre plus précis (par exemple remplacer un noeud par un polygone), on peut utiliser ce rôle. Concernant les membres manquants dans une relation (à rechercher et ajouter), on n'a rien sauf dans les tags de la relation elle-même où il faudra un ou plusieurs tag "FIXME:<numéro arbitraire>=*".</div><div class="gmail_extra"><br></div><div class="gmail_extra">Certaines "politiques" d'OSM jouent également contre la progression incrémentale (par exemple le fait de n'avoir pas admis les collections, qui sont pourtant très utiles quand justement les objets sont imprécis ou incomplets ou en pleine contruction, et qu'il n'est pas possible d'ajouter complètement comme on le voudrait en une seule modification). Certes on pourrait mettre ça sur des pages d'avancement sur un site externe de planification du travail (y compris HOT qui cependant ne gère pas ça mais juste un découpage un peu arbitraire en tuiles carrées plus ou mois subdivisées), mais hormis quelques collections complètement connues et documentées je trouve dommage d'une part de polluer le wiki pour ces tâches (et laisser ensuite ces pages à l'abandon). Au moins en mettant ça dans OSM directement (ou sur une base standardisée permettant de stocker des tags d'avancement et de qualification) on y irait accès tout de suite, y compris dans les éditeurs, sans avoir à trainer l'édition de pages web, blogues, ou autres pages wiki.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Il manque à OSM une gestion standardisée des tâches à accomplir et des outils et rapports de mesure de l'avancement. On a bien les "notes" mais elles sont insuffisantes : on n'a que des notes par objet, mais pas tag par tag, relation par relation. Et rien non plus pour les objets manquants dans une zone sommairement délimitée par un pseudo-objet (bounding box, ou polygone ou ligne grossiere pour la recherche) qu'on pourrait lier à un autre (comme pseudo-membre d'une relation, ou comme pseudo-noeud attaché à un chemin).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Dans certains cas on pourrait avoir plusieurs pseudo-objets candidats mais différents (un peu comme les "branches" dans un outil de gestion de versions de logiciel comme CVS ou git). On pourrait alors avoir un objet maître recensant les candidats, un système d'évaluation ou de "vote", des outils permettant de la comparer. Ce serait aussi utile pendant la préparation des imports d'une grosse source. Ce serait utile aussi pour diviser le travail en équipe.</div><div class="gmail_extra"><br></div><div class="gmail_extra">En gros cela consiste à admettre l'existence de plusieurs bases de données (chacune avec une URL ou un chemin de fichier local ou sur un réseau) en plus de la base OSM par défaut. Chaque base pouvant alors gérer ses propres "id" d'objets internes, ou rattacher un "id" à un objet maitre d'une autre base de données.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Pour ça il faut peut de modifications: "id=<numéro d'objet dans OSM>" peut s'étendre en "id=<numéro local de base de données>:<numéro d'objet>" ou en ajoutant "baseid=<numéro local de base de données>" où</div><div class="gmail_extra">-  le "<numéro local de base de données>" fait référence à un nouveau type d'objet (une métadonnée) dans la base de données locale (ou dans OSM) permettant de décrire cette base lui donner un nom, identifier son propriétaire, l'adresse (chemin, URL) de soumission de données avec le format (par défaut le format XML ou JSON pour OSM, ou un format "OSM API" si c'est un serveur compatible, la version de ce format). une date de dernière synchronisation de ces métadonnée, et un éventuel autre <numéro local de base de données> pour une autre base maître (où se fait la fusion)</div><div class="gmail_extra">- sans ce <numéro local de base de données>, le <numéro d'objet> fait référence à un objet dans la base OSM.</div><div class="gmail_extra">- plus besoin des ids négatifs pour les nouveaux objets. Et la soumission des données consiste à les envoyer à la base maître mentionnée, s'il y en a une, ou sinon à la base OSM principale.</div><div class="gmail_extra">- le "<numéro local de base de données>" est purement local à chaque base. Un fichier OSM sauvegardé localement avec des modifications contient son propre descripteur de base de données avec le numéro "0" (lequel descripteur peut faire ensuite référence à la base OSM en tant que base "maitre" par défaut.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Là on obtient autant de moyens de gérer le travail collaboratif avec des bases hiérarchisées sur plusieurs niveaux (voire totalement indépendantes pour y stocker des données dont OSM ne veut pas, y compris des données propriétaires qui resteront dans la base propriétare: le descripteur "0" mentionne alors qu'il est lui-même "maître" et n'a pas d'autre base maître).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Et on a alors une grande liberté pour mettre tous les tags qu'on veut (même des tags non standards, qu'il ne faudra standardisés que lors de la soumission à la base "maître"). On peut faire de la fusion sur plusieurs niveaux différents pour des données de nature différente. Cette base séparée permet alors la planification de tâche dans une équipe en en faisant une base maître référencée par les bases filles créées pour les tâches individuelles que peuvent se répartir plusieurs utilisateurs travaillant en équipe.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">Le 14 mai 2016 à 16:57, JB <span dir="ltr"><<a href="mailto:jbosm@mailoo.org" target="_blank">jbosm@mailoo.org</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">Le 14/05/2016 à 16:01, Jérôme Amagat a écrit :<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
si la position est bonne c'est déjà bien après je vous laisse faire pour les tag<br>
</blockquote></span>
Mouaif. C'est quand même ce genre d'objet qui m'énerve quand je contribue sur une zone. Personnellement, je préfère rien qu'un truc mal fichu : comme j'aime bien les choses propres, je vais passer pas mal de temps à essayer de faire mieux et avoir l'impression de perdre mon temps. D'autres préfèrent avoir plein d'éléments… mais avec une valeur ajoutée faible (voire nulle) : sans tag principal, pas ou peu d'utilisation par d'autres outils, et des outils très pointus auraient su les chercher dans la BDD spécialisée d'où ils ont été intégrés.<span class=""><font color="#888888"><br></font></span></blockquote></div></div></div></div></div>