Le 11 juillet 2012 07:49, Vincent de Chateau-Thierry
<v...@laposte.net> a écrit :
> Il ne te reste plus qu'à travailler sur une zone "assez petite"...

JOSM va être quasiment inutilisable. On va se borner à utiliser
Potlatch 2 dans les petites zones qu'il veut bien charger.

> Préparons-nous à trouver des tonnes de relations cassées à
>>
>> cause d'un seul noeud supprimé qui n'aura pas été remis à jour
>> (simplement en le bougeant un peu avec une précision améliorée).
>>
>
> Ce qui signifierait que la suppression d'un noeud supprime en cascade le way
> auquel il appartient, way référencé par ladite relation. Les commentaires du
> code de "redaction" semblent dirent le contraire (le way ne sera pas
> supprimé, mais reconstruit sans les nodes en cause) :
>
> "# if an acceptor creates a way, a decliner adds some nodes but doesn't
>  # change the tags in a subsequent edit, then we just need to roll back
>  # the nodes changes."

Oui mais il y a déjà eu des essais. Partout où ces essais sont passés
on a vu des ways déconnectés, des noeuds laissés sans way pour les
relier, des relations et de nombreuses géométries cassées. Il n'est
malheureusement pas possible de suivre tous les cas des anciennes
contributions. Tout bonnement car leurs contributeurs sont devenus
injoignables.

Ce changement de licence tiendra combien de temps ? On comprend aussi
que les collectivités hésitent à accepter d'autres licences que les
leurs même si elles sont ouvertes : elles sont concernées par la
stabilité et la pérénité de leurs données. Il manque un cadre légal
pour rendre les licences compatibles entre elles avec un cadre minimum
mais suffisant au moins à l'échelle d'un pays (si ce n'est de l'Union
européenne même pour la France).

Il fudra réfléchir pour qu'OSM évolue vers des jeux de données
multiples mais qui restent séparables en couches, chacune avec leur
licence et leur attribution, mais chacune pérène. A force de tout
mélanger, on aboutit à cette aberration qui est la destruction de
données pourtant parfaitement Open, et à dénigrer le travail fait
précédemment.

Une façon de faire serait d'avoir des jeux de données à revalider
régulièrement pour assurer leur fraicheur, mais ne rien effacer mais
plutôt exporter dans des couches historiques qui resteraient
sélectionnables pour compléter des trous non couvert. Ensuite on peut
développer des algorithmes pour trouver des corrélations entre les
couhes et les afficher. Car au passage ce changement de licence ne
change rien concernant les attributions : c'est le même Copyright
"OpenStreetMap et ses contributeurs, avec seulement en plus un
intervalle de dates". Toutes les données n'étant jamais affichées
simultanément sur une carte pratique, on peut simplifier les cas mais
OSM mélange tout au même niveau et sera de plus en plus difficile à
réutiliser.

De même il me parait incompréhensible de supprimer des limites
administratives dont la source réelle est publique, quel que soit
l'identité de celui qui les a importées. Car quoi qu'on fasse ce sera
toujours la donnée publique qui servira de référence pour les
modifications utltérieures (qu'elles soient à jour ou pas, ou sous
découpées pour créer d'autres objets).

En France, on en reviendra forcément à un moment donné au cadastre
même s'il y a eu des ajustements liés aux référenciels des
projections. On pourrait discuter de l'utilité à terme d'importer
directement dans OSM ces données publiques, au lieu de créer des
outils permettant d'utiliser par une APA commune ou des API de
conversion automatique, les données publiques telles qu'elles sont à
leur source, même si on ajoute des caches. Et de la possibilité
d'avoir un retour "qualité" sur ces données pour que les modifs
proposées soient évaluées, et recentralisées de façon fiable. Mais la
permanence et la stabilité des licences ne devrait pas être une
option. OK on peut ajouter des licences (c'est aux auteurs de le faire
pas à OSM lui-même), pas en supprimer. On devrait tous dans nos
comptes utilisateurs avoir la possibilité de lister un jeu de licences
approuvées sans en retirer aucune.

Cette migration destructrice est un énorme gachis de ressource, de
temps, et de bonne volonté, qui contrevient à la volonté initiale des
contributeurs. Un exemple qu'il ne faudra pas reproduire (et tant pis
si plus tard certains en "abusent", on trouvera des moyens techniques
de limiter les abus d'usage pour que cela n'empêche pas les autres
d'utiliser les données). Un autodafé moderne digne du Moyen-Âge et de
l'Inquisition.

_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Répondre à