[OSM-talk-fr] qualité de la carte

Guilhem Bonnefille guilhem.bonnefille at gmail.com
Mer 29 Sep 17:18:15 UTC 2010


(Je me permet de changer le sujet de la discussion pour ne plus
polluer le fil de discussion qui concerne une zone de la carte et qui
intéresse donc plutôt les contributeurs locaux)

Le 29 septembre 2010 14:21, Croquette Olivier <ml at ocroquette.de> a écrit :
> Le problème est qu'il n'y a pas de méthodologie ou d'outils officiels.

Tu met ici le doigt sur ce qui me semble être BEAUCOUP plus gênant que
des contributeurs fougueux. Pour moi, le problème essentiel que doit
résoudre OSM (ou une division locale) c'est de définir un outillage
(méthodologie et outils) *officiel*. Une fois que ce sera fait, il
deviendra bien plus simple à un contributeur très motivé de faire
moins d'erreurs.

Aujourd'hui, il y a des conventions dans tous les coins, des trucs que
le plus grand monde pratique, mais qui sont toujours dans l'état
"proposal" ou que les éditeurs ne supportent pas (dans le sens où ils
permettent de faire le contraire). Ensuite nous avons des outils tels
que l'import du bati qui extrait des informations avec beaucoup
d'information incorrecte pour OSM (trop de détails, des cours d'eau où
il n'y en a pas...).

A nouveau, je ne jette la pierre à personne (il est très bien de
laisser la liberté dans le tagging et il est très bien d'avoir un
outil qui extrait toutes ces informations des planches cadastrales),
j'explique juste pourquoi à mon sens il est naturel que des
contributeurs fassent des erreurs. Et dans la mesure où cette erreur
est finalement *naturelle* il me parait sain de respecter *toutes* les
contributions, qu'elles soient parfaites ou erronées.

> Je comprends donc la position de ceux qui attendent une grande qualité des imports, car le risque est grand que les erreurs restent dans la carte pendant un temps indéterminé voire long, et/ou que ce soit souvent les mêmes qui passent derrière pour faire les corrections rébarbatives...

Je vais me risquer à faire des réponses très caricaturales :
- s'il y a des erreurs qui perdurent, c'est qu'à priori elles ne
dérangent personne, donc pourquoi fournir un effort jugé inacceptable
pour les corriger.
- s'il y a des corrections rébarbatives, il y a certainement un outil
à inventer pour automatiser leur correction. Si on prend l'exemple des
doublons et qu'on considère, comme moi, qu'il n'est pas raisonnable
d'espérer que personne n'insèrera jamais un doublon dans la base,
alors il faut un outil qui permette à un contributeur informé/motivé
de corriger des doublons en fournissant un effort minimal.
Je vais prendre un exemple dans un domaine que je connais mieux : la
gestion des sources logicielles dans un environnement collaboratif.
Dans cet environnement, il y a un élément perturbateur qui est la
modification concurrente d'un même document. Historiquement, la
solution consiste à verrouiller le document afin qu'un seul ne
travaille dessus, ce qui pose le problème qu'un seul travaille dessus
et que les autres doivent perdre leur temps à attendre. Aujourd'hui,
la vision est plutôt d'offrir un outil qui permette à plusieurs
personnes de travailler sur le même document et que l'outil tente de
fusionner le résultat tout seul en criant à l'aide lorsqu'il ne s'en
sort pas.

Dans la mesure où le projet est OUVERT il me parait nécessaire qu'un
maximum de responsabilité porte sur les outils.
Et dans la mesure où ça ne pourra jamais être suffisant de se reposer
sur les outils, si on veut obtenir encore plus de qualité sur la
carte, il va falloir mettre en place une organisation qui assure cette
qualité, par exemple en isolant une version de la carte jugée de bonne
qualité d'une version de la carte dans laquelle il peut y avoir des
soucis (et où sont apportées les nouveautés). Mais cela nécessite des
personnes pour faire du travail de modération que certains jugeront
rébarbatif.
Pour moi, le meilleur exemple est une distribution GNU/Linux comme
Debian : il y a une version de travail (sid), une version de
développement (testing) et une version stable. Et pour que les
paquets/logiciels passent d'une version à l'autre, il y a des outils,
des packageurs (dont le travail peut certainement être considéré comme
rébarbatif) et des testeurs pour détecter les problèmes (dont le
travail peut aussi être jugé comme rébarbatif puisque leur
environnement n'est jamais stable ou exempt de bugs).


Désolé pour mon mail si long et bravo à ceux qui ont tenus.
-- 
Guilhem BONNEFILLE
-=- JID: guyou at im.apinc.org MSN: guilhem_bonnefille at hotmail.com
-=- mailto:guilhem.bonnefille at gmail.com
-=- http://nathguil.free.fr/




Plus d'informations sur la liste de diffusion Talk-fr