Reunions Francophones/Réunion spéciale Corine

Ordre du jour

Le but de cette réunion est de:

• valider la liste des tags OSM correspondant aux classes Corine Land Cover (CLC) et longuement discutées sur la liste de diffusion. Voir la page wiki WikiProject France/Corine Land Cover/Nomenclature
• voir comment on procède pour importer les données et avec quels outils

Log de la réunion

<pieren> pour les tags, vous pensez quoi de la page actuelle http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature ?
<pieren> alors pour la liste des tags OSM, il n'y aucune objection au schéma actuel ? parce que c'est pas un exemple de clarté et de grande logique
<Melaskia> pour les tags Corine, il y a 3 informations principales, categorie (code_06), id, et annee
<pieren> certaines classes sont adoptées et d'autre rejetées alors qu'elles sont assez proches
<pieren> mais si ça satisfait tout le monde alors on peut passer à l'étape suivante
<Melaskia> FrViPofm, de retour?
<FrViPofm> excuse : téléphone
<pieren> apparement nous ne somme que deux pour l'instant, Melaskia si tu n'as aucun commentaire a faire sur les tags on peut parler de l'import
<Melaskia> pour ma part, je suis satisfaite des categories. Je me reserve le droit d'importer certaines zones que je connais parmi les categories non acceptees d'office
* rddDavid51 (~roudoudou@lns-bzn-42-82-255-93-144.adsl.proxad.net) has joined #osm-fr
<Melaskia> bonsoir rddDavid51 
<pieren> ah, mais ça ferait bizarre non de retrouver des classes rejetées sur certaines zones uniquement
<pieren> bon d'un autre coté, on est jamais cohérent sur tout le territoire
* fabien (~4dcad883@idris.openstreetmap.org) has joined #osm-fr
<pieren> ça sera pour les mises à jour que ça risque d'être coton
<Melaskia> vi dans le cas present, je pense surtout au cas de la gare de routage que Fleury Les Aubrais a
<Melaskia> ca sera du cas par cas
<pieren> gar routiere ou ferroviere ?
<Melaskia> ferroviere
<Melaskia> 122
<Melaskia> enfin c'est un detail
<fabien> bonsoir 
<Melaskia> bonsoir fabien 
<pieren> j'ai remarqué que les polygones en ville ou adjacents sont tres approximatifs et débordent largement sur le residential
<Melaskia> vi c'est a importer avec beaucoup de precaution
<pieren> oui tu peux le faire aussi à partir d'autres sources
* monsieur_a (~monsieur_@86.68.84.200) has joined #osm-fr
<pieren> yahoo, cadastre
<FrViPofm> ok, je suis avec vous
<Melaskia> bonsoir monsieur_a 
<monsieur_a> bonsoir
<pieren> bon, je redemande une derniüre fois donc, il n'y a aucune objection concernant les tags OSM équivalents CLC documentés sur le wiki ?
<FrViPofm> aucune
<FrViPofm> sachant qu'il y aura un dépot pour les rubuts
<FrViPofm> rebuts
<pieren> j'ai peur que certains ne soient pas trop d'accord mais n'osent pas s'exprimer, ni ici, ni sur la ml
* fabien has quit ()
<pieren> les rejetés, c'est une chose, mais il y a aussi le choix des tags eux-meme
* fabien (~4dcad883@idris.openstreetmap.org) has joined #osm-fr
<pieren> bon, on peut passer à l'import alors. Melaskia, tu vois ça comment ?
<FrViPofm> pour ma part, j'ai bien exprimé mon avis sur la ml (Vincent Pottier) donc rien à ajouter, ni à retrancher
<Melaskia> pour l'import je peux generer des fichiers OSM
<pieren> un par classe ou toutes les classe ensemble ?
<Melaskia> que veux tu dire par un par classe?
* fabien has quit ()
<pieren> un fichier osm par classe CLC ou tag OSM
<pieren> ou par type de polygone
<Melaskia> je pense par classe CLC
<Melaskia> sinon ca va etre ingerable
<FrViPofm> un découpage par zone (rectangle ou département), c'est pas mieux que par classe ? doublons de points
<pieren> donc par exemple les classes 311, 312 et 313 feraient 3 fichiers osm ? mais tous seraient tagués avec landuse=forest
<Melaskia> j'avais cree initialement un fichier osm pour les 3 classes
<pieren> et comment fusionner les points utilisés par plusieurs polygones ?
<FredB> désolé j'arrive en retard, les tags du wiki sont ok pour moi aussi
<Melaskia> pour fusionner les points, je peux le faire avant l'import, c'est plus simple
<pieren> ok merci FredB
<pieren> il y a certains feedback qui me rassurent
<Melaskia> on peut le faire apres mais ca sera plus dur
<pieren> donc il faut faire un fichier OSM avec toutes les classes ensemble si tu le fais avant l'import
<FrViPofm> càd récupérer les points existants sur osm pour générer le nouveau fichier ?
<pieren> ça , c'est la deuxieme methode mais je prefererais aussi la premiere
<FredB> les edits sont limitées à 50000 par changeset, il faut je pense y faire attention
<Melaskia> qui a cree l'API python?
<Melaskia> je sais que c'est l'un d'entre vous
<pieren> oui j'espère que le script qui fera l'upload sera assez intelligent pour faire le découpage lui-meme
<FredB> ok
<Melaskia> je pensais utiliser l'API Python et faire le decoupage comme cela
<Melaskia> ok
<FredB> http://wiki.openstreetmap.org/wiki/PythonOsmApi 
<FredB> Etienne Chové
<pieren> en écrivant un nouveau script python ou en réutilisant un script existant ?
<Melaskia> en modifiant si besoin est
<pieren> le plus difficile est de gérer une grosse quantité de transactions
<Melaskia> bon pour une idee d'importation des donnees, il est possible pour moi assez facilement de fusionner des points existants avec le futur import ce n'est pas vraiment un probleme
<pieren> qui penvent échouer (donc avec reprise en cas d'echec)
<Melaskia> ca implique de fusionner un fichier recent OSM avec le fichier cible OSM
<pieren> c'est ce qu'est capable de faire je crois le script bulk_import mais c'est du perl
<Melaskia> la chose que je ne sais pas faire, c'est creer un changeset qui vient de la base de donnee
<Melaskia> Perl je ne touche pas du tout
<Melaskia> Python j'en fais regulierement au travail
<pieren> " fusionner un fichier recent OSM avec le fichier cible OSM", tu veux dire charger tous les nodes sur une zone pour voir lesquels devraient fusionner avec ceux de CLC à venir ?
<Melaskia> oui
<pieren> ouhlala, ça risque d'être très très long
<Melaskia> osmosis fait ca tres bien, apres il faut faire tourner une requete SQL
<Melaskia> non
<Melaskia> ca devrait etre assez rapide en fait
<Melaskia> sur un polygone comme la France, pas plus de 2h a mon avis
<pieren> parce que les requetes sur OSM sont limitées en taille bbox
<pieren> ah tu veux faire ça sur un extract ? 
<Melaskia> oui
<pieren> mais comment etre sûr que les nodes sont encore dans la base ?
<Melaskia> au boulot, je travaille generalement sur le monde et on arrive a obtenir des vitesses tres raisonnables
<Melaskia> c'est le probleme si l'on prend les points existants en compte
<Melaskia> sinon prends une base de donnee relativement fraiche comme celle de Geofabrik resoud le probleme
<Melaskia> je crois que Geofabrik genere leurs fichiers tous les jours
<pieren> tu ne pourras pas éviter les modifications faites dans la journée
<pieren> tout ton changeset risque d'échouer parce qu'un node a été supprimé par quelqu'un
<Melaskia> quelle est la probabilite qu'il y ait un changement vraiment
<pieren> d'après ce que j'ai lu sur d'autres imports de masse, les modifications sur les nouvelles données arrivent assez rapidement
<pieren> bien sur, ça n'arrivera pas à tous les changeset mais on peut etre certain que ça arrivera pour quelques changeset
<Melaskia> oui
<Melaskia> le plus simple est de ne pas tenir compte des points existants
<FrViPofm> entre le début et la fin de l'import : quel délai aproximatif
<Melaskia> et les fusionner au fur et a mesure
<Melaskia> FrViPofm, ca depend de la taille de l'import
<pieren> tu veux dire fusionner les points dans un deuxième temp ?
<Melaskia> oui
<Melaskia> tu telecharges une zone et tu fusionnes
<pieren> à vue de nez, je dirais que ça pourrait durer plusieurs jours, une semaine
<pieren> fusionner avec quoi, josm ?
<FrViPofm> donc risques importants de modifs
<pieren> sauf si tu mets a jour l'extract chaque nuit
<Melaskia> pas forcement puisqu'on a fait une recherche sur les polygones qui ne touchent rien
<Melaskia> les points qui sont fusionnables sont donc ceux de CLC eux meme
<pieren> je pensais que le plus simple serait de créer un énorme fichier OSM avec toutes les classes dedans et les nodes deja fusionnés. Après il ne reste plus qu'à faire l'upload, lentement mais surement
<Melaskia> je pense que c'est le plus simple en effet
<pieren> mais il reste encore une difficulté
<Melaskia> une seule? :)
<pieren> hehe
<FrViPofm> Mais nodes déjà fusionné, ça veut dire avoir des ids pour ces nodes, non ?
<Melaskia> non pas forcement
<FrViPofm> des ids fournis par osm
<Melaskia> quand tu crees un fichier OSM a partir de donnees non existantes, ca donne un chiffre negatif
<pieren> voila, c'est un id negatif mais il peut etre utilisé par plusieurs ways
<Melaskia> donc tu peux fusionner des points dans un fichier OSM consistent en lui meme
<FrViPofm> j'avais remarqué, mais il n'y a pas d'effets de bord entre deux changeset ?
<pieren> bonne remarque
<Melaskia> je ne crois pas
<Melaskia> puisqu'on uploadera des donnees au fur et a mesure
<pieren> bin si, on ne peut pas réutiliser l'id négatif apres un changeset
<Melaskia> ca veut juste dire qu'il faut charger les ways utilisant le meme node dans le meme changeset
<FrViPofm> a priori, on a une surface à peu près continue...
<pieren> mais comme tous les polygones se touchent plus ou moins, tu ne pourras pas définir une série 
<pieren> tu me l'ote de la bouche
<Melaskia> il faut voir
<FrViPofm> dans la transacrion, osm retourne des ids ?
<pieren> non
<FrViPofm> je suppose que JOSM fonctionne comme ça
<Melaskia> je ne connais pas trop comment ca fonctionne
* Marcussacapuces91 has quit (Quit: trop technique pour moi. Bonne nuit.)
<pieren> peut-etre font-ils un GET apres le PUT ?
<Melaskia> je pense qu'il faudra que je regarde
<FrViPofm> sinon il faut faire une séquence longue : upload, extract, mise à jour de la base pour les bords, upload...
<Melaskia> oui 
<pieren> http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#Create:_PUT_.2Fapi.2F0.6.2F.5Bnode.7Cway.7Crelation.5D.2Fcreate
<Melaskia> il y a une liste pour les imports qui se cree
<pieren> Response
<pieren> The ID of the newly created element (content type is text/plain) 
<pieren> oui on recoit le nouvel ID apres la creatoin
<FrViPofm> Ça dialogue plus vite qu'avec l'extract...
<pieren> l'extract est beaucoup rapide que faire des downloads sur la base OSM
<pieren> OSM limite la taille des bbox
<pieren> et on recoit des quantités de données qui ne nous interresse pas
<pieren> a moins d'utiliser XAPI
<Melaskia> xapi est down pour le moment
<Melaskia> phone sorry
<pieren> je pense qu'il faudrait faire un gros fichier avec les nodes deja fusionnés, puis etre capable de reprendre l'upload en cas d'interruption ou d'erreur, pour ca, il faudrait garder en permanence un tableau d'équivalence entre les ID négatifs et les ID réels qu'on reçoit de la base OSM au fur et à mesure des creations
<pieren> bulk_import.pl est capable de reprendre un upload interrompu, je pense qu'il faudra que le script python en fasse de meme
<Melaskia> oui ou utiliser le script oerl
<FrViPofm> ou remplacer les ids négatifs par les ids osm. On sait où on en est...
<Melaskia> re
<Melaskia> enfin je regarderais comment faire l'import
<Melaskia> je peux creer le gros fichier OSM sans probleme avec les points fusionnes entre eux s'il y en a
<pieren> le script bulk_import n'est pas compatible API 0.6
<FrViPofm> pas de perl ;-)
<Melaskia> ok bon, je vais voir avec Etienne si on ne peut pas etendre son API pour reimplementer Bulk Import
<Melaskia> bah Perl aujourd'hui j'ai du y toucher au boulot et j'aimerais autant que possible eviter de toucher a ce language
<pieren> oui je comprend ;-)
<pieren> bon, admettons que tu créées un énorme fichier OSM et qu'on trouve un script qui va bien pour l'upload
<pieren> ce fichier ne concernera que les polygones sans overlap, c'est ça ?
<Melaskia> oui
<pieren> c.a.d 0% ou 1% ou.. quelle sera la limite ?
<Melaskia> le but du jeu est d'importer avec une certaine confiance
<Melaskia> 0%
<pieren> est-ce que ca n'est pas un peu trop restrictif ?
<pieren> 5% d'overlap, c'est supportable non ?
<FrViPofm> on a une idée du tau d'overlap ?
<FrViPofm> de polygones avec overlap ?
<_mat_> (je lis en travers, JOSM fait un changeset/xxx/upload)
<Melaskia> FrViPofm, oui on a une idee
<Melaskia> j'ai un script SQL qui permet de calculer cela
<pieren> j'ai retrouvé ça dans un mail de sly:
<pieren> Après rapide estimation, 270,000 polygones corine, en supposant que 10% seront
<pieren> en conflict dans OSM (c'était à la louche le ratio de tes overlap/nooverlap)
<pieren> et une moyenne à 10ko par fichier.
<pieren> 270 Mo et 27,000 fichiers.
<Melaskia> je peux donner les resultats pour foret et villes si vous voulez
<Melaskia> c'est calcule sur ma base de donnee actuellement
<pieren> mais le problème, c'est que tu avais créé 3 catégories 0%, 1..5%, 6..100%. Je pensais que la deuxieme categorie irait dans l'import direct
<FrViPofm> si beaucoup de polygones ont de l'overlap, on monte le seuil de tolérance
<Melaskia> on peut faire de l'import direct sur la deuxieme categorie sans probleme
<Melaskia> c'est l'avantage de la methode que j'ai c'est juste une valeur a modifier dans le script SQL present sur le wiki
<pieren> je pense que si deux polygones se superposent de 5%, c'est encore acceptable
<Melaskia> oui 
<FrViPofm> il me semble aussi
<pieren> d'ailleurs, c'est 5% de quoi ? de la surface totale ou du plus grand polygone ?
<Melaskia> du plus grand polygone
<FrViPofm> on sait que clc est grossier et qu'il faudra ajuster
<Melaskia> oui
<_mat_> (c'est mieux de faire un changeset/upload, parce que tout ce qui est dans l'upload sera fait dans une transaction)
<Melaskia> _mat_, le probleme majeur c'est que notre import est massif et que tout ne tiendra pas dans un changeset
<_mat_> Melaskia, hum, oui, non, bien sur :-)
<_mat_> l'idée, c'est de faire des upload auto-contenus
<Melaskia> tu as donc le probleme de garder la coherence dans ce cas la
<_mat_> un changeset/upload qui crée un certain nombre de nodes, de polygones, de relations, ou je ne sais quoi, mais qui est indépendant
<Melaskia> oui on evoquait le sujet plus haut mais si on fusionne les points adjacents on peut creer une situation ou si on ne fait pas attention ou l'on cassera un way, ou une relation
* emarsden (~user@mir31-3-82-234-52-44.fbx.proxad.net) has joined #osm-fr
<pieren> le point le plus critique pour l'instant est de trouver le script qui fera l'upload sans se planter en cas d'erreur du serveur et capable de reprendre en cas d'interruption
<pieren> cela nécessite du developpement et des tests avant de franchir le pas
<_mat_> hum, ce qui est important, c'est que, hum, le flot de données entrant soit hum, concis, c'est pas grave si on réutilise un node déjà uploadé dans un autre changeset avant
<_mat_> tant qu'on l'utilise pas avant de l'avoir uploadé :-)
<FrViPofm> le script qui met à jour les ids dans le fichier osm  : ids négatifs => à uploader, quand tout est positif : bingo !
<Melaskia> oui mais je ne suis pas sure que le changeset te donne l'id est positif
<_mat_> cela dit, c'est aussi possible d'uploader d'abord tous les nodes, puis les way, mais ça me semble mieux de faire ça morceau par morceaux, ça évite que les nodes qui vont rester seuls dans leurs coins soient supprimés parce que pas taggés tout ça
<Melaskia> je pense que de toute facon demain je vais envoyer un mail sur la mailing list anglaise pour l'import
<pieren> Melaskia j'ai copié le texte de l'API. Il te retourne le nouvel ID quand tu fais le PUt de creation du node
<pieren> je pensais le faire aussi 
<pieren> il existe un groupe de support pour les imports de masse
<pieren> tu connais l'adresse ?
<pieren> il faut demander si le script bulk_upload a été remplacé depuis l'aPI 0.6
<Melaskia> j'ai vu passe ca sur la ML
<Melaskia> je demanderais a Andy Allan ou Matt Amos 
<Melaskia> ok aucun des deux sont connectes en ligne
<Melaskia> tiens dis moi _mat_ tu n'etais pas a Where 2.0?
<_mat_> nope
<Melaskia> j'ai du reve alors :P
<_mat_> c'était quand et où ?
<Melaskia> USA il y a quelques semaines
<_mat_> ah, alors, c'est sur, j'y étais pas :-)
<Melaskia> qui va a Amsterdam?
<_mat_> tu m'aurais dit au canada, j'aurais pas dit, mais aux us, non
<FrViPofm> pas moi... désolé...
<Melaskia> pieren, enfin je crois que la conclusion actuelle est que comme on ne sait pas comment on va uploader, on attend d'avoir une reponse technique
<Melaskia> je viens d'avoir l'accord de ma boite
<pieren> oui mais on a deja pas mal avancé:
<Melaskia> donc j'y serais au moins vendredi et dimanche
<pieren> - pas d'objection sur le schema des tags
<_mat_> j'ai pas mal joué avec de l'import automatisé récement (quand j'ai mis un champ source=cadastre sur environ 700k nodes que j'avais oublié de faire sur des imports de limites communales)
<pieren> - separation des données CLC en deux categories : no_overlap ou overlap jusqu'a 5 % qui seront directement uploadé
<Melaskia> _mat_, je vois, tu avais procede comment?
<Melaskia> pieren, je suis d'accord avec tes conclusions
<FrViPofm> moi aussi. Des pistes pour traiter les rebuts ?
<Melaskia> pour les rebuts, c'est une bonne question
<pieren> ça c'est le dernier point à voir. Il faudra les résoudre à la mano
<_mat_> Melaskia, hum, par étapes, récupérer mes changesets qui contenaient des nouvelles relations, récupérer ces relations, choper les nodes qui n'avaient pas de tags source, ajouter la source, uploader un changeset par node
<_mat_> s/node/relation/
<Melaskia> tu utilisais l'API REST?
<_mat_> trois petits scripts
<_mat_> oui
<pieren> _mat_ pourquoi ajouter le tag source cadastre sur les nodes alors qu'il suffit de le mettre sur les ways ?
<Melaskia> _mat_, quel type de script?
<_mat_> pieren, parce que si on déplace des morceaux, la source n'est plus le cadastre pour ces morceaux là
<_mat_> Melaskia, euh, trois scripts ruby, à base de Net::HTTP, de REXML et de XPATH
<pieren> ça ne change rien - le tag source=cadastre n'est pas une garantie contre les altérations
<Melaskia> oki donc Perl :p
<_mat_> non, ruby
<Melaskia> ah, encore pire :p
<_mat_> Melaskia, bah, différent
<Melaskia> non mais je plaisante :)
<_mat_> tu veux voir mon script awk qui va récupérer les infos sur wikipedia pour créer un node place et la relation pour la commune ? :-p
<Melaskia> euh tu sais que l'import a partir de Wikipedia n'est pas vraiment authorise
<pieren> non pas vraiment, c'est des données IGN
<pieren> je parle de la position
<_mat_> je bouge toujours la position après coup
<_mat_> après un rapide coup d'oeuil sur le cadastre
<pieren> ouais bo, je vais faire le sketch des trois singes qui se bouchent les yeux, les oreilles et ne disent rien
<_mat_> :)
<Melaskia> au fait, est ce que les gens ont vu le message que j'avais mis venant de mon ami avocate?
<FrViPofm> Oui
<Melaskia> ok, comme je n'avais pas vu de reponse je me posais la question
<FrViPofm> Mais je n'ai pas d'opinion : le droit c'est pas mon truc.
<pieren> c'était quoi deja son avis ? 
<pieren> qu'on pouvait utiliser mais je ne sais plus sur quel argument
<FrViPofm> qu'il y avait un travail d'intelligence je crois
<Melaskia> utilisable car c'est un fait public grosso modo 
<Melaskia> et parce que tu as lu
<Melaskia> enfin je peux renvoyer le mail si besoin
<FrViPofm> Mais ça avance pour les fiches de géodésie, on est pas loin d'avoir une autorisation béton
<FrViPofm> donc la hauteur des sommets...
<Melaskia> vi je lisais ca cette apres midi
<FrViPofm> On revient aux rebuts ?
* emmanuel_lap (~pacaud@pom74-2-82-247-189-1.fbx.proxad.net) has joined #osm-fr
<pieren> tout le problème est de savoir quelles sont les activités entièrement subventionnées. Pour celles-la, il n'y aura pas de probleme. Mais pour les autres... reste à savoir si la position des villes est entierement subventionné ou pas
<pieren> pour revenir aux "rebuts", 
<pieren> je suis pour faire un découpage en petites zones que les gens pourront s'approprier et identifier
<pieren> genre par département ou canton
<pieren> ou demi-departement
<pieren> et on fait la fusion à la main avec josm
<FrViPofm> genre dépot des communes ?
<Melaskia> plusieurs solutions ont ete proposees pour le stockage: un fichier OSM par polygone, un gros fichier osm qu'on decoupe a coup de Osmosis, ou decoupe a la volee sur la base de donnee
<pieren> la question est qu'il faut qu'on sache quelles zones ont été traitées et lesquelles restent a faire
<Melaskia> oui et c;est la ou je n'ai pas trop compris tes questions sur la ML pieren 
<FrViPofm> la base de donnée, ça peut donner un layer ?
<Melaskia> qu'appelle tu layer?
<_mat_> calque ?
<FrViPofm> calque openLayer. du coup on peut superposer osm et les rebuts
<pieren> une fois qu'une personne aura fait la fusion des polygones en overlap avec OSM, comment éviter que quelqu'un d'autre repasse derrière sur la meme zone ?
<Melaskia> je peux creer facilement une intersection avec une bounding box dans la base de donnee
<Melaskia> oui on peut faire ca facilement
<pieren> je ne comprend pas
<pieren> admettons qu'on ait une base avec les polygones en overlap
<FrViPofm> autre piste : avec les extracts on peut supprimer de la base de donnée ?
<Melaskia> ok
<pieren> ou alors on travaille avec des fichiers
<pieren> disons un fichier osm avec un paquet de 10 ou 20 polygones à fussionner avec osm
<FrViPofm> mais comment mettre à jour l'info de ce qui est entré
<pieren> une personne prend le fichier et le supprime du depot
<Melaskia> travailler avec des fichiers ca va etre enorme si on ne fait pas gaffe mais c'est possible
<pieren> puis il résout les polygones avec JOSM et passe au fichier suivant
<Melaskia> ou du moins le rendre temporairement inaccessible
<pieren> si c'est pas un fichier, c'est dans une bdd
<FrViPofm> Ça me paraît plus dynamique
<Melaskia> je ne suis pas pour un fichier car ca implique une gestion bien plus lourde
<pieren> c'est encore plus compliqué, comment signaler à la base qu'un polygone est résolu dans osm (fusionné ou non pris en compte) ?
<Melaskia> de plus effacer un fichier est "dangereux" si on ne gere pas ca bien correctement
<pieren> mais si tu ouvres l'accès à ta base, et si on peut supprimer les polygones dans la base, c'est pareil
<pieren> et c'est plus compliqué
<Melaskia> non car je mettrais un flag efface
<Melaskia> autrement dit, je n'efface jamais rien
<pieren> comment ? il faudra créer une interface
<Melaskia> oui il faudra creer une interface
* persei (~fm@lns-bzn-52-82-65-127-119.adsl.proxad.net) has left #osm-fr
<FrViPofm> web ? JOSM ?
<pieren> et c'est plus simple que de créer des fichiers ?
<Melaskia> mais personnellement je trouve les fichiers plus compliques a gerer, enfin ce n'est que moi
<pieren> regarde les limites communales sur le dépot de Sly, ca marche
<Melaskia> il faut voir
<Melaskia> je suis ouverte a toute suggestion
<pieren> sinon il faut trouver quelqu'un pour déveloper une interface 
<pieren> qui ne servira qu'une fois
<FrViPofm> Il y a d'autres européens
<Melaskia> oui
<pieren> et même avec une interface, je ne vois pas encore bien comment cela va fonctionner. Tu demanderas tous les polygones sur un bbox , c'est ca ?
<FrViPofm> oui, ou une classe
<Melaskia> oui ou une forme
<FrViPofm> ;-)
<Melaskia> il faut voir le cote logistique
<pieren> puis 2 heures ou 2 jours plus-tard, tu vas dire : ok tous les polygones de ce bbox ont été fusionnés, marque le flag delete pour eux, et voila, c'est ça ?
<Melaskia> voila, c'est l'idee de base
<pieren> donc il faut garder en mémoire le bbox
<pieren> ou le noter sur un bout de papie
<pieren> r
<pieren> ou un bookmark
<Melaskia> ou demander a l'utilisateur de se logguer
<FrViPofm> non mise à jour par comparaison avec un extract 
<Melaskia> de toute facon, on va mettre a jour l'overlap aussi
<pieren> ah, tu créé des comptes utilisateurs ?
<FrViPofm> overlap > 95% => importé
<Melaskia> un des projets en cours pour le site est l'utilisation de Oauth
<pieren> mais tu ne peux pas comparer avec un extract, tu ne peux pas savoir comment les conflits seront résolus
<FrViPofm> certes
<pieren> pourquoi 95%, ca peut etre 10 polygones avec des tags différent pour un polygone CLC ou l'inverse
<pieren> ca peut etre 20% et etre juste
<pieren> c'set impossible a valider automatiquement
<Melaskia> enfin je suis desolee, mais je fatigue, je pense que cette discussion sera mieux lancee sur la ML
<FrViPofm> ok
<pieren> bon ok
<Melaskia> il y a des gens avec plus d'experience comme Sly par exemple
<FrViPofm> OK rendez-vous sur la ML
<FrViPofm> Merci à Pieren pour l'animation pour les codes CLC
<pieren> bof
<FrViPofm> Bah si on a fini !
<Melaskia> oui merci beaucoup pieren pour ton role ;) tu as meme reussi a emmener les Estoniens :)
<pieren> je vais mettre le log quelque part sur le wiki comme ca, Sly le sauveur  pourra nous relire ;-)
<emarsden> ça pourrait être un mailbox IMAP public, que chaque lecteur marquerai par un flag pour indiquer qu'il a "pris" une zone
<FrViPofm> Oh, je sens la trouvaille, mais je ne connais pas.
<pieren> ca marcherait comment ça ?
<FrViPofm> emarsden, on en reparle sur la mailing-list ? 
<emarsden> chaque zone serait un courriel dans une boite IMAP publique
<Melaskia> emarsden, oui enfin partager un serveur imap, je ne suis pas convaincue :p
<emarsden> ça peut être une boite gmail ...
<pieren> bonjours les spams ;-)
<pieren> et les polygones OSM seraient dans les emails ?
<FrViPofm> Bonne nuit à vous.
<emarsden> oui, des pieces jointes dans chaque message