2010/1/18 sly (sylvain letuffe) <sylv...@letuffe.org> > Les chiffres que tu avances sont-ils le fruit d'une supposition de ta part, > où as tu réussi à dénicher cette information ? > > Je me souviens du chiffre des 10% de mémoire parmi les centaines de messages que j'ai lu concernant le changement de licence. La fourchette des 40-50%, c'est un exemple qui vient de moi mais personne n'a oser articuler un chiffre clair sur ce point officiellement.
Un petit rappel sur certains points: à mon avis et suivant mon expérience, très peu d'objets contiennent plusieurs contributeurs. On les retrouve sur les voies les plus fréquentées comme les autoroutes et les routes principales. S'ils disparaissent, ils se reconstitueront assez rapidement parce que là où il y avait de nombreux contributeurs "avant", il y en aura aussi "après", peut-être pas les mêmes. Mais je comprends parfaitement la frustration des gros contributeurs qui pourraient voir une partie de leur travail disparaître. Une migration automatique de cc-by-sa vers odbl : il est impossible de changer la licence sans l'accord du contributeur. Notez que ça serait beaucoup plus facile de changer la licence "après" la migration puisque le contributeur cèderait ses droits à la fondation. Donc des changements ultérieurs seraient beaucoup difficiles à réaliser. Une cohabitation des données sous des licences différentes mais dans la même base : c'est une proposition qui tourne actuellement dans la liste principale mais comme l'a fait remarqué Emilie un peu plus haut, c'est toujours les mêmes et c'est une discussion inutile car tout simplement impossible à réaliser. Les versions : si un élément contient 15 versions de 15 contributeurs, c'est bien l'accord des 15 contributeurs qu'il faudra obtenir pour conserver la dernière version dans la nouvelle base. Si le contributeur n°1 refuse, l'élément disparait, même si les 14 autres acceptent. En fait, l'élément ne disparaîtrait pas vraiment de la base mais ne serait plus accessible depuis l'API. L'intégrité de la base : ces histoires de versions poseront des problèmes d'intégrité de la base. Par exemple, un Node A peut faire partie d'un Way B dans une version 1 et d'un Way C dans une version 2 (et ne plus faire partie du way B). Si on restaure la version 1 du node, il faudrait donc le supprimer du way C et le remettre dans le Way B. Sauf que le Way B aura peut-être changé entre-temps ou même avoir remplacé le node A par un autre, auquel cas il sera peut-être préférable de ne plus migrer du tout le node A.... Bref, la migration risque de créer de nombreuses erreurs genre nodes dupliqués, polygones ou ronds-points non fermés, etc. Pieren
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
