Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
2012/10/23 Philippe Verdy verd...@wanadoo.fr: Certes, mais la validité sera encore pire si on le stocke dans l'objet, car cette information va s'appliquer automatiquement à toutes les versions suivantes et toutes les autres modifications faites à l'objet, dont pourtant les sources n'ont rien à voir avec la source initiale. Si on veut être précis, la source ne concerne QUE chaque modification entre deux versions d'un même objet. Autrement dit cette source n'est pas non plus l'utilisateur lui-même, mais c'est bien un attribut du changeset, dans lequel le contributeur qui le soumet devra mentionner les sources utilisées au delà de son propre travail personnel sur ces données, où le contributeur est implicitement aussi une source). Si je prend un exemple : on utilise le cadastre une année pour importer un bâtiment. Il est source de ce tracé. Plus tard, le bâtiment est entièrement modifié pourtant la source lui survit dans l'objet ou dans certaines de ses versions historiques, mais on met alors la nouvelle source. Plus tard encore, le cadastre est réutilisé dans un nouveau millésime (parfois le même) et redéfinit à nouveau la plupart des caractéristiques de l'objet : comment doit-on interpréter les différentes sources entre les versions successives ? Evidemment la seule interprétation possible c'est version par version. Le changeset est le seul lieu approprié pour mettre les infos spécifiques à chaque version. La base de données reste interrogeable objet par ojet pour voir la liste des versions, et pour chacune le changeset concerné qui mentionne la ou les sources utilisées et qui permet aussi de ce qui est ajouté, modifié ou supprimé par rapport à la version précédente par l'utilisateur qui l'a soumis (cet utilisateur s'ajoutant aux autres sources qu'il indique dans son changeset). S'il faut continuer sur cette voie, il faudra automatiser et systématiser d'avantage dans les éditeurs le renseignement des changeset afin que ces sources puissent être facilement indiquées (par des simple cases à cocher, ou automatiquement si on utilise certaines couches visibles dans l'éditeur à l'endroit où l'objet était modifié dans sa géométrie, mais ce ne sera pas automatique pour les tags textuels dont la source n'a le plus souvent rien à voir avec celle des autres fonds de carte utilisés : les éditeurs devraient alors pouvoir inclure un petit onglet de navigation web, mémorisant les URLs ou domaines visitées, afin de permettre un copier-coller éventuel depuis cet onglet, si la source web est autorisée comme source libre pour ces éléments textuels, de même l'utilisateur devrait avoir dans son carnet perso de sources une liste de sources qu'il lui suffit d'activer d'un clic pour que cela figure dans les propriétés du changeset qu'il va soumettre). Chaque changeset contiendra donc une liste de sources (de même qu'il contient déjà le nom de l'utilisateur), uniquement celles concernées par la modification. Les autres sources des parties non modifiées ou des anciennes versions persistent dans la base dans les changesets associés aux versions dans lesquelles sont apparues les données. Cette liste de sources est facilement intérrogeable, mais si on veut faciliter leur affichage, on peut développer dans l'API un type de requête simple permettant de les avoir de façon exhautives pour toutes les données et attributs d'un objet qui sont encore visibles, simplement en groupant ces données visibles par changeset, en ordre antéchronologique où elles sont apparues, le serveur alors générant dans ses résultats une liste de versions pertinentes d'un objet, où celle-ci mentionne les sources du changeset associé). Bon, je crois qu'il faut revenir un peu sur terre, là. Nous sommes un projet collaboratif ouvert à tous les publics. Ca sera déjà bien si quelqu'un écrit un commentaire pertinent dans son changeset. Alors compter sur l'ajout de la source qui sera uniforme pour un changeset... L'essentiel des tags sources proviennent des imports. Si vous voyez un bâtiment en version 2 ou + , je peux déjà vous dire que : soit la géométrie a changé et ça vient de l'imagerie aérienne, soit des tags supplémentaires ont catégoriser le bâti et la personne qui ne fait pas l'effort de citer sa source ne le fera pas plus que pour d'autres éléments, ni sur le changeset. L'important au final, c'est d'avoir respecter notre obligation au moment de l'import. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
On lundi 22 octobre 2012, Vincent Privat wrote: Bwouf, vu les symptômes que tu décris, ça a l'air d'être bordélique côté implémentation, va falloir creuser et améliorer ça :) Quand tu dis va falloir, tu intègres un je là dedans ;-) ? Ouvrir un ticket sur JOSM, ça je peux faire, je fais ? Ne connaissant pas bien les entrailles de la bête, j'imagine que la gestion des tags de changeset sont venus un peu au fûr et à mesure, et je suppose qu'il n'y a pas un mécanisme unique est défini pour les enlever, en rajouter, les ré-utiliser, etc. ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
J'intègre le je oui :) Dès que je finis de mettre en place le serveur WMS sur osm107 ! Mais tu peux créer un ticket, oui, ça évitera que j'oublie. Pense à bien détailler toutes les conneries que tu vois :) Je n'ai aucune idée pour l'instant de la façon dont c'est implémenté donc je ne peux pas répondre à tes dernières questions, là. Le 23 octobre 2012 16:21, sly (sylvain letuffe) li...@letuffe.org a écrit : On lundi 22 octobre 2012, Vincent Privat wrote: Bwouf, vu les symptômes que tu décris, ça a l'air d'être bordélique côté implémentation, va falloir creuser et améliorer ça :) Quand tu dis va falloir, tu intègres un je là dedans ;-) ? Ouvrir un ticket sur JOSM, ça je peux faire, je fais ? Ne connaissant pas bien les entrailles de la bête, j'imagine que la gestion des tags de changeset sont venus un peu au fûr et à mesure, et je suppose qu'il n'y a pas un mécanisme unique est défini pour les enlever, en rajouter, les ré-utiliser, etc. ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
On samedi 20 octobre 2012, Marc Sibert wrote: re, Le problème de la répétition est un détail technique lié à l'implémentation du modèle de données. C'est tout à fait vrai. Toutefois, la présence des tags de type source sur les objets eux même présente un vrai défaut : Lorsqu'un contributeur modifie l'objet en question de telle sorte que la source ne s'applique plus, il lui arrive souvent de l'oublier. Avec un tag dans le changeset, on pourra, une fois les outils plus au point, mieux se rendre compte d'a quel moment l'édit utilisant la source est intervenu, et ce qui s'est passé après. Je me permet d'ailleurs de signaler ma proposition d'uniformisation ici : http://wiki.openstreetmap.org/wiki/Proposed_features/changeset_tags Et j'aimerais bien l'appliquer, une fois stabilisée, à nos exports de fichiers .osm en provenance du cadastre. Et pas juste pour faire plaisir au DWG, mais aussi car je pense que ça peut/pourra nous servir à nous aussi de mieux identifier les imports du cadastre -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
2012/10/22 sly (sylvain letuffe) li...@letuffe.org: Toutefois, la présence des tags de type source sur les objets eux même présente un vrai défaut : Lorsqu'un contributeur modifie l'objet en question de telle sorte que la source ne s'applique plus, il lui arrive souvent de l'oublier. Avec un tag dans le changeset, on pourra, une fois les outils plus au point, mieux se rendre compte d'a quel moment l'édit utilisant la source est intervenu, et ce qui s'est passé après. Si les contributeurs n'ont pas la discipline de mettre à jour le tag source sur un objet, ils ne l'auront pas plus pour le faire sur un changeset. Autre vrai défaut du tag sur le changeset, celui-ci ne contient pas toujours des données issues d'une seule source. La validité du tag source dans OSM sera toujours sujette à caution, quel que soit l'endroit où on le stocke. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
salut, On lundi 22 octobre 2012, Pieren wrote: Si les contributeurs n'ont pas la discipline de mettre à jour le tag source sur un objet, ils ne l'auront pas plus pour le faire sur un changeset. Je sais que ce fil de discussion a été particulièrement long et que j'ai envoyé particulièrement beaucoup de messages, mais le lire en son entier n'était pas particulièrement facultatif ;-) Mais je saurais être magnanime, voici celui qu'il fallait particulièrement lire : http://lists.openstreetmap.org/pipermail/talk-fr/2012-October/050177.html Et bien que j'eusse abusé ici de l'adverbe particulièrement, la solution que j'évoque permettrait de régler tout particulièrement le problème que tu évoques (au moins dans un grand nombre de cas). Autre vrai défaut du tag sur le changeset, celui-ci ne contient pas toujours des données issues d'une seule source. C'est en effet vrai, et là, cette fois, seule la discipline peut améliorer encore. Mais ce défault me semble vrai également dans le tag source des objets avec l'avantage qu'il est plus simple de mettre un tag de source à un endroit qu'a chaque objet. Toutefois, rien n'empêche de maintenir la recommandation du tag source sur les objets mais de malgré tout commencer aussi à le mettre dans le changeset. La validité du tag source dans OSM sera toujours sujette à caution, quel que soit l'endroit où on le stocke. Je ne peux rien répondre à ça, si ce n'est que c'est aussi le cas pour absolument tout ce qui se trouve dans OSM, où que ce soit : c'est sujet à caution -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
2012/10/22 sly (sylvain letuffe) li...@letuffe.org: Mais je saurais être magnanime, voici celui qu'il fallait particulièrement lire : http://lists.openstreetmap.org/pipermail/talk-fr/2012-October/050177.html Je n'ai pas regardé les détails de ce patch mais il soulève pour moi d'autres problèmes : est-ce que les tags lus depuis le fichier .osm vont survivre à une fusion de calques dans JOSM (ce qui se fait en principe lorsqu'on intègre avec l'existant) ? Sur combien de changeset's les tags s'appliquent-ils (autremend dit, quelle est leur durée de vie dans une session d'édition) ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
On lundi 22 octobre 2012, Pieren wrote: Je n'ai pas regardé les détails de ce patch mais il soulève pour moi d'autres problèmes : est-ce que les tags lus depuis le fichier .osm vont survivre à une fusion de calques dans JOSM (ce qui se fait en principe lorsqu'on intègre avec l'existant) ? Sur combien de changeset's les tags s'appliquent-ils (autremend dit, quelle est leur durée de vie dans une session d'édition) ? Je n'ai pas étudié la question de manière précise, et je ne dis pas qu'il est la solution à tous nos problèmes en l'état, mais je pense que c'est une bonne voie à explorer en complément de ce que l'on fait déjà pour l'instant, avec l'éventuelle option, à l'avenir que cela puisse remplacer, sous condition de meilleurs résultats, que d'autres solutions. Quelques tests rapides montrent (le message que j'ai cité de moi contenait un fichier d'exemple avec un seul bâtiment et des tags pour le changeset) - un petit bug sur ma version de JOSM : si l'envoi est directement tenté, les tags ne sont pas pris en compte, un clic de souris sur la zone de travail, même sans modifs les prennent en compte - les tags survivent à la fusion avec l'existant - les tags semblent hélas être maintenus même après un premier upload, donc la suite de la session est pourrie par les tags, mais après quelques bidouilles ils sont oubliés (bon ok, c'est pas très stable cette affaire) - si on upload rien, et qu'on supprime le layer et que finalement on fait autre chose les tags vont quand même être appliqués - les tags ne survivent pas à une sauvegarde car ne sont pas remis dans le fichier .osm sauvegardé Bref, d'accord, en l'état, c'est pas super clean, mais bon, c'est pas parce que c'est mal implémenté que c'est une mauvaise idée non ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Bwouf, vu les symptômes que tu décris, ça a l'air d'être bordélique côté implémentation, va falloir creuser et améliorer ça :) Vincent Le 22 octobre 2012 14:29, sly (sylvain letuffe) li...@letuffe.org a écrit : On lundi 22 octobre 2012, Pieren wrote: Je n'ai pas regardé les détails de ce patch mais il soulève pour moi d'autres problèmes : est-ce que les tags lus depuis le fichier .osm vont survivre à une fusion de calques dans JOSM (ce qui se fait en principe lorsqu'on intègre avec l'existant) ? Sur combien de changeset's les tags s'appliquent-ils (autremend dit, quelle est leur durée de vie dans une session d'édition) ? Je n'ai pas étudié la question de manière précise, et je ne dis pas qu'il est la solution à tous nos problèmes en l'état, mais je pense que c'est une bonne voie à explorer en complément de ce que l'on fait déjà pour l'instant, avec l'éventuelle option, à l'avenir que cela puisse remplacer, sous condition de meilleurs résultats, que d'autres solutions. Quelques tests rapides montrent (le message que j'ai cité de moi contenait un fichier d'exemple avec un seul bâtiment et des tags pour le changeset) - un petit bug sur ma version de JOSM : si l'envoi est directement tenté, les tags ne sont pas pris en compte, un clic de souris sur la zone de travail, même sans modifs les prennent en compte - les tags survivent à la fusion avec l'existant - les tags semblent hélas être maintenus même après un premier upload, donc la suite de la session est pourrie par les tags, mais après quelques bidouilles ils sont oubliés (bon ok, c'est pas très stable cette affaire) - si on upload rien, et qu'on supprime le layer et que finalement on fait autre chose les tags vont quand même être appliqués - les tags ne survivent pas à une sauvegarde car ne sont pas remis dans le fichier .osm sauvegardé Bref, d'accord, en l'état, c'est pas super clean, mais bon, c'est pas parce que c'est mal implémenté que c'est une mauvaise idée non ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ 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] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Le 22 octobre 2012 13:20, sly (sylvain letuffe) li...@letuffe.org a écrit : La validité du tag source dans OSM sera toujours sujette à caution, quel que soit l'endroit où on le stocke. Je ne peux rien répondre à ça, si ce n'est que c'est aussi le cas pour absolument tout ce qui se trouve dans OSM, où que ce soit : c'est sujet à caution Certes, mais la validité sera encore pire si on le stocke dans l'objet, car cette information va s'appliquer automatiquement à toutes les versions suivantes et toutes les autres modifications faites à l'objet, dont pourtant les sources n'ont rien à voir avec la source initiale. Si on veut être précis, la source ne concerne QUE chaque modification entre deux versions d'un même objet. Autrement dit cette source n'est pas non plus l'utilisateur lui-même, mais c'est bien un attribut du changeset, dans lequel le contributeur qui le soumet devra mentionner les sources utilisées au delà de son propre travail personnel sur ces données, où le contributeur est implicitement aussi une source). Si je prend un exemple : on utilise le cadastre une année pour importer un bâtiment. Il est source de ce tracé. Plus tard, le bâtiment est entièrement modifié pourtant la source lui survit dans l'objet ou dans certaines de ses versions historiques, mais on met alors la nouvelle source. Plus tard encore, le cadastre est réutilisé dans un nouveau millésime (parfois le même) et redéfinit à nouveau la plupart des caractéristiques de l'objet : comment doit-on interpréter les différentes sources entre les versions successives ? Evidemment la seule interprétation possible c'est version par version. Le changeset est le seul lieu approprié pour mettre les infos spécifiques à chaque version. La base de données reste interrogeable objet par ojet pour voir la liste des versions, et pour chacune le changeset concerné qui mentionne la ou les sources utilisées et qui permet aussi de ce qui est ajouté, modifié ou supprimé par rapport à la version précédente par l'utilisateur qui l'a soumis (cet utilisateur s'ajoutant aux autres sources qu'il indique dans son changeset). S'il faut continuer sur cette voie, il faudra automatiser et systématiser d'avantage dans les éditeurs le renseignement des changeset afin que ces sources puissent être facilement indiquées (par des simple cases à cocher, ou automatiquement si on utilise certaines couches visibles dans l'éditeur à l'endroit où l'objet était modifié dans sa géométrie, mais ce ne sera pas automatique pour les tags textuels dont la source n'a le plus souvent rien à voir avec celle des autres fonds de carte utilisés : les éditeurs devraient alors pouvoir inclure un petit onglet de navigation web, mémorisant les URLs ou domaines visitées, afin de permettre un copier-coller éventuel depuis cet onglet, si la source web est autorisée comme source libre pour ces éléments textuels, de même l'utilisateur devrait avoir dans son carnet perso de sources une liste de sources qu'il lui suffit d'activer d'un clic pour que cela figure dans les propriétés du changeset qu'il va soumettre). Chaque changeset contiendra donc une liste de sources (de même qu'il contient déjà le nom de l'utilisateur), uniquement celles concernées par la modification. Les autres sources des parties non modifiées ou des anciennes versions persistent dans la base dans les changesets associés aux versions dans lesquelles sont apparues les données. Cette liste de sources est facilement intérrogeable, mais si on veut faciliter leur affichage, on peut développer dans l'API un type de requête simple permettant de les avoir de façon exhautives pour toutes les données et attributs d'un objet qui sont encore visibles, simplement en groupant ces données visibles par changeset, en ordre antéchronologique où elles sont apparues, le serveur alors générant dans ses résultats une liste de versions pertinentes d'un objet, où celle-ci mentionne les sources du changeset associé). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Le 19/10/2012 21:56, Pierre-Alain Dorange a écrit : Pieren pier...@gmail.com wrote: Il n'y a pas d'engagement vis à vis de la dgfip d'avoir un tag source sur les objets eux même, je doute que la dgfip connaisse notre modèle de données, sache ce qu'est un tag, sache ce qu'est un changeset. Que l'info de source soit sur l'objet lui même ou sur le changeset c'est du pareil au même (pour moi), elle n'est pas visible dans la majorité des usages (cartes), il faut passer par un éditeur pour voir ce tag et l'éditeur permet de remonter l'historique pour savoir que l'objet provient du cadastre et de quel millésime il s'agit. Trouver les tags du changeset est plus difficile que de trouver ceux directement attachés à l'élément. Lorsqu'un objet a un historique, c'est encore plus difficile. Lorsque les données OSM sont redistribuées (export, planet), il est très facile de perdre les tags des changesets alors que supprimer le tag source attachés aux éléments nécessite une action volontaire. J'ai déjà fait une liste des avantages et inconvénients de chaque méthode, cf les archives. OK c'est moins précis (ça suit moins facilement les évolutions) mais ça présente un avantage certain (et qui répond a une des critiques qui est faites à nos imports cadastraux) : cela réduit drastiquement la taille des données, car quoiqu'on en dise le tag source sur chaque objet avec une chaine aussi longue est très lourde au niveau données... Il ne faut oublier que c'est aussi sur ce point (taille des données) que les imports cadastraux sont critiqués. Et moi même je suis pas très a l'aise ni satisfait que voit ce tag source attaché a tout les objets importés ad-vitam-eternam... Ca fait un signal données-source faible. Bonjour, Le problème de la répétition est un détail technique lié à l'implémentation du modèle de données. On peut très bien concevoir un schéma où chaque paire de clé/valeur n'est présent qu'une seule fois et possède une simple référence qui est attachée à tous les éléments concernés. Ce qui serait même malin, indépendamment des imports du Cadastre. Même la compression des fichiers OSM fait cela (je ne vais rentrer dans les détails des algo de compression par suppression des répétitions). Ce point n'est pas un problème. C'est juste un argument (bidon) de plus pour empêcher les imports. A+ -- Marc Sibert mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Bonjour, Je n'interviendrai pas sur le problème politique, car ils y a eu déjà assez de discussions, et je ne veux pas augmenter le bruit. Par contre, techniquement, si on commence à se dire qu'il faut améliorer l'outil JOSM, pourquoi ne pas trouver un moyen automatique (ou via les filtres, c'est déjà possible) de séparer en 2 calques un travail réalisé sous JOSM : * un calque avec le bâti - on l'enverra avec le compte dédié * un calque avec tous les autres objets - on l'enverra avec le compte classique. L'idée étant de se dire je veux pouvoir continuer à faire du multi-source sur mes éditions (bing, cadastre, terrain), et je sépare seulement avant l'upload. Bien sûr, il faut modifier aussi JOSM pour permettre de choisir l'utilisateur avant l'envoi, et pourquoi pas prévenir, genre Plus de 90% des objets à envoyer ont le tag source=Cadastre, pensez à utiliser votre compte cadastre ! Michael Le 18 octobre 2012 21:37, Christian Quest cqu...@openstreetmap.fr a écrit : Le 18 octobre 2012 17:35, Marc SIBERT m...@sibert.fr a écrit : +1 Tout ça n'a aucun sens, ce n'est que de la poudre aux yeux du DWG et ne protège en rien contre les problèmes de qualité ou le vandalisme. Comme de toute façon l'import du Cadastre n'est pas concerné par ces points. il ne s'agit que d'une perte de temps et le DWG ferait mieux de ce concentrer sur les vrais problèmes de qualité et de vandalisme. Ça me gave ce sujet ! Mais ce serait vraiment trop domage de laisser pisser (@sly : I'm back ! ) +beaucoup ! Ca me fait penser à des discussions interminables de règlements de compétitions sportives (parapente/delta) où certains (en gros les anglo-saxons dans leur version autant anglo que saxons) perdaient de vue l'utilité des règles. Des règles faites pour la sécurité qui mal appliquées ou appliquées bêtement, mécaniquement pouvaient aller à l'encontre de l'objectif initial. Il fallait pouvoir avoir un peu de recul pour le comprendre, mais visiblement la remise en cause des règles est quelque chose de culturel. -- 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] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Voire même: - un tri par JOSM avant envoi des données ayant un tag source=XXX du reste - un premier envoi avec le compte dédié qui va bien des nouvelles données identifiées par source=XXX en supprimant au passage le source=XXX sur les objets pour le mettre sur le changeset - un second envoi du reste sur le compte normal. Le 19 octobre 2012 09:28, kimaidou kimai...@gmail.com a écrit : Bonjour, Je n'interviendrai pas sur le problème politique, car ils y a eu déjà assez de discussions, et je ne veux pas augmenter le bruit. Par contre, techniquement, si on commence à se dire qu'il faut améliorer l'outil JOSM, pourquoi ne pas trouver un moyen automatique (ou via les filtres, c'est déjà possible) de séparer en 2 calques un travail réalisé sous JOSM : * un calque avec le bâti - on l'enverra avec le compte dédié * un calque avec tous les autres objets - on l'enverra avec le compte classique. L'idée étant de se dire je veux pouvoir continuer à faire du multi-source sur mes éditions (bing, cadastre, terrain), et je sépare seulement avant l'upload. Bien sûr, il faut modifier aussi JOSM pour permettre de choisir l'utilisateur avant l'envoi, et pourquoi pas prévenir, genre Plus de 90% des objets à envoyer ont le tag source=Cadastre, pensez à utiliser votre compte cadastre ! Michael Le 18 octobre 2012 21:37, Christian Quest cqu...@openstreetmap.fr a écrit : Le 18 octobre 2012 17:35, Marc SIBERT m...@sibert.fr a écrit : +1 Tout ça n'a aucun sens, ce n'est que de la poudre aux yeux du DWG et ne protège en rien contre les problèmes de qualité ou le vandalisme. Comme de toute façon l'import du Cadastre n'est pas concerné par ces points. il ne s'agit que d'une perte de temps et le DWG ferait mieux de ce concentrer sur les vrais problèmes de qualité et de vandalisme. Ça me gave ce sujet ! Mais ce serait vraiment trop domage de laisser pisser (@sly : I'm back ! ) +beaucoup ! Ca me fait penser à des discussions interminables de règlements de compétitions sportives (parapente/delta) où certains (en gros les anglo-saxons dans leur version autant anglo que saxons) perdaient de vue l'utilité des règles. Des règles faites pour la sécurité qui mal appliquées ou appliquées bêtement, mécaniquement pouvaient aller à l'encontre de l'objectif initial. Il fallait pouvoir avoir un peu de recul pour le comprendre, mais visiblement la remise en cause des règles est quelque chose de culturel. -- 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 -- 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] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Ok pour ta proposition Christian, sauf la suppression du tag source des objets OSM pour le reporter sur le tag du changeset. Nous nous sommes engagés à conserver la source du cadastre sur les objets, et cela risque de coincer. Mais j'ai peut-être mal compris ta proposition Mais sinon, montrer que la communauté français sait être force de proposition aussi dans le domaine technique fera avancer le débat. On pourra dire à nos interlocuteurs : que pensez vous de notre solution ? Cela ne résout pas le problème de gouvernance, qui mettra plus de temps (le temps long de la négociation), mais cela nous permettra d'avancer dans le bon sens. Michael Le 19 octobre 2012 09:39, Christian Quest cqu...@openstreetmap.fr a écrit : Voire même: - un tri par JOSM avant envoi des données ayant un tag source=XXX du reste - un premier envoi avec le compte dédié qui va bien des nouvelles données identifiées par source=XXX en supprimant au passage le source=XXX sur les objets pour le mettre sur le changeset - un second envoi du reste sur le compte normal. Le 19 octobre 2012 09:28, kimaidou kimai...@gmail.com a écrit : Bonjour, Je n'interviendrai pas sur le problème politique, car ils y a eu déjà assez de discussions, et je ne veux pas augmenter le bruit. Par contre, techniquement, si on commence à se dire qu'il faut améliorer l'outil JOSM, pourquoi ne pas trouver un moyen automatique (ou via les filtres, c'est déjà possible) de séparer en 2 calques un travail réalisé sous JOSM : * un calque avec le bâti - on l'enverra avec le compte dédié * un calque avec tous les autres objets - on l'enverra avec le compte classique. L'idée étant de se dire je veux pouvoir continuer à faire du multi-source sur mes éditions (bing, cadastre, terrain), et je sépare seulement avant l'upload. Bien sûr, il faut modifier aussi JOSM pour permettre de choisir l'utilisateur avant l'envoi, et pourquoi pas prévenir, genre Plus de 90% des objets à envoyer ont le tag source=Cadastre, pensez à utiliser votre compte cadastre ! Michael Le 18 octobre 2012 21:37, Christian Quest cqu...@openstreetmap.fr a écrit : Le 18 octobre 2012 17:35, Marc SIBERT m...@sibert.fr a écrit : +1 Tout ça n'a aucun sens, ce n'est que de la poudre aux yeux du DWG et ne protège en rien contre les problèmes de qualité ou le vandalisme. Comme de toute façon l'import du Cadastre n'est pas concerné par ces points. il ne s'agit que d'une perte de temps et le DWG ferait mieux de ce concentrer sur les vrais problèmes de qualité et de vandalisme. Ça me gave ce sujet ! Mais ce serait vraiment trop domage de laisser pisser (@sly : I'm back ! ) +beaucoup ! Ca me fait penser à des discussions interminables de règlements de compétitions sportives (parapente/delta) où certains (en gros les anglo-saxons dans leur version autant anglo que saxons) perdaient de vue l'utilité des règles. Des règles faites pour la sécurité qui mal appliquées ou appliquées bêtement, mécaniquement pouvaient aller à l'encontre de l'objectif initial. Il fallait pouvoir avoir un peu de recul pour le comprendre, mais visiblement la remise en cause des règles est quelque chose de culturel. -- 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 -- 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] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
De : Christian Quest cqu...@openstreetmap.fr Voire même: - un tri par JOSM avant envoi des données ayant un tag source=XXX du reste - un premier envoi avec le compte dédié qui va bien des nouvelles données identifiées par source=XXX en supprimant au passage le source=XXX sur les objets pour le mettre sur le changeset - un second envoi du reste sur le compte normal. Cette solution la serait vraiment sympa. Au moins pas de risque d oublis et ca peut etre etendu a d autres sources que le Cadastre. Julien___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
On 19/10/2012 09:39, Christian Quest wrote: Le 19 octobre 2012 09:28, kimaidou kimai...@gmail.com a écrit : Par contre, techniquement, si on commence à se dire qu'il faut améliorer l'outil JOSM, pourquoi ne pas trouver un moyen automatique (ou via les filtres, c'est déjà possible) de séparer en 2 calques un travail réalisé sous JOSM : * un calque avec le bâti - on l'enverra avec le compte dédié * un calque avec tous les autres objets - on l'enverra avec le compte classique. L'idée étant de se dire je veux pouvoir continuer à faire du multi-source sur mes éditions (bing, cadastre, terrain), et je sépare seulement avant l'upload. Bien sûr, il faut modifier aussi JOSM pour permettre de choisir l'utilisateur avant l'envoi, et pourquoi pas prévenir, genre Plus de 90% des objets à envoyer ont le tag source=Cadastre, pensez à utiliser votre compte cadastre ! Voire même: - un tri par JOSM avant envoi des données ayant un tag source=XXX du reste - un premier envoi avec le compte dédié qui va bien des nouvelles données identifiées par source=XXX en supprimant au passage le source=XXX sur les objets pour le mettre sur le changeset - un second envoi du reste sur le compte normal. J'ai un gros doute sur la pertinence d'une modification structurelle d'une fonction importante d'un outil majeur pour traiter le cas particulier d'une source de données locale. Mon expérience est que lorsqu'on se lance dans de telles aventures pour traiter un cas particulier, c'est généralement qu'il y a un problème ailleurs. Dans le cas présent, il me semble que les problèmes principaux sont d'ordre politiques. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
D'accord avec le problème politique. Néanmoins, chaque fois que la communauté locale parle politique et gouvernance sur la liste internationale, on lui répond compte séparé. La solution de Christian aurait l'avantage d'éliminer cette fixette sur le double compte, et partant, de pouvoir ensuite recentrer le débat sur la gouvernance. Attention toutefois, d'un point de vue solution technique, ça ne sera probablement pas si simple. Quid par exemple s'il y a un noeud commun à deux ways dont l'une est tagguée cadastre et l'autre pas ? = cela nécessitera surement un download entre les deux uploads, afin de récupérer l'id de ce noeud. Jean-Marc Liotier j...@liotier.org a écrit : On 19/10/2012 09:39, Christian Quest wrote: Le 19 octobre 2012 09:28, kimaidou kimai...@gmail.com a écrit : Par contre, techniquement, si on commence à se dire qu'il faut améliorer l'outil JOSM, pourquoi ne pas trouver un moyen automatique (ou via les filtres, c'est déjà possible) de séparer en 2 calques un travail réalisé sous JOSM : * un calque avec le bâti - on l'enverra avec le compte dédié * un calque avec tous les autres objets - on l'enverra avec le compte classique. L'idée étant de se dire je veux pouvoir continuer à faire du multi-source sur mes éditions (bing, cadastre, terrain), et je sépare seulement avant l'upload. Bien sûr, il faut modifier aussi JOSM pour permettre de choisir l'utilisateur avant l'envoi, et pourquoi pas prévenir, genre Plus de 90% des objets à envoyer ont le tag source=Cadastre, pensez à utiliser votre compte cadastre ! Voire même: - un tri par JOSM avant envoi des données ayant un tag source=XXX du reste - un premier envoi avec le compte dédié qui va bien des nouvelles données identifiées par source=XXX en supprimant au passage le source=XXX sur les objets pour le mettre sur le changeset - un second envoi du reste sur le compte normal. J'ai un gros doute sur la pertinence d'une modification structurelle d'une fonction importante d'un outil majeur pour traiter le cas particulier d'une source de données locale. Mon expérience est que lorsqu'on se lance dans de telles aventures pour traiter un cas particulier, c'est généralement qu'il y a un problème ailleurs. Dans le cas présent, il me semble que les problèmes principaux sont d'ordre politiques. ___ 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] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Le 19 octobre 2012 09:48, kimaidou kimai...@gmail.com a écrit : Ok pour ta proposition Christian, sauf la suppression du tag source des objets OSM pour le reporter sur le tag du changeset. Nous nous sommes engagés à conserver la source du cadastre sur les objets, et cela risque de coincer. Mais j'ai peut-être mal compris ta proposition Il n'y a pas d'engagement vis à vis de la dgfip d'avoir un tag source sur les objets eux même, je doute que la dgfip connaisse notre modèle de données, sache ce qu'est un tag, sache ce qu'est un changeset. Que l'info de source soit sur l'objet lui même ou sur le changeset c'est du pareil au même (pour moi), elle n'est pas visible dans la majorité des usages (cartes), il faut passer par un éditeur pour voir ce tag et l'éditeur permet de remonter l'historique pour savoir que l'objet provient du cadastre et de quel millésime il s'agit. Mais sinon, montrer que la communauté français sait être force de proposition aussi dans le domaine technique fera avancer le débat. On pourra dire à nos interlocuteurs : que pensez vous de notre solution ? Cela ne résout pas le problème de gouvernance, qui mettra plus de temps (le temps long de la négociation), mais cela nous permettra d'avancer dans le bon sens. Cette approche technique n'est qu'une facilité pour gérer automatiquement une règle illégitime. Elle a aussi l'avantage de pouvoir gérer bien plus intelligemment un réel problème en séparant dans des changesets différents des données de source différente (que l'on utilise un ou plusieurs compte). La règle reste illégitime pour moi, et les questions sur la gouvernance restent ouvertes. Le 19 octobre 2012 10:06, Jean-Marc Liotier j...@liotier.org a écrit : J'ai un gros doute sur la pertinence d'une modification structurelle d'une fonction importante d'un outil majeur pour traiter le cas particulier d'une source de données locale. Mon expérience est que lorsqu'on se lance dans de telles aventures pour traiter un cas particulier, c'est généralement qu'il y a un problème ailleurs. Dans le cas présent, il me semble que les problèmes principaux sont d'ordre politiques. Justement, je vois cette modification comme un outil bien plus global et pas uniquement adapté au cas particulier du double compte et du cadastre. Il y a une réelle amélioration à apporte à la gestion du traçage des sources, traçage qui sert aussi à évaluer la qualité d'un objet (quelle source, quelle date pour la source, etc). Le 19 octobre 2012 10:31, khris78 ch...@gallioz.fr a écrit : Attention toutefois, d'un point de vue solution technique, ça ne sera probablement pas si simple. Quid par exemple s'il y a un noeud commun à deux ways dont l'une est tagguée cadastre et l'autre pas ? = cela nécessitera surement un download entre les deux uploads, afin de récupérer l'id de ce noeud. Seuls les objets NOUVEAUX (id=0) ayant un tag source=* seraient ainsi traités. Si lors de l'intégration, on fusionne des objets avec des objets pré-existants, ceux-ci gardent l'id de l'objet pré-existant. Il y aura bien quelques cas à la marge, mais globalement le principe de traçabilité de l'origine des données fonctionnera. J'ai déjà fait des essais manuels à coup de chercher et envoyer la sélection, ça marche. Il faut envoyer les nouveaux objets avec sourge=* en premier, puis le reste. Il faudrait juste l'automatiser et le rendre transparent pour le contributeur, mais je suis incapable de coder des trucs dans JOSM (java pas bien du tout). -- 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] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
2012/10/19 Christian Quest cqu...@openstreetmap.fr: Il n'y a pas d'engagement vis à vis de la dgfip d'avoir un tag source sur les objets eux même, je doute que la dgfip connaisse notre modèle de données, sache ce qu'est un tag, sache ce qu'est un changeset. Que l'info de source soit sur l'objet lui même ou sur le changeset c'est du pareil au même (pour moi), elle n'est pas visible dans la majorité des usages (cartes), il faut passer par un éditeur pour voir ce tag et l'éditeur permet de remonter l'historique pour savoir que l'objet provient du cadastre et de quel millésime il s'agit. Trouver les tags du changeset est plus difficile que de trouver ceux directement attachés à l'élément. Lorsqu'un objet a un historique, c'est encore plus difficile. Lorsque les données OSM sont redistribuées (export, planet), il est très facile de perdre les tags des changesets alors que supprimer le tag source attachés aux éléments nécessite une action volontaire. J'ai déjà fait une liste des avantages et inconvénients de chaque méthode, cf les archives. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
-Message d'origine- De : Pieren [mailto:pier...@gmail.com] Envoyé : vendredi 19 octobre 2012 14:44 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration) 2012/10/19 Christian Quest cqu...@openstreetmap.fr: Il n'y a pas d'engagement vis à vis de la dgfip d'avoir un tag source sur les objets eux même, je doute que la dgfip connaisse notre modèle de données, sache ce qu'est un tag, sache ce qu'est un changeset. Que l'info de source soit sur l'objet lui même ou sur le changeset c'est du pareil au même (pour moi), elle n'est pas visible dans la majorité des usages (cartes), il faut passer par un éditeur pour voir ce tag et l'éditeur permet de remonter l'historique pour savoir que l'objet provient du cadastre et de quel millésime il s'agit. Trouver les tags du changeset est plus difficile que de trouver ceux directement attachés à l'élément. Lorsqu'un objet a un historique, c'est encore plus difficile. Lorsque les données OSM sont redistribuées (export, planet), il est très facile de perdre les tags des changesets alors que supprimer le tag source attachés aux éléments nécessite une action volontaire. J'ai déjà fait une liste des avantages et inconvénients de chaque méthode, cf les archives. Pieren +10 Dans le produit composite que forme la base OSM par rapport au plan cadastral, il est indispensable de maintenir la source au niveau données et pas des changesets. Tant que l'API ne transfèrera pas automatiquement la mention de source d'un changeset sur les objets concernés, il serait hasardeux d'envisager un tel changement de méthode. Je crois qu'on a de la marge jusqu'à ce que cela soit réalisé. Pour les cartes, qui sont des œuvres intellectuelles distinctes de la base, ce sont les mentions de la licence ODbl OSM qui s'appliquent. Si c'est la question taille de ces mentions de source dans la base qui posent problème, je suis prêt à participer à l'appel de fonds nécessaire pour l'acquisition de serveurs supplémentaires. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Je te l'accorde, aujourd'hui ce n'est pas parfait et chaque méthode a les avantages et inconvénients que tu avais rémusé (cf archives). Je voulais juste dire que c'est une étape de plus mais que l'info est bien accessible dès qu'on passe au niveau des objets et que des améliorations techniques sont possibles. Par contre, je ne comprend comment il serait possible de perdre les tags sur les changeset, ceux-ci ne sont pas modifiables une fois le changeset fermé à ce que je sache. Insérer dans les dump et les diffs les infos/tags sur les changeset (par les changeset en eux même) serait un sacré bonus. C'est aussi de ce côté qu'il faut améliorer les choses si on veut réduire la répétition inutile des tags source sur les objets issus d'un import. -- 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] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Comment a-t-on fait pour changer de licence ? Il a fallu de toute façon regarder les historiques des objets pour regarder de quel changeset venait chaque modification ou ajout, qui l'avait faite et quelles conditions de licence lui était applicable. Cela n'a pas demandé un temps de traitement si considérable que ça aux serveurs, alors qu'il a fallu traiter la totalité des données du monde entier. Là on parle de pourvoir faire un revert éventuel sur quelques éléments qui ne devraient pas être dans la base. Même si cela concerne un gros import de quelques dizaines milliers de points et des milliers de petits objets, les serveurs ont déjà prouvé la capacité de le faire lors de la migration de licence. Les bots concernés écrits pour ce changement ont pu faire les modifs nécessaires, ils sauront encore lire les tags des changeset pour retrouver les sources (facilement) alors que les tags des objets eux-mêmes nécessitent de fouiller des version successives de tout un tas d'objets non concernés dans la zone par la première source de données. Les tags des changesets ont effecitmvement l'avantage d'être inamovibles et de nécessiter très peu de requêtes pour les obtenir (pour un seul objet cela ne change rien mais là on parle de milliers d'objets qui se partagent un même changeset problématique : il y a beaucoup moins de changesets à analyser que d'objets, dès qu'on a récupéré un changeset trouvé dans l'hstorique d'un objet, on a ses caractéristiques déjà chargées aussi pour tous les autres historiques d'objets. En terme d'efficacité et aussi d'exhausitivé, c'est bien plus précis et plus rapide de regarder les attributs des changesets que le détail de chacun des objets dans une zone (en risquant d'en oublier des tas d'autres dans la même zone. Bref je ne suis pas d'accord avec toi en terme de difficulté, même si dans le cas des éditeurs ces données sont moins facilement accessibles immédiatement. Mais le but n'est pas ici de faciliter les éditions, mais de savoir qui a fait quoi et à qui appartient les données existantes et d'où elles viennent à l'origine (ce que n'indique en fait pas, ou très mal, les tags des objets eux-mêmes qui ont pu être modifiés souvent depuis leur import, la source effective ayant pu changer et celle mentionnée n'étant pus adéquate dès l'instant qu(on a augmenté les données à partir d'autres sources ou de connaissances personnelles, ou divisé les chemins et surfaces, et fusionné des noeuds proches mais de source différentes). Le 19 octobre 2012 14:43, Pieren pier...@gmail.com a écrit : 2012/10/19 Christian Quest cqu...@openstreetmap.fr: Il n'y a pas d'engagement vis à vis de la dgfip d'avoir un tag source sur les objets eux même, je doute que la dgfip connaisse notre modèle de données, sache ce qu'est un tag, sache ce qu'est un changeset. Que l'info de source soit sur l'objet lui même ou sur le changeset c'est du pareil au même (pour moi), elle n'est pas visible dans la majorité des usages (cartes), il faut passer par un éditeur pour voir ce tag et l'éditeur permet de remonter l'historique pour savoir que l'objet provient du cadastre et de quel millésime il s'agit. Trouver les tags du changeset est plus difficile que de trouver ceux directement attachés à l'élément. Lorsqu'un objet a un historique, c'est encore plus difficile. Lorsque les données OSM sont redistribuées (export, planet), il est très facile de perdre les tags des changesets alors que supprimer le tag source attachés aux éléments nécessite une action volontaire. J'ai déjà fait une liste des avantages et inconvénients de chaque méthode, cf les archives. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Pieren pier...@gmail.com wrote: Il n'y a pas d'engagement vis à vis de la dgfip d'avoir un tag source sur les objets eux même, je doute que la dgfip connaisse notre modèle de données, sache ce qu'est un tag, sache ce qu'est un changeset. Que l'info de source soit sur l'objet lui même ou sur le changeset c'est du pareil au même (pour moi), elle n'est pas visible dans la majorité des usages (cartes), il faut passer par un éditeur pour voir ce tag et l'éditeur permet de remonter l'historique pour savoir que l'objet provient du cadastre et de quel millésime il s'agit. Trouver les tags du changeset est plus difficile que de trouver ceux directement attachés à l'élément. Lorsqu'un objet a un historique, c'est encore plus difficile. Lorsque les données OSM sont redistribuées (export, planet), il est très facile de perdre les tags des changesets alors que supprimer le tag source attachés aux éléments nécessite une action volontaire. J'ai déjà fait une liste des avantages et inconvénients de chaque méthode, cf les archives. OK c'est moins précis (ça suit moins facilement les évolutions) mais ça présente un avantage certain (et qui répond a une des critiques qui est faites à nos imports cadastraux) : cela réduit drastiquement la taille des données, car quoiqu'on en dise le tag source sur chaque objet avec une chaine aussi longue est très lourde au niveau données... Il ne faut oublier que c'est aussi sur ce point (taille des données) que les imports cadastraux sont critiqués. Et moi même je suis pas très a l'aise ni satisfait que voit ce tag source attaché a tout les objets importés ad-vitam-eternam... Ca fait un signal données-source faible. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Le 18/10/2012 17:04, THEVENON Julien a écrit : Concernant l usage de comptes differents Frederik a bien precise que c est uniquement une histoire de quantite de donnee pas de qualites: 100 building d un coup pas de probleme, 1 buildings d un coup = utilisation d un compte separe Frederik propose de resoudre 2 points techniques pour faciliter l usage de plusieurs comptes: _ patcher JOSM pour choisir une identite au moment de l upload _ avoir la possibilite de creer plusieurs comptes avec le meme email Il demande si c est une perte de temps de faire cela ou si cela peut changer l attitude anti-compte-separes pour les gros uploads Julien Ça ne répond pas aux questions posées, ça ne rend pas plus fine leur compréhension de ce qu'est l'intégration du bâti, ça ne rend pas la règle plus intelligente, ça ne change rien à la politique du DWG, ça ne fait pas avancer l'intégration de Christian et Sly dans le DWG, mais si ça le rassure... Le fait que ça l'occupe un bout de temps, ce ne sera peut-être pas une perte de temps. Donc ça ne mange pas de pain. Il est probable qu'on oubliera parfois de changer d'identité, dans un sens comme dans l'autre, déjà que j'oublie souvent de mettre un bon descriptif dans le changeset... Alors on présentera nos excuses. J'ai déjà deux comptes sur OSM, dont un dont j'ai oublié le mot de masse et que je n'utilise plus (l'ai-je utilisé seulement une fois ?). Ça m'en fera trois. Mais quand on aime, on ne compte pas. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Salut, pour ma part si il y a une possibilité de multi-compte avec la possibilité que JOSM fasse un filtre à l'envoi pour que le bâti (sur tag cadastre) parte sous un compte, et le reste des donnée ssous un autre, alors je dis pourquoi pas ! mais ça ne règle à priori pas la question de l'utilité réelle d'un double compte (*le nombre d'importeurs) pour l'import par petite partie du cadastre ... Sylvain 2012/10/18 THEVENON Julien julien_theve...@yahoo.fr Concernant l usage de comptes differents Frederik a bien precise que c est uniquement une histoire de quantite de donnee pas de qualites: 100 building d un coup pas de probleme, 1 buildings d un coup = utilisation d un compte separe Frederik propose de resoudre 2 points techniques pour faciliter l usage de plusieurs comptes: _ patcher JOSM pour choisir une identite au moment de l upload _ avoir la possibilite de creer plusieurs comptes avec le meme email Il demande si c est une perte de temps de faire cela ou si cela peut changer l attitude anti-compte-separes pour les gros uploads Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Le 18 octobre 2012 17:17, Vincent Pottier vpott...@gmail.com a écrit : Le 18/10/2012 17:04, THEVENON Julien a écrit : Concernant l usage de comptes differents Frederik a bien precise que c est uniquement une histoire de quantite de donnee pas de qualites: 100 building d un coup pas de probleme, 1 buildings d un coup = utilisation d un compte separe Frederik propose de resoudre 2 points techniques pour faciliter l usage de plusieurs comptes: _ patcher JOSM pour choisir une identite au moment de l upload _ avoir la possibilite de creer plusieurs comptes avec le meme email Il demande si c est une perte de temps de faire cela ou si cela peut changer l attitude anti-compte-separes pour les gros uploads Julien Ça ne répond pas aux questions posées, ça ne rend pas plus fine leur compréhension de ce qu'est l'intégration du bâti, ça ne rend pas la règle plus intelligente, ça ne change rien à la politique du DWG, ça ne fait pas avancer l'intégration de Christian et Sly dans le DWG, mais si ça le rassure... Le fait que ça l'occupe un bout de temps, ce ne sera peut-être pas une perte de temps. Donc ça ne mange pas de pain. Il est probable qu'on oubliera parfois de changer d'identité, dans un sens comme dans l'autre, déjà que j'oublie souvent de mettre un bon descriptif dans le changeset... Alors on présentera nos excuses. J'ai déjà deux comptes sur OSM, dont un dont j'ai oublié le mot de masse et que je n'utilise plus (l'ai-je utilisé seulement une fois ?). Ça m'en fera trois. Mais quand on aime, on ne compte pas. -- FrViPofm +1 Tout ça n'a aucun sens, ce n'est que de la poudre aux yeux du DWG et ne protège en rien contre les problèmes de qualité ou le vandalisme. Comme de toute façon l'import du Cadastre n'est pas concerné par ces points. il ne s'agit que d'une perte de temps et le DWG ferait mieux de ce concentrer sur les vrais problèmes de qualité et de vandalisme. Ça me gave ce sujet ! Mais ce serait vraiment trop domage de laisser pisser (@sly : I'm back ! ) A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Le Thu, Oct 18, 2012 at 04:04:57PM +0100, THEVENON Julien [julien_theve...@yahoo.fr] a écrit: Concernant l usage de comptes differents Frederik a bien precise que c est uniquement une histoire de quantite de donnee pas de qualites: 100 building d un coup pas de probleme, 1 buildings d un coup = utilisation d un compte separe Frederik propose de resoudre 2 points techniques pour faciliter l usage de plusieurs comptes: _ patcher JOSM pour choisir une identite au moment de l upload _ avoir la possibilite de creer plusieurs comptes avec le meme email Il demande si c est une perte de temps de faire cela ou si cela peut changer l attitude anti-compte-separes pour les gros uploads Ce ne serait pas une perte de temps, parceque c'est utile en soi. (et forcément nécesssaire pour pouvoir suivre la guideline du compte séparé) Mais sur le sujet du cadastre, je crains que tant que le DWG n'assimilera pas le fait que la communauté fr est plus à même de gérer les problèmes d'import, ça ne changera pas grand chose, de suivre la guideline ou pas. -- Dominique Rousseau d...@lee-loo.net - 06 82 43 12 27 A l'instant où l'esclave décide qu'il ne sera plus esclave, ses chaînes tombent. -- Mahatma Gandhi ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
On jeudi 18 octobre 2012, THEVENON Julien wrote: Frederik propose de resoudre 2 points techniques pour faciliter l usage de plusieurs comptes: _ patcher JOSM pour choisir une identite au moment de l upload _ avoir la possibilite de creer plusieurs comptes avec le meme email Il demande si c est une perte de temps de faire cela ou si cela peut changer l attitude anti-compte-separes pour les gros uploads C'est clairement en pas en avant, mais le risque est malgré tout d'oublier de changer de compte et donc de mélanger quand même différents type de contribution. Si on en est à se dire que l'on peut modifier JOSM autant que ça puisse fournir un outil utiles à d'autres cas, limiter encore plus les erreurs humaines, et pour ça, ma proposition est la suivante : Sachant que les seuls intérêts annoncés du 2ème comptes (que j'ai enfin fini par comprendre, peut-être...) sont : - pouvoir annuler facilement le(s) changeset qui ne concerne que l'import de bâtiment uniquement si celui-ci part en vrille, ou s'il faut un jour retirer ça pour X raisons Et là, je pense que la solution de richard de mettre des tags dans le changeset est la meilleure solution, car c'est bien plus simple que de se créer un compte par source externe. Le contributeur est bien toujours le même, c'est ce qu'il fait qui change ! En en plus ça permettrait d'aider à coller plus facilement un source au changeset. http://lists.openstreetmap.org/pipermail/talk/2012-October/064856.html En français : - réaliser un patch pour JOSM lui permettant, lorsque l'on ouvre une source externe au format .osm de venir lire des champs supplémentaires indiquants la liste des tags et leur valeur à ajouter au prochain changeset Coté cadastre.openstreetmap.fr on pourrait alors ajouter ces champs, qui seraient alors automatiquement mis sur le changeset. Après, on peut rêver un peu, mais une modif d'ordre plus générale pour que quelle que soit la source d'acquisition (bing/cadastre à la main/fichier .osm externe/gpx converti/...) toutes ces manières d'acquérir des données puisse utiliser le tuyau du : Tiens cet utilisateur a chargé un fond de carte bing et commence à cliquer dessus, je demande l'ajout automatique du tag source:aerial=bing 2012 pour le prochain changeset qu'il va créer -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
- Mail original - De: sly (sylvain letuffe) li...@letuffe.org À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Jeudi 18 Octobre 2012 18:04:11 Objet: Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration) Sachant que les seuls intérêts annoncés du 2ème comptes (que j'ai enfin fini par comprendre, peut-être...) sont : - pouvoir annuler facilement le(s) changeset qui ne concerne que l'import de bâtiment uniquement si celui-ci part en vrille, ou s'il faut un jour retirer ça pour X raisons C'est comme ça que je le comprends aussi : augmenter la traçabilité, faciliter les opérations de revert en cas de pb. Et là, je pense que la solution de richard de mettre des tags dans le changeset est la meilleure solution, car c'est bien plus simple que de se créer un compte par source externe. Le contributeur est bien toujours le même, c'est ce qu'il fait qui change ! En en plus ça permettrait d'aider à coller plus facilement un source au changeset. http://lists.openstreetmap.org/pipermail/talk/2012-October/064856.html +1 Les tags dans le changeset sont le meilleur compromis possible, dommage que cette proposition n'est pas été accueillie avec plus d'enthousiasme. Mieux suivre les modifications, les documenter, faciliter les revert, c'est exactement pour ça que les changeset ont été crée : http://wiki.openstreetmap.org/wiki/API_v0.6#Changesets_2 Cela permettrait de revenir aux définitions de base : l'utilisateur c'est celui qui fait (rôle), le changeset c'est ce qui a été fait (tache). Francisco ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Le 18 octobre 2012 17:35, Marc SIBERT m...@sibert.fr a écrit : +1 Tout ça n'a aucun sens, ce n'est que de la poudre aux yeux du DWG et ne protège en rien contre les problèmes de qualité ou le vandalisme. Comme de toute façon l'import du Cadastre n'est pas concerné par ces points. il ne s'agit que d'une perte de temps et le DWG ferait mieux de ce concentrer sur les vrais problèmes de qualité et de vandalisme. Ça me gave ce sujet ! Mais ce serait vraiment trop domage de laisser pisser (@sly : I'm back ! ) +beaucoup ! Ca me fait penser à des discussions interminables de règlements de compétitions sportives (parapente/delta) où certains (en gros les anglo-saxons dans leur version autant anglo que saxons) perdaient de vue l'utilité des règles. Des règles faites pour la sécurité qui mal appliquées ou appliquées bêtement, mécaniquement pouvaient aller à l'encontre de l'objectif initial. Il fallait pouvoir avoir un peu de recul pour le comprendre, mais visiblement la remise en cause des règles est quelque chose de culturel. -- 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] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)
Le 18 octobre 2012 21:37, Christian Quest cqu...@openstreetmap.fr a écrit : Ca me fait penser à des discussions interminables de règlements de compétitions sportives (parapente/delta) où certains (en gros les anglo-saxons dans leur version autant anglo que saxons) perdaient de vue l'utilité des règles. Les Français sont spécialistes pour contester en permanence les règles, mais surtout pour en inventer de nouvelles qui s'ajoutent aux premières en les contredisant. Les Anglo-saxons sont spécialistes pour créer des règles soit totalement inamovibles (le moindre changement dans les droits ou obligations est vu aussitôt comme une révolution), soit pour justement ne PAS en définir là où elles seraient souhaitables (à la place ils utilisent le système judiciaire et la Common Law, en principe pragmatique, mais qui a le défaut de permettre à celui qui y fait appel d'obtenir des droits ayant la même force légale qu'une loi mais sans même avoir jamais négocier avec ceux qui en disposaient et qui n'ont même pas été contactés pour savoir si ces droits allaient les abuser ; pour se défendre, c'est toujours aux abusés de payer très cher et d'aller en justice contester la décision prise en leur absence). Des règles faites pour la sécurité qui mal appliquées ou appliquées bêtement, mécaniquement pouvaient aller à l'encontre de l'objectif initial. Il fallait pouvoir avoir un peu de recul pour le comprendre, mais visiblement la remise en cause des règles est quelque chose de culturel. Deux cultures en apparence différentes, mais paradoxalement aux mêmes effets, qui laissent peu de place à la négociation réelle. Dans les deux cas, des règles mal définies, ou mal expliquées, mal appliquées. Une autre culture existe en Asie où les règles sont essentielles et bien suivies, par respect de l'ordre pour éviter les débats. D'autres cultures plus pragmatiques et plus consensuelles (selon les points de vue) existent aussi : - la culture germano-nordique par exemple, qui aime aussi l'ordre mais fait appel à des négociations où chacun accepte facilement les concessions, ce qui permet de faire évoluer les règles assez rapidement. - la culture africaine traditionnelle (aussi polynésienne) qui ne connait que peu les règles, mais fait appel à des réunions publiques et collégiales fréquentes pour la moindre prise de décision, mais dans des pourparlers interminables. - la culture arabo-musulmane qui connait les élites décidant de tout pour tout le monde (mais souvent incapables de s'accorder entre elles). - la culture russo-orthodoxe (trop souvent imitée dans les dictatures), qui respecte les pouvoirs des décideurs les plus puissants et tend vers l'immobilisme forcené ; du coup aucune règle, c'est le décideur qui peut changer d'avis quand cela lui plait et selon ses intérêts (pas très compatible avec un projet communautaire, car la prise de décision est totalement opaque) C'est un peu schématique, mais entre tout ça un fonctionnement communautaire doit pouvoir faire un mix acceptable. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
