<div dir="ltr">Tu as raison de t'indigner de la dérive de ceux qui considèrent les données comme les leurs. Sur un projet collaboratif, les données sont partagées, corrigées en commun, personne n'a la main mise.<div>

<br></div><div>La qualité peut se mesurer malgré tout mais sans pour autant nécessiter un accaparement par quelques uns (une dérive qu'on trouve aujourd'hui sur les projets Wikimedia dont bon nombre de choses sont imposées par quelques administrateurs qui décident de tout et bloquent tout changement, alors que le blocage d'article n'a été fait que pour stopper des guerres d'édition et pas pour empêcher des évolutions ou contre-propositions, là où le blocage des comptes ne suffit pas ; bloquer un article devrait immédiatement conduire à une page de vote et d'évaluation collective des contre-propositions).</div>

<div><br></div><div>Maintenant oui, on peut sélectionner ce qu'on veut dans les données de la base, mais le problème c'est plutôt les données qui sont remplacées/modifiées/supprimées et pas facilement exploitables par nos outils. Il n'est pas facile de stocker des versions différentes dans OSM sans que cela génère des tas de problèmes (c'est plus difficile dans OSM que sur un wiki).</div>

<div><br></div><div>A cela il y a une autre solution: importer dans une autre base de façon sélective, et utiliser OSM comme une source vivante où on va piocher non pas au fur et à mesure mais de façon sélective, afin de créer une base dérivée (cela permet de préserver certaines versions). Mais pour cela il faudrait disposer d'outils permettant de comparer facilement deux bases et choisir quoi prendre et comment facilement importer de l'une vers l'autre.</div>

<div><br></div><div>Filtrer sur la base d'une liste d'utilisateurs ne suffit pas. Tout bonnement car tout le monde peut malgré tout faire une erreur à un instant donné (ou n'avoir fait aucune erreur mais pas fini de transmettre les données à cause de conflits d'éditions à résoudre).</div>

<div><br></div><div>----</div><div><br></div><div>Certaines modifs non terminées peuvent faire croire aux autres à une erreur ou incohérence. J'ai déjà eu le cas où une modif en cours d'envoi a été tagué comme erreur par quelqu'un dans les secondes après le début de l'envoi (il a cru à l'insertion d'un doublon alors que l'objet était scindé en deux mais un seul était transmis au début), qui l'a ensuite supprimée, avant même que l'envoi soit complet. Il a généré au passage un conflit d'édition. Pourtant il fallait moins d'1 minute pour finaliser le tout (pour résoudre le conflit, il fallait d'abord accepter la suppression, puis restaurer l'objet supprimé à tord, puis reprendre la suite de l'envoi).</div>

<div><br></div><div>JOSM ne facilite pas beaucoup les choses puisqu'il ne permet pas facilement décharger une version spécifique depuis l'historique, et il se mélange dans les statuts d'objet sur l'ordre des envois à faire ensuite (il faut le guider en sélectionnant les objets à envoyer dans le bon ordre, car son algo de tri des envois ne prévoit pas qu'un objet supprimé puisse être restauré, et JOSM n'a aucun outil permettant de sélectionner la version à restaurer d'un objet supprimé, on ne peut prendre que la dernière version avant suppression).</div>

<div><br></div></div>