Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
2012/7/12 Vincent de Chateau-Thierry : > Sachant que le lien... est issu d'ici :-) : > http://lists.openstreetmap.org/pipermail/talk-fr/2010-November/028582.html Oui, je m'en souvient ;) Mais cela ne change rien à ma réponse. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Bonjour, > De : "Pieren" > > A propos du lien, il vaudrait mieux abriter un vrai article sur le site > osm.fr. > Sachant que le lien... est issu d'ici :-) : http://lists.openstreetmap.org/pipermail/talk-fr/2010-November/028582.html vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Mauvais lien pour OSM.fr ! A moins que nous faisions de la construction métallique :) Plus sérieusement, cela vaudrait peut être le coup de le préciser car à mon sens, cela entretient la confusion. Les nouveaux utilisateurs signent pour de l'ODBL ils n'ont donc pas connaissance de cet épisode CC-By-SA. Mais à vous de voir, c'est un point de détails de toute façon. A. 2012/7/12 Pieren > 2012/7/12 Arnaud Vandecasteele : > > > qu'en pensez-vous ? > > Je pense qu'il faudra changer le jour où ça changera sur osm.org. Pour > l'instant, ça reste du cc-by-sa jusqu'à ce que l'entier de la base > soit en odbl. > > A propos du lien, il vaudrait mieux abriter un vrai article sur le site > osm.fr. > > Pieren > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > -- Arnaud Van De Casteele Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - Spatial Ontology - GeoCollaboration Web Site http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/ http://geotribu.net/ http://www.i2c.eu/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
2012/7/12 Arnaud Vandecasteele : > qu'en pensez-vous ? Je pense qu'il faudra changer le jour où ça changera sur osm.org. Pour l'instant, ça reste du cc-by-sa jusqu'à ce que l'entier de la base soit en odbl. A propos du lien, il vaudrait mieux abriter un vrai article sur le site osm.fr. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Au passage, je me demande si avec ce changement de licence il ne serait pas opportun de changer la ligne qui est sur la page d’accueil de openstreetmap.fr : "Les données cartographiques collectées sont ré-utilisables sous licence libre (CC-by-SA)" Nous pourrions en profiter également pour mettre un lien vers le wiki de la licence ODBL ainsi que ce lien [1] expliquant l'historique du changement, qu'en pensez-vous ? A. [1] http://media.baliz-geospatial.com/fr/article/openstreetmap-changement-de-licence-historique-et-d%C3%A9bat-actuel-osm-openstreetmap 2012/7/11 Christian Quest > C'est sûr que travailler sur de très grandes zones chargées > intégralement n'est pas gérable avec les éditeurs actuels qui ne sont > pas conçus pour ça. > C'est sûr aussi que travailler sur des objets sans charger les données > avoisinantes est le meilleur moyen de mettre la pagaille. > > Une solution ? Oui, peut être... enfin voici la mienne: > > Quand je travaille sur des relations étendues (par exemple la limite > d'un département ou d'une région), je charge les membres de la > relation. > > J'utilise ensuite "Téléchargement le long...", fonction ajoutée par le > plugin JOSM "download_along" qui permet de charger par petites zones > (réglable avant chargement) le long d'un ou plusieurs chemins > sélectionnés. > > De cette façon, je charge juste ce qu'il faut, je ne risque pas de > mettre la pagaille, mon JOSM n'a pas besoin de plus de 2Go de RAM et > il reste très réactif. > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > -- Arnaud Van De Casteele Mines Paris Tech - CRC Sophia-Antipolis 0698 24 25 29 SIG - WebMapping - Spatial Ontology - GeoCollaboration Web Site http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/ http://geotribu.net/ http://www.i2c.eu/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
C'est sûr que travailler sur de très grandes zones chargées intégralement n'est pas gérable avec les éditeurs actuels qui ne sont pas conçus pour ça. C'est sûr aussi que travailler sur des objets sans charger les données avoisinantes est le meilleur moyen de mettre la pagaille. Une solution ? Oui, peut être... enfin voici la mienne: Quand je travaille sur des relations étendues (par exemple la limite d'un département ou d'une région), je charge les membres de la relation. J'utilise ensuite "Téléchargement le long...", fonction ajoutée par le plugin JOSM "download_along" qui permet de charger par petites zones (réglable avant chargement) le long d'un ou plusieurs chemins sélectionnés. De cette façon, je charge juste ce qu'il faut, je ne risque pas de mettre la pagaille, mon JOSM n'a pas besoin de plus de 2Go de RAM et il reste très réactif. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Le 11 juillet 2012 14:52, Vincent de Chateau-Thierry a écrit : > >> De : "Philippe Verdy" >> >> Ce sont des transferts peu fréquents et peu volumineux, mais pourtant >> nécessaires. Ce n'est pas une question de façon de faire : il y a des >> objets dans OSM qui sont très volumineux, et fréquemment cassés. Qu'il >> est impossible de réparer autrement que de cette façon. >> > > Si justement, tout est dans la façon de faire. Tu parlais jusque là de > téléchargement > de "grandes zones". Alors qu'il apparaît que ton besoin est de corriger un > objet de > grande étendue. Inutile de charger toute la zone dans laquelle est inclus > l'objet à > corriger. En utilisant le menu de JOSM "Fichier > Télécharger un objet", tu > contournes > le problème. C'est bien ce que je fais, mais il y a d'autres difficultés ! En ne chargeant qu'un seul objet et pas les autres objets qui l'utilisent par référence (un ou plusieurs ways référencent des nœuds, ways, nœuds et relations peuvent être référencés par d'autres relations), on aboutit à les casser. Moralité on doit combiner le chargement d'un objet avec celui d'une microzone rectangulaire contenant tous les objets référençant un noeud autour duquel on fait une modification, afin de s'assurer qu'aucun ne soit oublié. Modifier une grande zone n'est pas une partie de plaisir : impossible de le faire dans Potlatch 2 qui veut charger tous les objets d'une zone rectangulaire dans leur totalité, et JOSM n'aide pas non plus en vérifiant automatiquement les dépendances pour les charger avant de faire une modif locale : les oublis sont vite arrivés !). Nombreux sont ceux qui ne le font pas et se contentent de modifier un seul objet qui les intéresse, et oublient le reste, par exemple en coupant un chemin en deux alors qu'il est aussi utilisé dans d'autres relations : c'est à mon avis la principale raison pour laquelle des objets sont cassés (surtout les relations), et aussi le danger qu'on va voir avec les destructions annoncées qui ne vérifient pas toutes les dépendances, quand ils vont annuler des modifs, supprimer des nœuds, refusionner des chemins qui ont été découpés (cela génère localement des géométries valides pour l'objet en cours d'analyse mais ça oublie les autres objets qui ont ne sont pas sensés être fondamentalement modifiés). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
> De : "Philippe Verdy" > > Ce sont des transferts peu fréquents et peu volumineux, mais pourtant > nécessaires. Ce n'est pas une question de façon de faire : il y a des > objets dans OSM qui sont très volumineux, et fréquemment cassés. Qu'il > est impossible de réparer autrement que de cette façon. > Si justement, tout est dans la façon de faire. Tu parlais jusque là de téléchargement de "grandes zones". Alors qu'il apparaît que ton besoin est de corriger un objet de grande étendue. Inutile de charger toute la zone dans laquelle est inclus l'objet à corriger. En utilisant le menu de JOSM "Fichier > Télécharger un objet", tu contournes le problème. > Oui cela m'expose à des conflits d'édition même pour une modif > microscopique. C'est assez ingrat mais pourtant nécessaire. Sinon la > base OSM n'aurait plus depuis longtemps des contours de côtes, de > régions, de pays. Merci pour ton abnégation :-) Mais la correction d'une limite de région (c'est un exemple) ne nécessite pas de charger toute la relation qui décrit cette entité administrative, quoi que tu dises. Et quand bien même tu aurais besoin de charger toute cette relation, avec le miroir ".fr" de l'api, ça se fait sans problème aucun. Une région cassée, c'est quasi à chaque fois des départements cassés, au même endroit, voire des arrondissements, comcom et communes. Bref, en prenant le diagnostic sous l'angle local, grâce par exemple à une visu sur layers.openstreetmap.fr des couches communale ou EPCI, il est largement possible de réparer de grosses entités sans, à aucun moment, avoir dû les charger en entier ni vérifier la connexion des ways qui les composent (autre point qui revient souvent dans ton discours). Si tu trouves ça si pénible, n'hésite pas à zapper, d'autres sauront s'en occuper (j'ai les noms :-) ). > Même pour une modif microscopique comme ajouter une plage ou une > petite île, ou ajouter un petit affluebt à un long fleuve, on est > amené à modifier des objets très grands (essentiellement des relations > contenant de nombreux membres dont celui à modifer), et même assez > souvent de multiples objets (des relations qui partagent des objets > communs. > Il ne faut pas confondre la lourdeur des géométries qui composent une relation, et la lourdeur (infime par comparaison) de la définition d'une relation. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Le 11 juillet 2012 10:28, Pieren a écrit : > 2012/7/11 Philippe Verdy : > >> JOSM va être quasiment inutilisable. On va se borner à utiliser >> Potlatch 2 dans les petites zones qu'il veut bien charger. > > Pour les autres lecteurs de cette liste : nous recommandons > généralement de travailler sur de petites zones lorsqu'on édite les > données OSM et de faire des transferts fréquents vers la base, surtout > si vous travaillez à plusieurs au même endroit (ce qui est le cas > durant les mapping parties ou les formations). Philippe V. semble > travailler sur d'immenses zones en hors ligne et avec des transferts > peu fréquents vers la base principale, ce qui l'oblige à utiliser une > machine sur-puissante et augmente considérablement les risques de > conflits au moment du transfert. C'est à dire qu'il cummule tous les > inconvénients sans qu'il nous explique les avantages ou les raisons de > cette manière de faire (on peut imaginer qu'il n'a pas accès à > internet en permanence, par exemple). Ce sont des transferts peu fréquents et peu volumineux, mais pourtant nécessaires. Ce n'est pas une question de façon de faire : il y a des objets dans OSM qui sont très volumineux, et fréquemment cassés. Qu'il est impossible de réparer autrement que de cette façon. Oui cela m'expose à des conflits d'édition même pour une modif microscopique. C'est assez ingrat mais pourtant nécessaire. Sinon la base OSM n'aurait plus depuis longtemps des contours de côtes, de régions, de pays. Même pour une modif microscopique comme ajouter une plage ou une petite île, ou ajouter un petit affluebt à un long fleuve, on est amené à modifier des objets très grands (essentiellement des relations contenant de nombreux membres dont celui à modifer), et même assez souvent de multiples objets (des relations qui partagent des objets communs. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
De : "f.dos.san...@free.fr" Petite erreur de date, c'est Mai 2010 pour les nouveaux inscrits et ça fait plus d'un an qu'il est impossible de contribuer si on n'a pas accepté la nouvelle licence. oh la faute de frappe ! merci pour la correction ! Julien___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Selon THEVENON Julien : > De : Balaitous > Comment faire pour savoir si on utilise la bonne licence ? > > Si tu arrives encore a faire des editions ou que tu as cree ton compte OSM > apres mai 2012 alors tu as deja accepte la nouvelle licence. > Sinon en cas de doute regarde ton profil ( une url du genre > http://www.openstreetmap.org/user/balaitous ) c est ecrit si tu as accepte la > nouvelle licence ou pas > > Julien > Petite erreur de date, c'est Mai 2010 pour les nouveaux inscrits et ça fait plus d'un an qu'il est impossible de contribuer si on n'a pas accepté la nouvelle licence. Pour l'historique voir : http://wiki.openstreetmap.org/wiki/Open_Data_License/Implementation_Plan ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
>>>> De : Balaitous >>>> Comment faire pour savoir si on utilise la bonne licence ? Si tu arrives encore a faire des editions ou que tu as cree ton compte OSM apres mai 2012 alors tu as deja accepte la nouvelle licence. Sinon en cas de doute regarde ton profil ( une url du genre http://www.openstreetmap.org/user/balaitous ) c est ecrit si tu as accepte la nouvelle licence ou pas Julien > > De : Balaitous >À : Discussions sur OSM en français >Envoyé le : Mercredi 11 juillet 2012 11h01 >Objet : Re: [OSM-talk-fr] Démarrage de la destruction des données (transition >ODbL) > >Bonjour, > >Comment faire pour savoir si on utilise la bonne licence ? > >Merci >Balaitous > > >Le mardi 10 juillet 2012 à 09:47 +0200, Eric Marsden a écrit : >> [Vu sur la liste de diffusion principale, t...@openstreetmap.org. Ceci >> est une information et non une traduction du message d'annonce.] >> >> Le robot qui supprimera les données incompatibles avec la licence ODbL et >> les termes du contributeur (c'est à dire, des données qui, à un moment >> dans leur historique, ont été modifiées par un utilisateur n'ayant pas >> accepté les termes du contributeur) devrait commencer son travail le mercredi >> 11 juillet (demain). >> >> Le robot tournera par zone géographique, dans l'ordre suivant: >> >> Ireland >> UK >> Western Europe >> North America >> Australia >> rest of the world >> >> Une fois ce travail de suppression des contributions terminé, les >> données OSM ne seront plus distribuées que sous la nouvelle licence >> expérimentale ODbL. Il est prévu que le processus de destruction des >> données dure environ un mois. >> >> Les serveurs et API continueront à fonctionner pendant cette période, >> sans interruption de service. Il est conseillé de sauvegarder plus >> souvent son travail lorsque le robot destructeur travaille dans sa >> zone, pour éviter les conflits d'édition. >> >> Ce processus était prévu pour démarrer début avril, mais sa composante >> technique avait été insuffisamment planifiée, d'où le retard dans sa >> mise en oeuvre. >> >> >> Message d'origine en anglais: >> >> http://blog.osmfoundation.org/2012/07/09/licence-redaction-ready/ >> > > > >___ >Talk-fr mailing list >Talk-fr@openstreetmap.org >http://lists.openstreetmap.org/listinfo/talk-fr > > >___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Bonjour, Comment faire pour savoir si on utilise la bonne licence ? Merci Balaitous Le mardi 10 juillet 2012 à 09:47 +0200, Eric Marsden a écrit : > [Vu sur la liste de diffusion principale, t...@openstreetmap.org. Ceci > est une information et non une traduction du message d'annonce.] > > Le robot qui supprimera les données incompatibles avec la licence ODbL et > les termes du contributeur (c'est à dire, des données qui, à un moment > dans leur historique, ont été modifiées par un utilisateur n'ayant pas > accepté les termes du contributeur) devrait commencer son travail le mercredi > 11 juillet (demain). > > Le robot tournera par zone géographique, dans l'ordre suivant: > > Ireland > UK > Western Europe > North America > Australia > rest of the world > > Une fois ce travail de suppression des contributions terminé, les > données OSM ne seront plus distribuées que sous la nouvelle licence > expérimentale ODbL. Il est prévu que le processus de destruction des > données dure environ un mois. > > Les serveurs et API continueront à fonctionner pendant cette période, > sans interruption de service. Il est conseillé de sauvegarder plus > souvent son travail lorsque le robot destructeur travaille dans sa > zone, pour éviter les conflits d'édition. > > Ce processus était prévu pour démarrer début avril, mais sa composante > technique avait été insuffisamment planifiée, d'où le retard dans sa > mise en oeuvre. > > > Message d'origine en anglais: > >http://blog.osmfoundation.org/2012/07/09/licence-redaction-ready/ > ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
2012/7/11 Philippe Verdy : > JOSM va être quasiment inutilisable. On va se borner à utiliser > Potlatch 2 dans les petites zones qu'il veut bien charger. Pour les autres lecteurs de cette liste : nous recommandons généralement de travailler sur de petites zones lorsqu'on édite les données OSM et de faire des transferts fréquents vers la base, surtout si vous travaillez à plusieurs au même endroit (ce qui est le cas durant les mapping parties ou les formations). Philippe V. semble travailler sur d'immenses zones en hors ligne et avec des transferts peu fréquents vers la base principale, ce qui l'oblige à utiliser une machine sur-puissante et augmente considérablement les risques de conflits au moment du transfert. C'est à dire qu'il cummule tous les inconvénients sans qu'il nous explique les avantages ou les raisons de cette manière de faire (on peut imaginer qu'il n'a pas accès à internet en permanence, par exemple). Durant l'execution du bot, il pourra y avoir des conflits mais les risques sont les mêmes, quel que soit l'éditeur. > Ce changement de licence tiendra combien de temps ? On comprend aussi > que les collectivités hésitent à accepter d'autres licences que les > leurs On se demande même pourquoi des collectivités (Paris, par exemple) ont adopté Odbl pour leur données libérées. Au lieu de voir ça avec leurs services juridiques, ils auraient dû te consulter d'abord. > 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. Si tu étais abonné à la liste de diffusion talk ou legal-talk, tu saurais que cette question a été abordée à plusieurs reprises. Concrètement, il n'est pas possible de séparer les données par licenses, il y a trop de dépendences entre elles. Ou alors, tu fais ta propre base de données OSM et tu la publies sous la license que tu veux, mais séparée. Il y a même un projet qui continue en cc-by-sa2.0, il s'appelle fosm (fork osm). Le sujet sur la re-validation des données après un certain temps est un autre sujet, qui n'a rien à voir avec les licenses. D'ailleurs, quelqu'un vient de sortir un prototype de carte 'staleness' : http://mvexel.dev.openstreetmap.org/staleness/amsterdam.html Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
De : Philippe Verdy En Espagne, et en France, les commentaires étaient clairs sur ces destructions faites sous prétexte que ce n'était pas en ODdBL. Aussi sur la majeure partie des lignes de côtes européennes. Certains ont anticipé le changement de licence sans suivre les règles (et c'est pour ça que j'avais cru un moment que la nouvelle licence était déjà en vigueur). Il ne faut pas confondre ce qu ont fait certains contributeurs avec ce que le bot va faire, ca me parait un peu abusif de tirer des conclusions sur ce que va faire le bot a partir de modifs faites des contributeurs Lers membres de l equipe rebuild ont fait beaucoup de tests pour justement essayer de minimiser la casse. Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Le 11 juillet 2012 08:53, THEVENON Julien a écrit : > Cetait ou ? > Jusqu a maintenant tous les tests ont ete faits dans une base de donnee > separee d apres ce qu j ai lu sur la mailing liste dediee. En Espagne, et en France, les commentaires étaient clairs sur ces destructions faites sous prétexte que ce n'était pas en ODdBL. Aussi sur la majeure partie des lignes de côtes européennes. Certains ont anticipé le changement de licence sans suivre les règles (et c'est pour ça que j'avais cru un moment que la nouvelle licence était déjà en vigueur). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Le 11 juillet 2012 07:49, Vincent de Chateau-Thierry 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
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
De : Philippe Verdy Des suppressions ont déjà été tentées, on voyait disparaître ça et là des régions entières voire des pays, des îles intérieures sur les fleuves, des forêts et des communes en doublon lors des tentatives de reconstruction. Il y a eu déjà des reconstructions de côtes, parfois avec des décalages importants ou des précisions abitraire (souvent aussi avec beaucoup plus de points que nécessaire, mais aussi des oublis dans les relations référentes : par exemple juste le pays, mais pas une plage). Cetait ou ? Jusqu a maintenant tous les tests ont ete faits dans une base de donnee separee d apres ce qu j ai lu sur la mailing liste dediee. Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Bonjour, Le 11/07/2012 04:59, Philippe Verdy a écrit : Pendant un mois donc, travailler sur une zone assez grande va être un enfer. Il ne te reste plus qu'à travailler sur une zone "assez petite"... 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." lu ici : https://github.com/gravitystorm/openstreetmap-license-change/blob/against_api/test_way.rb Des suppressions ont déjà été tentées, on voyait disparaître ça et là des régions entières voire des pays, des îles intérieures sur les fleuves, des forêts et des communes en doublon lors des tentatives de reconstruction. Des pays, passe encore. Mais des communes, ah ça non ! :-) Il y a eu déjà des reconstructions de côtes, parfois avec des décalages importants ou des précisions abitraire (souvent aussi avec beaucoup plus de points que nécessaire, mais aussi des oublis dans les relations référentes : par exemple juste le pays, mais pas une plage). Les communautés de communes vont être vite à la ramasse (et ce sera d'autant plus difficile à corriger en France car on n'aura pas gardé leur composition par des membres "subarea", comme cela a été fait partout ailleurs où les trous seront faciles à reboucher sans faire beaucoup de recherches...) Inutile de spéculer : on a aujourd'hui presque 1600 comcom en base, dont moins de 200 ont plus d'un an. La casse (si casse) devrait être très limitée. Après, si un way en limite administrative, qui participe à une limite de comcom, saute du fait de sa licence, il ne sera pas sorcier de le recomposer. S'il y a bien un domaine où les sources ne manquent pas, c'est bien celui-là, avec le cadastre. Plus les relations couvriront des surfaces importantes, plus elles seront difficiles à reboucher, surtout en France. Si ce n'est pas dramatique de voir disparaître des POIs isolés ou des numéros de rue (on complète visuellement ce qui manque et on a d'autres moyens de repérage proches) pour les grandes zones qu'il est impossible de charger en totalité (millions de points que le serveur ne sait pas servir à la demande) on va avoir des trous un peu partout. Des petites zones, Philippe, des petites zones. Ton besoin, récurrent, de charger des zones "monstres" m'a toujours interpellé. Ça rejoint ce questionnement récent (sans réponse) : http://lists.openstreetmap.org/pipermail/dev-fr/2012-July/001032.html Les relations seront les plus délicates à restaurer il va y avoir beaucoup de nouvelles erreurs d'interprétation du résiduel lors de ces reconstructions. J'ai peut que dans de nombreux endroits on devra se contenter de tout réimporter... en masse. Quitte ensuite à éliminer ensuite des tonnes de doublons. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Pendant un mois donc, travailler sur une zone assez grande va être un enfer. 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). Des suppressions ont déjà été tentées, on voyait disparaître ça et là des régions entières voire des pays, des îles intérieures sur les fleuves, des forêts et des communes en doublon lors des tentatives de reconstruction. Il y a eu déjà des reconstructions de côtes, parfois avec des décalages importants ou des précisions abitraire (souvent aussi avec beaucoup plus de points que nécessaire, mais aussi des oublis dans les relations référentes : par exemple juste le pays, mais pas une plage). Les communautés de communes vont être vite à la ramasse (et ce sera d'autant plus difficile à corriger en France car on n'aura pas gardé leur composition par des membres "subarea", comme cela a été fait partout ailleurs où les trous seront faciles à reboucher sans faire beaucoup de recherches...) Plus les relations couvriront des surfaces importantes, plus elles seront difficiles à reboucher, surtout en France. Si ce n'est pas dramatique de voir disparaître des POIs isolés ou des numéros de rue (on complète visuellement ce qui manque et on a d'autres moyens de repérage proches) pour les grandes zones qu'il est impossible de charger en totalité (millions de points que le serveur ne sait pas servir à la demande) on va avoir des trous un peu partout. Les relations seront les plus délicates à restaurer il va y avoir beaucoup de nouvelles erreurs d'interprétation du résiduel lors de ces reconstructions. J'ai peut que dans de nombreux endroits on devra se contenter de tout réimporter... en masse. Quitte ensuite à éliminer ensuite des tonnes de doublons. Le 10 juillet 2012 11:49, Christian Quest a écrit : > Il y a juste un risque plus grand de se retrouver en conflit d'édition > si le robot est en train de bosser sur la zone qu'on modifie... > > > Le 10 juillet 2012 11:46, Vincent Privat a écrit : >> Autre info liée: normalement ce processus ne devrait pas avoir d'impact >> notable sur les éditeurs. >> Si cependant vous constatez des soucis avec JOSM sur les zones impactées, on >> a déjà un ticket tout prêt pour ça: >> >> http://josm.openstreetmap.de/ticket/7505 >> > > -- > Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Il y a juste un risque plus grand de se retrouver en conflit d'édition si le robot est en train de bosser sur la zone qu'on modifie... Le 10 juillet 2012 11:46, Vincent Privat a écrit : > Autre info liée: normalement ce processus ne devrait pas avoir d'impact > notable sur les éditeurs. > Si cependant vous constatez des soucis avec JOSM sur les zones impactées, on > a déjà un ticket tout prêt pour ça: > > http://josm.openstreetmap.de/ticket/7505 > -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Le 10 juillet 2012 09:47, Eric Marsden a écrit : > Ceci est une information et non une traduction du message d'annonce. > > Merci pour l'info, et aussi pour la précision. Autre info liée: normalement ce processus ne devrait pas avoir d'impact notable sur les éditeurs. Si cependant vous constatez des soucis avec JOSM sur les zones impactées, on a déjà un ticket tout prêt pour ça: http://josm.openstreetmap.de/ticket/7505 Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Eric a ?crit : Je me posais justement la question ce week end : en faisant des évolutions, je voyais dans l'historique du point des personnes n'ayant pas accepté les nouvelles conditions. Donc mes modifs seront perdues j'imagine. G [...] J'espere que le p'tit robot a été bien testé, il va chauffer .. Ils ont défini à peu près 300 tests élémentaires représentant les différents cas où il faut supprimer ou pas les données. Ca visait justement à réduire les pertes par exemple dans les cas où il ne reste plus rien du contributeur initial. La base sera verrouillée quand il bossera sur une zone ? Pas que je sache. Mais il est globalement déconseiller de faire des imports massifs durant cette période (mais plus personne ne fait d'import massif dans OSM ;-) Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Je me posais justement la question ce week end : en faisant des évolutions, je voyais dans l'historique du point des personnes n'ayant pas accepté les nouvelles conditions. Donc mes modifs seront perdues j'imagine. G Je pensais que le tri avait déjà été fait. J'espere que le p'tit robot a été bien testé, il va chauffer ..La base sera verrouillée quand il bossera sur une zone ? Le 10 juillet 2012 09:47, Eric Marsden a écrit : > [Vu sur la liste de diffusion principale, t...@openstreetmap.org. Ceci > est une information et non une traduction du message d'annonce.] > > Le robot qui supprimera les données incompatibles avec la licence ODbL et > les termes du contributeur (c'est à dire, des données qui, à un moment > dans leur historique, ont été modifiées par un utilisateur n'ayant pas > accepté les termes du contributeur) devrait commencer son travail le > mercredi > 11 juillet (demain). > > Le robot tournera par zone géographique, dans l'ordre suivant: > > Ireland > UK > Western Europe > North America > Australia > rest of the world > > Une fois ce travail de suppression des contributions terminé, les > données OSM ne seront plus distribuées que sous la nouvelle licence > expérimentale ODbL. Il est prévu que le processus de destruction des > données dure environ un mois. > > Les serveurs et API continueront à fonctionner pendant cette période, > sans interruption de service. Il est conseillé de sauvegarder plus > souvent son travail lorsque le robot destructeur travaille dans sa > zone, pour éviter les conflits d'édition. > > Ce processus était prévu pour démarrer début avril, mais sa composante > technique avait été insuffisamment planifiée, d'où le retard dans sa > mise en oeuvre. > > > Message d'origine en anglais: > >http://blog.osmfoundation.org/2012/07/09/licence-redaction-ready/ > > -- > Eric Marsden > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
[Vu sur la liste de diffusion principale, t...@openstreetmap.org. Ceci est une information et non une traduction du message d'annonce.] Le robot qui supprimera les données incompatibles avec la licence ODbL et les termes du contributeur (c'est à dire, des données qui, à un moment dans leur historique, ont été modifiées par un utilisateur n'ayant pas accepté les termes du contributeur) devrait commencer son travail le mercredi 11 juillet (demain). Le robot tournera par zone géographique, dans l'ordre suivant: Ireland UK Western Europe North America Australia rest of the world Une fois ce travail de suppression des contributions terminé, les données OSM ne seront plus distribuées que sous la nouvelle licence expérimentale ODbL. Il est prévu que le processus de destruction des données dure environ un mois. Les serveurs et API continueront à fonctionner pendant cette période, sans interruption de service. Il est conseillé de sauvegarder plus souvent son travail lorsque le robot destructeur travaille dans sa zone, pour éviter les conflits d'édition. Ce processus était prévu pour démarrer début avril, mais sa composante technique avait été insuffisamment planifiée, d'où le retard dans sa mise en oeuvre. Message d'origine en anglais: http://blog.osmfoundation.org/2012/07/09/licence-redaction-ready/ -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
