[OSM-talk-fr] Je ne comprends pas ces points ?

[Philippe Verdy]

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.

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).

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?

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.

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.

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.

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>=*".

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.

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).

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.

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.

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ù
-  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)
- 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.
- 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.
- 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.

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).

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.


Le 14 mai 2016 à 16:57, JB <jbosm at mailoo.org> a écrit :

> Le 14/05/2016 à 16:01, Jérôme Amagat a écrit :
>
>> si la position est bonne c'est déjà bien après je vous laisse faire pour
>> les tag
>>
> 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.
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160514/da75fe01/attachment.htm>