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

Pierre BOIZOT pierre at boizot.name
Mer 29 Sep 20:18:38 UTC 2010


Merci pour cette Belle intervention. qui à mon sens nous ramène à plusieurs
point déjà débattu dans diverses interventions.

Pas de méthodologie, mais y a t il une méthode, nous dirons les adeptes du
"on n'en veut pas".
Il y a plusieurs  méthodes certes mais à mon sens il devrait y avoir une
organisation plus rigoureuse des intégrations de data.

Je ne pense pas que sur le noyaux linux, une distribution sur un driver
quelconque on accepte un patch sans le regarder de près, et avoir validé que
la contribution était juste et judicieuse.

Or dans OSM on s'inscrit on charge josm , on trace deux trois way on mets
peut - étre n'importe quoi, on commit ....
et ensuite on entends les grognements  dans les mailing listes .

La qualité est quelques chose de très subjectif. C'est sur certain point
facile à résoudre.
Pourquoi l'outil d'import accepte il un import de chemin incomplètement
marqué?

Ma réponse :  parce que le processus est itératif, que l'organisation doit
être souple pour intégrer de nouveaux contributeurs, parce qu'aujourd'hui il
est plus important d'engranger des données même partielles, même fausses que
de qualifier finement.

Et je suis un partisan du mieux vaut une voie mal codifiée que pas de voie.

Pourtant je me suis étonné courant Aout qu'il n'y ai pas de processus de
d'apprentissage , d'accompagnement des nouveaux CartoGrafAmateur, j'ai
déploré la présence d'une organisation plus structuré, la présence d'un
outil de documentation plus facile d'accès au nouvel arrivant .

Pensez vous vraiment que cette page
<http://wiki.openstreetmap.org/wiki/FR:Beginners_Guide>soit un guide pour
débutant.

J'avais cru comprendre que justement un désir des premiers contributeurs
était de s'appuyer sur des communautés locales, mais visiblement la sauce
n'a pas prise , il y a peu de communauté en deçà du niveau national.

Donc que faire pour avancer :

Des cartes stable / test / travail est bien. j'imagine que sa mise en place
puisse etre complexe , couteuse mais bon , dans la vie réelle je vois
souvent 3 , 4 niveau d'organisation.

Un bac à sable et un accompagnement pour les nouveaux contributeurs un
contributeur ne commit en base travail qu'aprés avoir eu le OK de plusieurs
parrains. He oui je trouve étrange que je puisse contribuer sans avoir
vraiment compris l'importance du ref:sandre ;-)

Des outils qui génèrent moins d'erreur , encore l'import bati...

Une mailling liste qui soit éclater en au moins 5 traffics:

Dev
Debutant
Question Mapping general
Question mapping France
Info diverse, annonces.

Salut a tous.
Pierre

Pierre Boizot
CH-1009 PULLY


Le 29 septembre 2010 19:18, Guilhem Bonnefille <guilhem.bonnefille at gmail.com
> a écrit :

> (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/
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20100929/7dfcc0e7/attachment.htm>


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