(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 <m...@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: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
