Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)

2012-10-23 Par sujet Vincent Privat 
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)  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)

2012-10-23 Par sujet sly (sylvain letuffe) 
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)

2012-10-23 Par sujet Pieren 
2012/10/23 Philippe Verdy :
> 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)

2012-10-22 Par sujet Philippe Verdy 
Le 22 octobre 2012 13:20, sly (sylvain letuffe)  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)

2012-10-22 Par sujet Vincent Privat 
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)  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)

2012-10-22 Par sujet sly (sylvain letuffe) 
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)

2012-10-22 Par sujet Pieren 
2012/10/22 sly (sylvain letuffe) :

> 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)

2012-10-22 Par sujet sly (sylvain letuffe) 
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 Par sujet Pieren 
2012/10/22 sly (sylvain letuffe) :

> 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)

2012-10-22 Par sujet sly (sylvain letuffe) 
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-20 Par sujet Marc Sibert 

Le 19/10/2012 21:56, Pierre-Alain Dorange a écrit :

Pieren  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)

2012-10-19 Par sujet Pierre-Alain Dorange 
Pieren  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 : 


___
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 Par sujet Philippe Verdy 
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  a écrit :
> 2012/10/19 Christian Quest :
>> 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)

2012-10-19 Par sujet Christian Quest 
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)

2012-10-19 Par sujet HELFER Denis 


> -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 :
> > 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)

2012-10-19 Par sujet Pieren 
2012/10/19 Christian Quest :
> 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)

2012-10-19 Par sujet Christian Quest 
Le 19 octobre 2012 09:48, kimaidou  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  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  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 Par sujet khris78 
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  a écrit :

>On 19/10/2012 09:39, Christian Quest wrote:
>> Le 19 octobre 2012 09:28, kimaidou  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)

2012-10-19 Par sujet Jean-Marc Liotier 

On 19/10/2012 09:39, Christian Quest wrote:

Le 19 octobre 2012 09:28, kimaidou  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)

2012-10-19 Par sujet THEVENON Julien 
> De : Christian Quest 

> 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)

2012-10-19 Par sujet kimaidou 
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  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  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  a
> écrit
> > :
> >>
> >> Le 18 octobre 2012 17:35, Marc SIBERT  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)

2012-10-19 Par sujet Christian Quest 
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  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  a écrit
> :
>>
>> Le 18 octobre 2012 17:35, Marc SIBERT  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)

2012-10-19 Par sujet kimaidou 
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  a écrit
:

> Le 18 octobre 2012 17:35, Marc SIBERT  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)

2012-10-18 Par sujet Philippe Verdy 
Le 18 octobre 2012 21:37, Christian Quest  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

Re: [OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)

2012-10-18 Par sujet Christian Quest 
Le 18 octobre 2012 17:35, Marc SIBERT  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)

2012-10-18 Par sujet f . dos . santos 


- Mail original -
De: "sly (sylvain letuffe)" 
À: "Discussions sur OSM en français" 
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)

2012-10-18 Par sujet sly (sylvain letuffe) 
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)

2012-10-18 Par sujet Dominique Rousseau 
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)

2012-10-18 Par sujet Marc SIBERT 
Le 18 octobre 2012 17:17, Vincent Pottier  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)

2012-10-18 Par sujet Sylvain Maillard 
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 

> 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)

2012-10-18 Par sujet Vincent Pottier 

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

[OSM-talk-fr] Proposition de Frederik etait [OSM-talk] Continued aggression against French contributors (cadastre integration)

2012-10-18 Par sujet THEVENON Julien 
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




>
> De : Frederik Ramm 
>À : Pieren  
>Cc : t...@openstreetmap.org 
>Envoyé le : Jeudi 18 octobre 2012 16h31
>Objet : Re: [OSM-talk] [OSM-talk-fr] Continued aggression against French 
>contributors (cadastre integration)
> 
>Hi,
>
>On 10/18/12 14:41, Pieren wrote:
>> It's more than 5 minutes if you have to create first a new email
>> account (I know now all the tricks to duplicate our first email
>> account but then explain why a different email address is still
>> required) then spend time to continuously switch from one account to
>> the other.
>
>Both of these are technical issues that could be solved, and I'm prepared to 
>help solve them - at least on the JOSM side, it would be easy to make it so 
>that JOSM can store multiple identities and when you hit "upload" you can 
>select which identity to use from a drop-down, and as for the 
>many-accounts-one-email question, I'm sure that could be solved somehow as 
>well.
>
>If I do that, would that change the attitude towards the "separate account" 
>question, or would it be a a waste of time?
>
>Bye
>Frederik
>
>-- Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
>___
>talk mailing list
>t...@openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk
>
>
>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr