Re: [OSM-talk-fr] Communes Nodes Ways
Marc SIBERT a écrit : Bonjour, Au vu de la règle : on ne code jamais deux fois un élément avec des objets différents (nodes, ways, relations) et le résultat sur les renders, est-il encore judicieux de tagger les communes avec un node Place et avec leur contour ? Je crois que ça a déjà été discuté. Le polygone sert de limite, le point sert à positionner le centre administratif (la préfecture d'un département, le centre d'une commune... ce qui n'est pas calculable). Cependant comme le node sera dans la relation de la commune a termes, il ne sera plus nécessaire de lui mettre toutes les informations. Je me trompe ? -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes Nodes Ways
Bonjour, on pourrait en theorie calculer un point en utilsant un centroid sur le polygone, permettant de placer le point sur le barycentre du polygone. Emilie Laffray Etienne Chové wrote: Marc SIBERT a écrit : Bonjour, Au vu de la règle : on ne code jamais deux fois un élément avec des objets différents (nodes, ways, relations) et le résultat sur les renders, est-il encore judicieux de tagger les communes avec un node Place et avec leur contour ? Je crois que ça a déjà été discuté. Le polygone sert de limite, le point sert à positionner le centre administratif (la préfecture d'un département, le centre d'une commune... ce qui n'est pas calculable). Cependant comme le node sera dans la relation de la commune a termes, il ne sera plus nécessaire de lui mettre toutes les informations. Je me trompe ? signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 32 Milieux à végétation arbustive et/ou herbac ée
Tout pareil :) Voire même pour 324 : pas d'import. Antoine - Mail Original - De: Mathieu Arnold m...@mat.cc À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Mercredi 27 Mai 2009 23h47:46 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [OSM-talk-fr] Corine Land Cover : nomenclature 32 Milieux à végétation arbustive et/ou herbacée +--On 27 mai 2009 22:28:24 +0200 Pieren pier...@gmail.com wrote: | * la classe 321 Pelouses et pâturages naturels est proposée en | natural=fell sur le wiki. La description de fell se trouve ici sur | le wiki : | http://wiki.openstreetmap.org/wiki/Tag:natural%3Dfell | On notera toutefois que la nomenclature CLC en anglais utilise plutôt | le terme de grassland | (http://etc-lusi.eionet.europa.eu/CLC2000/classes/Pictures?CLCcategory=3/ | 3.2/3.2.1CLCtitle=Natural%20grasslands) qui existe aussi en tant que | proposition sur le wiki : | http://wiki.openstreetmap.org/wiki/Proposed_features/Grassland | Je proposerais donc de remplacer natural=fell par natural=grassland. +1 pour grassland | * la classe 322 Landes et broussailles est proposée à la traduction | en natural=heath. Ce tag est présent dans la Map Features et c'est | aussi le terme utilisé dans la nomenclature CLC en anglais (Moors and | heathland). +1 | * la classe 323 Végétation sclérophylle a deux propositions sur le | wiki, soit natural=wood + wood=mixed, soit natural=scrub | (brousaille, bush). Le sous-titre en français parle de végétation | arbustive persistente comprenant maquis, garrigue et oliveraies | abandonnées. Quelques arbres isolés peuvent être présents.. Les | termes de bushes and scrubs sont utilisés par la nomenclature CLC en | anglais | (http://etc-lusi.eionet.europa.eu/CLC2000/classes/Pictures?CLCcategory=3/ | 3.2/3.2.3CLCtitle=Sclerophyllous%20vegetation). Donc la faible présence | d'arbres et la définition CLC en anglais me ferait pencher pour la | version natural=scrub mais un examen de | quelques exemples montre aussi la présence assez marquée d'arbres par | endroits (seulement ~1500 polygones). +1 pour scrub. | * la classe 324 Forêt et végétation arbustive en mutation est de | loin la plus présente dans cette catégorie (~15000). Elle est proposée | en natural=wood + wood=mixed sur le wiki. Le sous-titre parle de | Végétation arbustive ou herbacée avec arbres épars. Formations | pouvant résulter de la dégradation de la forêt ou d’une | re-colonisation / régénération par la forêt.. Les quelques photos ici | : | http://etc-lusi.eionet.europa.eu/CLC2000/classes/Pictures?CLCcategory=3/3 | .2/3.2.4CLCtitle=Transitional%20woodland-shrub montrent une grande | variété de cas. Mais un examen sur la carte en ligne et google désigne | plutôt des espaces de jeunes arbrisseaux, donc une future forêt (dans | le sud, ça peut concerner d'anciennes zones brûlées). Marquer ces | zones comme de la forêt me parait abusif dans la majorité des cas mais | je n'ai pas d'autre proposition à soumettre. J'aurais tendance à ne pas | importer ces polygones. Pas d'avis. -- Mathieu Arnold ___ 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] Corine Land Cover : nomenclature 22 Cultures permanentes
Tout à fait d'accord. Antoine - Mail Original - De: sylvain letuffe sylv...@letuffe.org À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Mercredi 27 Mai 2009 23h50:51 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [OSM-talk-fr] Corine Land Cover : nomenclature 22 Cultures permanentes * ou landuse=orchard + trees=olive_tree. (en partie basé sur la discussion http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/plantage) +1 C'est de loin la solution la plus propre a mes yeux. +2 Il sera toujours temps de revenir dessus pour faire autrement (car il n'y a pas que nous français), mais ça me semble mieux que le curieux plantage ou un nième landuse=olive_trees -- sly ___ 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] Communes Nodes Ways
Bonjour, En fait ma question, c'était plutôt dans le sens : ne peut-on pas supprimer le Node des communes dont le contour est défini. Les informations Place, etc peuvent être taggées dans la relation, la préfecture, mairie sont des bâtiments publics que l'on peut aussi mettre dans la relation si nécessaire, mais est-ce nécessaire ? Je corrige régulièrement des parkings avec un way et un node dedans et je vois ces communes avec des ways du contour et un node dedans. Voilà, voilà. -- Marc On Thu, 28 May 2009 08:11:55 +0100, Emilie Laffray emilie.laff...@gmail.com wrote: Bonjour, on pourrait en theorie calculer un point en utilsant un centroid sur le polygone, permettant de placer le point sur le barycentre du polygone. Emilie Laffray Etienne Chové wrote: Marc SIBERT a écrit : Bonjour, Au vu de la règle : on ne code jamais deux fois un élément avec des objets différents (nodes, ways, relations) et le résultat sur les renders, est-il encore judicieux de tagger les communes avec un node Place et avec leur contour ? Je crois que ça a déjà été discuté. Le polygone sert de limite, le point sert à positionner le centre administratif (la préfecture d'un département, le centre d'une commune... ce qui n'est pas calculable). Cependant comme le node sera dans la relation de la commune a termes, il ne sera plus nécessaire de lui mettre toutes les informations. Je me trompe ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] message d'erreur sur JOSM
Bonjour, J'essaye d'uploader mes modifs et j'ai le message d'erreur suivant : Precondition failed : Node 411695997 is still used by way 35093505 Que faire ? J'ai essayé de rechercher les deux id (par la recherche id:411695997 et pareil pour le way, mais je n'ai rien trouvé) J'ai pas trop envie de perdre mes modifs. Merci pour votre aide, Axel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] message d'erreur sur JOSM
Ça m'est arrivé hier, je pense que c'était lors de l'upload où le validator a ralé et je lui ai laissé corriger des noeuds en double, et apparemment il a mal corrigé. Normal que tu ne le trouves pas car il est sûrement supprimé. D'ailleurs c'est ch*** que l'historique soit supprimé dès qu'on upload, même quand l'upload plante : on ne peut plus revenir en arrière. Solution : j'ai enregistré le calque en .osm, puis je l'ai ouvert avec un éditeur de texte, viré à la main les 3 lignes concernant la suppression du noeud en question, enregistré, réouvert avec JOSM et upload ok :) 2009/5/28 Axel R. a...@esperanto-jeunes.org Bonjour, J'essaye d'uploader mes modifs et j'ai le message d'erreur suivant : Precondition failed : Node 411695997 is still used by way 35093505 Que faire ? J'ai essayé de rechercher les deux id (par la recherche id:411695997 et pareil pour le way, mais je n'ai rien trouvé) J'ai pas trop envie de perdre mes modifs. Merci pour votre aide, Axel ___ 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] Communes Nodes Ways
Moi je dis comme Étienne : le node c'est le centre-ville, et comme on en a déjà discuté plusieurs fois : ça n'est pas calculable... Par contre je suis bien d'accord que la plupart des infos pourraient être déplacées sur la relation car elles concernent aussi la surface (code INSEE, population, etc.) Yann Le 28 mai 09 à 09:30, Marc SIBERT a écrit : En fait ma question, c'était plutôt dans le sens : ne peut-on pas supprimer le Node des communes dont le contour est défini. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes Nodes Ways
Question collatérale : pour les communes composées de plusieurs anciennes communes regroupées, par exemple Dio-et-Valquières dans l'Hérault, faut-il conserver un node Dio-et-Valquières ou se contenter d'un node Dio (portant les infos INSEE and co) et d'un node Valquières ? Le 28 mai 2009 04:15, Marc SIBERT m...@sibert.fr a écrit : Bonjour, Au vu de la règle : on ne code jamais deux fois un élément avec des objets différents (nodes, ways, relations) et le résultat sur les renders, est-il encore judicieux de tagger les communes avec un node Place et avec leur contour ? Comment cela se fait dans les autres pays ? PS : ça sent le troll ;-) -- Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Lionel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes Nodes Ways
2009/5/28 Yann Coupin y...@coupin.net: non pas troll ;-) le node représente le centre de l'agglomération et le boundary la limite administrative. Même s'ils portent le même nom, c'est pas tout à fait la même chose. Mais c'est vrai que certains tags pourraient comme le code postal et le code INSEE pourraient migrer vers la relation. Mais si on fait ça maintenant, on aura une différence de traitement entre les communes avec relation et les communes sans (qui sont encore largement majoritaires). Il y a aussi des questions qui ne sont pas claires. Quid des regroupements de communes (une relation, deux nodes place=village) ? Quid du tag population dans ces cas-là ? Quid des codes postaux qui ne correspondent pas aux limites adminstratives ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] message d'erreur sur JOSM
j'ai eu exactement le même problème hier soir! validator a planté, j'ai tout de même essayé l'upload (je suis un kamikaz je sais!). Forcément, ca a planté avec l'erreur précondition failed... Le 28 mai 2009 09:42, Julien D. murphy2...@gmail.com a écrit : Ça m'est arrivé hier, je pense que c'était lors de l'upload où le validator a ralé et je lui ai laissé corriger des noeuds en double, et apparemment il a mal corrigé. Normal que tu ne le trouves pas car il est sûrement supprimé. D'ailleurs c'est ch*** que l'historique soit supprimé dès qu'on upload, même quand l'upload plante : on ne peut plus revenir en arrière. Solution : j'ai enregistré le calque en .osm, puis je l'ai ouvert avec un éditeur de texte, viré à la main les 3 lignes concernant la suppression du noeud en question, enregistré, réouvert avec JOSM et upload ok :) 2009/5/28 Axel R. a...@esperanto-jeunes.org Bonjour, J'essaye d'uploader mes modifs et j'ai le message d'erreur suivant : Precondition failed : Node 411695997 is still used by way 35093505 Que faire ? J'ai essayé de rechercher les deux id (par la recherche id:411695997 et pareil pour le way, mais je n'ai rien trouvé) J'ai pas trop envie de perdre mes modifs. Merci pour votre aide, Axel ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes Nodes Ways
2009/5/28 Lionel Maraval lionel.mara...@gmail.com: Question collatérale : pour les communes composées de plusieurs anciennes communes regroupées, par exemple Dio-et-Valquières dans l'Hérault, faut-il conserver un node Dio-et-Valquières ou se contenter d'un node Dio (portant les infos INSEE and co) et d'un node Valquières ? Ben justement, il y a eu quelques discussions l'année dernière sur ce point et pour l'instant on met deux nodes place=village et un des deux porte le code insee et postal. Mais il faudrait aussi ajouter un tag sur l'autre node pour indiquer qu'il fait administrativement partie maintenant d'une autre commune (mais géographiquement, ça peut être deux agglomérations clairement séparée). D'ailleurs un panneau signale souvent ce rattachement à l'entrée du village. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] message d'erreur sur JOSM
Merci beaucoup. J'ai pensé au début que ça n'avait pas marché car plusieurs noeuds étaient dans ce cas et il m'affichait le même message avec un autre numéro de noeud... On prends les mêmes et on recommence et au bout de 4/5 noeuds retiré à la mimine dans le fichier .osm, ça a fini par fonctionner. Merci beaucoup ! Axel Ça m'est arrivé hier, je pense que c'était lors de l'upload où le validator a ralé et je lui ai laissé corriger des noeuds en double, et apparemment il a mal corrigé. Normal que tu ne le trouves pas car il est sûrement supprimé. D'ailleurs c'est ch*** que l'historique soit supprimé dès qu'on upload, même quand l'upload plante : on ne peut plus revenir en arrière. Solution : j'ai enregistré le calque en .osm, puis je l'ai ouvert avec un éditeur de texte, viré à la main les 3 lignes concernant la suppression du noeud en question, enregistré, réouvert avec JOSM et upload ok :) 2009/5/28 Axel R. a...@esperanto-jeunes.org Bonjour, J'essaye d'uploader mes modifs et j'ai le message d'erreur suivant : Precondition failed : Node 411695997 is still used by way 35093505 Que faire ? J'ai essayé de rechercher les deux id (par la recherche id:411695997 et pareil pour le way, mais je n'ai rien trouvé) J'ai pas trop envie de perdre mes modifs. Merci pour votre aide, Axel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Rivières, cadastre (et CORINE ?)
Bonjour la liste :) je me suis mis à mapper des cours d'eau et rivières dans les Vosges en me basant sur le cadastre. Je commence à peine et je voulais avoir votre avis avant d'aller plus loin. Pour l'instant, j'ai seulement fait des waterway={river, stream}. Je comptais me lancer dans les aires 'riverbank', mais je lis sur le wiki que ce tag est pour les rivières de la taille de la Tamise et que les plus petites se contentent d'un simple way. Je pense que c'est un peu dommage de perdre la précision du cadastre. D'où ma question: à partir de quelle taille une rivière mérite ses berges? Corine référence les rivières de plus de 100m de largeur (si j'ai bien compris) et je pense qu'il y a de quoi faire en deça. À propos, y'a un fichier Corine dispo qq part pour les rivières, cours d'eau et espaces d'eau? :) Cheers, /Seb. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rivières, cadastre (et CORINE ?)
Le 28 mai 2009 11:01, Sébastien Pierrel sebastien.pier...@gmail.com a écrit : D'où ma question: à partir de quelle taille une rivière mérite ses berges? Le wiki Map features en français est effectivement moins précis qu'en anglais D'après : http://wiki.openstreetmap.org/wiki/Map_Features#Waterway la limite serait à une lergeur de 12 mètres. Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Regarde mon profil Facebook
Bonjour Liste, Je vous ai invité à rejoindre Facebook récemment et je voulais vous rappeler que dès que vous serez enregistré, vous pourrez vous connecter en ligne, partager des photos, organiser des groupes et des événements, et plus. Merci, Ratzillas Pour vous inscrire à Facebook, suivez le lien ci-dessous : http://www.facebook.com/p.php?i=636867474k=SZE35YRX4W5M5J1CWGWYSVr Ratzillas Da Rats#039; Prince a invité talk-fr@openstreetmap.org à rejoindre Facebook. Si vous ne voulez plus recevoir ce type de messages de la part de Facebook, veuillez cliquer sur le lien ci-dessous pour annuler votre inscription. http://www.facebook.com/o.php?k=07787bu=1843658522mid=885a13G6de3ff1aG0G8 Les bureaux de Facebook se trouvent à : 1601 S. California Ave., Palo Alto, CA 94304. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Regarde mon profil Facebook
On Thu, May 28, 2009 at 02:44:05AM -0700, Ratzillas Da Rats' Prince wrote: Bonjour Liste, Je vous ai invité à rejoindre Facebook récemment et je voulais vous rappeler que dès que vous serez enregistré, vous pourrez vous connecter en ligne, partager des photos, organiser des groupes et des événements, et plus. Merci, Ratzillas Pour vous inscrire à Facebook, suivez le lien ci-dessous : http://www.facebook.com/p.php?i=636867474k=SZE35YRX4W5M5J1CWGWYSVr Ratzillas Da Rats#039; Prince a invité talk-fr@openstreetmap.org à rejoindre Facebook. Si vous ne voulez plus recevoir ce type de messages de la part de Facebook, veuillez cliquer sur le lien ci-dessous pour annuler votre inscription. http://www.facebook.com/o.php?k=07787bu=1843658522mid=885a13G6de3ff1aG0G8 Les bureaux de Facebook se trouvent à : 1601 S. California Ave., Palo Alto, CA 94304. Il y a déjà suffisement de traffic sur cette liste pour ne pas envoyer des spams à l'ensemble des inscrits. J'espère que c'était une erreur de manipulation. ___ 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] Regarde mon profil Facebook
On Thursday 28 May 2009 11:55:50 am gnu...@gnunux.info wrote: Il y a déjà suffisement de traffic sur cette liste pour ne pas envoyer des spams à l'ensemble des inscrits. J'espère que c'était une erreur de manipulation. Erreur de manip ou pas c'est pas normal que ce genre de message arrive à passer sur la ML. Parce que j'ai comme un doute sur le fait que l'adresse invite+2nmwx...@facebookmail.com soit inscrite à la ML. -- Vincent MEURISSE ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rivières, cadastre (et CORINE ?)
Sébastien Pierrel a écrit : Bonjour la liste :) Corine référence les rivières de plus de 100m de largeur (si j'ai bien compris) et je pense qu'il y a de quoi faire en deça. À propos, y'a un fichier Corine dispo qq part pour les rivières, cours d'eau et espaces d'eau? :) Cheers, /Seb. Ça va venir. Ça fait parti du projet d'import de masse de CLC. Quelques aspects doivent être précisés, notamment par cette mailing liste. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Communes révolutionaires
Bonjour, Que signifie le rouge-sang pour les communes : http://beta.letuffe.org/?zoom=11lat=46.82474lon=5.5202layers=B0FFTF La couleur du maire ? Plus sérieusement : un type d'erreur ? lequel ? Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Regarde mon profil Facebook
Bonjour, Erreur de manip ou pas c'est pas normal que ce genre de message arrive à passer sur la ML. Parce que j'ai comme un doute sur le fait que l'adresse invite+2nmwx...@facebookmail.com soit inscrite à la ML. La liste est modérée ? (seuls les inscrits peuvent participer ?) Pour ce qui est du spam, connaissant Gaël, je pense qu'il s'agit d'une erreur de manip' de sa part (quoique vu l'intrusivité de facebook, m'étonnerait pas qu'en utilisant le scanneur de boite mail intégré au truc d'inscription, qui maile ensuite tous les contacts disponibles, il soit à moitié fautif) et qu'il n'avait bref pas l'intention de nuire. (désolé de participer au traffic en trop) Bonne après-midi, -- Pierre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Rivières, cadastre (et CORINE?)
Corinne contient beaucoup de donnees la dessus ? parce que pour Grenoble j etais alle jeter un coup d oeuil sur leur site et on ne voyait meme pas l isere et le drac qui ne sont pourtant pas des ruisseaux...apres ce que j ai vu n etait peut etre pas aussi fin que les donnees reelles du CLC De : Vincent Pottier vpott...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Jeudi, 28 Mai 2009, 13h55mn 29s Objet : Re: [OSM-talk-fr] Rivières, cadastre (et CORINE?) Sébastien Pierrel a écrit : Bonjour la liste :) Corine référence les rivières de plus de 100m de largeur (si j'ai bien compris) et je pense qu'il y a de quoi faire en deça. À propos, y'a un fichier Corine dispo qq part pour les rivières, cours d'eau et espaces d'eau? :) Cheers, /Seb. Ça va venir. Ça fait parti du projet d'import de masse de CLC. Quelques aspects doivent être précisés, notamment par cette mailing liste. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Bug sur beta ou restes de pâté d ans le Jura ?
http://beta.letuffe.org/?zoom=13lat=46.86325lon=5.6831layers=B0 Ce sont les restes de pâté du Jura de l'autre week-end ou un bug récent ? Je n'ai pas vu la marmelade annoncé l'autre week-end et qu'il a fallu 'reverter'. Donc je ne sais pas si ça ressemble à ce qu'on voit maintenant. Comme il y a un problème sur l'affichage de communes dans le même coin (communes rouge-sang) : http://beta.letuffe.org/?zoom=12lat=46.86325lon=5.6831layers=B0FFTF Ça a l'air drôlement tricoté ! http://www.openstreetmap.org/?lat=46.83405lon=5.5698zoom=15layers=B000FTF Je vais faire un tour avec JOSM. Mais si des 'plus compétents' trouvent des choses... Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
J'aide un peu pieren à avancer, courage on y est presque ;-) ## Rappel : ce fil de discussion aborde les tags à adopter lors de l'intégration des données Corine Land Cover France (CLCF). Voir http://lists.openstreetmap.org/pipermail/talk-fr/2009-May/009395.html pour le début de la discussion. Le document de référence est la page wiki : http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature Aucun fil de discussion n'est clos par le suivant. Tous les commentaires sont les bienvenues et vous pouvez revenir à tout moment sur les plus anciens. ## * 511 (59) Cours et voies d’eau Vu le peu de polygone, et vu leur qualité après quelques repérages, je propose tout simplement de laisser tomber le 511, OSM étant déjà bien plus fourni et précis * 512 (2 373) Plans d’eau Étendues d’eau, naturelles ou artificielles, de plus de 25 hectares. natural=water me va bien, OSM ne faisant pour l'instant pas de distinction naturel/artificiel * 521 (90) Étendues d’eau salée ou saumâtre sans végétation, séparées de la mer OSM ne fait pas de distinction entre les lacs d'eau douce et ce qu'on appellerais nous les étangs salés qu'on retrouve en bord de mer. Donc je propose le même traitement que pour les plan d'eau (soit natural=water) le tag corine étant conservé, il sera possible de garder une trace et de passer à natural=salted_water le jour où ça existera * 522 (30) Estuaires Je propose de ne pas importer * 523 (4) Mers et océans Je suppose que c'est déjà dans OSM, je propose de ne pas importer non plus. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bug sur beta ou restes de pâté d ans le Jura ?
On Thursday 28 May 2009 15:06, Vincent Pottier wrote: http://beta.letuffe.org/?zoom=13lat=46.86325lon=5.6831layers=B0 Ce sont les restes de pâté du Jura de l'autre week-end ou un bug récent ? Je n'ai pas vu la marmelade annoncé l'autre week-end et qu'il a fallu 'reverter'. Donc je ne sais pas si ça ressemble à ce qu'on voit maintenant. Très joli en tout cas, comme c'est en zoom 13, c'est un reste du cache, en passant en zoom 14 il n'y a plus rien, je suppose donc que c'est propre. Comme il y a un problème sur l'affichage de communes dans le même coin (communes rouge-sang) : Comme dirait coluche : il est fort au ballons, y'avait des couleurs même pas marquées dans le manuel Je pense qu'il s'agit de plusieurs couches de rouge qui se superposent, donc plusieurs communes qui s'entrecroisent. Soit c'est normal parce qu'il y a des enclaves/exclaves (que mon outils ne gère pas), soit il y a superposition anormal. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes révolutionaires
Un autre donnera peut-être les durées précises pour chaque couleur. Pratique pour voir où ça avance, et où d'autres travaillent pour éviter de se marcher sur les villes ;-) Le code couleur ne donne qu'une très vague idée de l'âge dans la base d'une commune car je n'ai pas réussi à disposer de cette information. Les couleurs changent au fur et à mesure que d'autres relations sont insérées dans la base OSM mondiale. ( Je prend par exemple le paris que juste après l'import de corine, toutes les communes passeront en vert ;-( ) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes révolutionaires
Je vais peut-être dire une bêtise, mais si je prend le fichier correspondant à un changeset que j'ai fait (c'en est un au hasard il n'a rien de particulier), je vois un timestamp sur l'objet relation, on pourrait utiliser ça non ? http://www.openstreetmap.org/api/0.6/changeset/861268/download Yann Le 28 mai 09 à 15:41, sly (sylvain letuffe) a écrit : Un autre donnera peut-être les durées précises pour chaque couleur. Pratique pour voir où ça avance, et où d'autres travaillent pour éviter de se marcher sur les villes ;-) Le code couleur ne donne qu'une très vague idée de l'âge dans la base d'une commune car je n'ai pas réussi à disposer de cette information. Les couleurs changent au fur et à mesure que d'autres relations sont insérées dans la base OSM mondiale. ( Je prend par exemple le paris que juste après l'import de corine, toutes les communes passeront en vert ;-( ) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.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] Communes révolutionaires
On Thursday 28 May 2009 15:46, Yann Coupin wrote: Je vais peut-être dire une bêtise, Non non, tu as bien raison. mais si je prend le fichier correspondant à un changeset que j'ai fait (c'en est un au hasard il n'a rien de particulier), je vois un timestamp sur l'objet relation, on pourrait utiliser ça non ? http://www.openstreetmap.org/api/0.6/changeset/861268/download c'est possible ;-) J'utilise simplement des outils qui ne savent pas faire. (osm2pgsql) Ou, s'ils le font, je ne sais où ils mettent cette information. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes révolutionaires
Bon je confirme ça ne stocke pas le timestamp, mais osm2pgsql a un code simple et je pense que je pourrais faire la modif en une heure, tu veux que j'y jete un coup d'œil ce soir ? Yann Le 28 mai 09 à 15:52, sly (sylvain letuffe) a écrit : J'utilise simplement des outils qui ne savent pas faire. (osm2pgsql) Ou, s'ils le font, je ne sais où ils mettent cette information. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
sly (sylvain letuffe) a écrit : J'aide un peu pieren à avancer, courage on y est presque ;-) ## Rappel : ce fil de discussion aborde les tags à adopter lors de l'intégration des données Corine Land Cover France (CLCF). Voir http://lists.openstreetmap.org/pipermail/talk-fr/2009-May/009395.html pour le début de la discussion. Le document de référence est la page wiki : http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature Aucun fil de discussion n'est clos par le suivant. Tous les commentaires sont les bienvenues et vous pouvez revenir à tout moment sur les plus anciens. ## * 511 (59)Cours et voies d’eau Vu le peu de polygone, et vu leur qualité après quelques repérages, je propose tout simplement de laisser tomber le 511, OSM étant déjà bien plus fourni et précis * 512 (2 373) Plans d’eau Étendues d’eau, naturelles ou artificielles, de plus de 25 hectares. natural=water me va bien, OSM ne faisant pour l'instant pas de distinction naturel/artificiel * 521 (90) Étendues d’eau salée ou saumâtre sans végétation, séparées de la mer OSM ne fait pas de distinction entre les lacs d'eau douce et ce qu'on appellerais nous les étangs salés qu'on retrouve en bord de mer. Donc je propose le même traitement que pour les plan d'eau (soit natural=water) le tag corine étant conservé, il sera possible de garder une trace et de passer à natural=salted_water le jour où ça existera * 522 (30) Estuaires Je propose de ne pas importer * 523 (4) Mers et océans Je suppose que c'est déjà dans OSM, je propose de ne pas importer non plus. +1 pour l'ensemble Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes révolutionaires
On Thursday 28 May 2009 03:41:36 pm sly (sylvain letuffe) wrote: toutes les communes passeront en vert C'est pas grave. Ça fera un chalenge pour remettre plein de rouge :) -- Vincent MEURISSE ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
2009/5/28 sly (sylvain letuffe) sylv...@letuffe.org: J'aide un peu pieren à avancer, courage on y est presque ;-) Il fallait le dire si j'avançais trop lentement ;-) Mais c'est vrai que ça prend du temps sur certaines catégories : il faut bien comprendre ce que veut dire CLC, voir s'il peut y avoir des tags équivalents autres que ceux proposés, examiner la carte en ligne et les photos satellites pour voir à quoi ça correspond dans les faits. Par exemple, pour la 511, il faudrait d'abord regarder s'il n'y a aucun polygone de fleuve qui pourrait nous être utile et si OSM a déjà couvert tous les fleuves et si c'est vraiment plus précis avant de décider d'abandonner cette classe. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bug sur beta ou restes de pâté d ans le Jura ?
j'ai remarqué ca il y a pas longtemps, c'est juste des restes. Sur JOSM, on ne récupère rien... On ne se débarrasse pas si facilement, d'une telle œuvre d'art!!! [?] Je suis en train d'importer les communes du jura, ca corrigera certainement les problèmes... Le 28 mai 2009 15:28, sly (sylvain letuffe) sylv...@letuffe.org a écrit : On Thursday 28 May 2009 15:06, Vincent Pottier wrote: http://beta.letuffe.org/?zoom=13lat=46.86325lon=5.6831layers=B0 Ce sont les restes de pâté du Jura de l'autre week-end ou un bug récent ? Je n'ai pas vu la marmelade annoncé l'autre week-end et qu'il a fallu 'reverter'. Donc je ne sais pas si ça ressemble à ce qu'on voit maintenant. Très joli en tout cas, comme c'est en zoom 13, c'est un reste du cache, en passant en zoom 14 il n'y a plus rien, je suppose donc que c'est propre. Comme il y a un problème sur l'affichage de communes dans le même coin (communes rouge-sang) : Comme dirait coluche : il est fort au ballons, y'avait des couleurs même pas marquées dans le manuel Je pense qu'il s'agit de plusieurs couches de rouge qui se superposent, donc plusieurs communes qui s'entrecroisent. Soit c'est normal parce qu'il y a des enclaves/exclaves (que mon outils ne gère pas), soit il y a superposition anormal. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr 32A.png___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes révolutionaires
On Thursday 28 May 2009 16:14, Yann Coupin wrote: Bon je confirme ça ne stocke pas le timestamp, mais osm2pgsql a un code simple et je pense que je pourrais faire la modif en une heure, tu veux que j'y jete un coup d'œil ce soir ? Ha ben si tu as le courage ! Mais le jeu en vaut il la chandelle ? à toi de voir. L'ajout d'un timestamp unix correspondant à la dernière modification de la relation dans un champ de la table marcherait au poil. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
On Thursday 28 May 2009 16:26, Pieren wrote: 2009/5/28 sly (sylvain letuffe) sylv...@letuffe.org: J'aide un peu pieren à avancer, courage on y est presque ;-) Il fallait le dire si j'avançais trop lentement ;-) Mais c'est vrai que ça prend du temps sur certaines catégories Je tente de filer un coup de main ;-) et c'est clair que ce n'est pas si simple, il faut mener une petite recherche pour ne pas faire que survoler. Par exemple, pour la 511, il faudrait d'abord regarder s'il n'y a aucun polygone de fleuve qui pourrait nous être utile et si OSM a déjà couvert tous les fleuves et si c'est vraiment plus précis avant de décider d'abandonner cette classe. Dans l'absolu, ça vaudrait le coût de se creuser la tête, mais dans le cas français (que nous traitons ici, avant de propager chez les autres qui en feront un peu ce qu'ils veulent) il n'y a que peu de polygones, et mes recherches rhône, Isère, Saône des coins que je connais un peu me montre que OSM est quasiment à chaque fois plus précis. L'importation avec une relation de type riverbank va créer une complexité à l'import pour pas grand chose à mon avis. Reste qu'il n'est pas idiot de proposer un dépot pour tout corine où chacun ira piocher pour faire du manuel. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
Est-ce qu'il va exister un plugin pour télécharger les données corine dans JOSM ? Ou alors va-t-il y avoir un fichier superposable avec les données OSM dans notre éditeur pour rajouter des données qui ne seront pas importées ? Car, autant défois Corine est imprécise sur les forêts autour de chez moi, et qu'il va falloir que j'adapte avec le terrain, autant défois Corine met en avant des plans d'eau qui ne sont pas dans OSM, et les plans cadastraux non encore disponibles. Donc corine reste ma seule source pour rajouter des surfaces en eau (ou alors pour corriger la cadastre, car comme dit dans un autre fil aujourd'hui, les zones bleus sur le cadastre sont défois pas très réelles). --- En date de : Jeu 28.5.09, Pieren pier...@gmail.com a écrit : De: Pieren pier...@gmail.com Objet: Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau À: Discussions sur OSM en français talk-fr@openstreetmap.org Date: Jeudi 28 Mai 2009, 16h26 2009/5/28 sly (sylvain letuffe) sylv...@letuffe.org: J'aide un peu pieren à avancer, courage on y est presque ;-) Il fallait le dire si j'avançais trop lentement ;-) Mais c'est vrai que ça prend du temps sur certaines catégories : il faut bien comprendre ce que veut dire CLC, voir s'il peut y avoir des tags équivalents autres que ceux proposés, examiner la carte en ligne et les photos satellites pour voir à quoi ça correspond dans les faits. Par exemple, pour la 511, il faudrait d'abord regarder s'il n'y a aucun polygone de fleuve qui pourrait nous être utile et si OSM a déjà couvert tous les fleuves et si c'est vraiment plus précis avant de décider d'abandonner cette classe. Pieren ___ 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] Corine Land Cover : nomenclature 5 Surfaces en eau
+1 pour le reste * 522 (30) Estuaires Je propose de ne pas importer Je pense que ca pourrait etre une classe qui pourrait etre utile car c'est generalement typique de certaines zones, mais il doit y avoir peu de polygones. * 523 (4) Mers et océans Je suppose que c'est déjà dans OSM, je propose de ne pas importer non plus. Je ne suis pas sure que ca soit dans OSM. La derniere fois que j'ai lu quelques choses a propos des mers et des oceans c'est qu'ils inversaient les coastlines pour obtenir les mers et les oceans. Si c'est effectivement le cas, ce tag pourrait etre utile. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
sly (sylvain letuffe) a écrit : On Thursday 28 May 2009 16:26, Pieren wrote: 2009/5/28 sly (sylvain letuffe) sylv...@letuffe.org: J'aide un peu pieren à avancer, courage on y est presque ;-) Il fallait le dire si j'avançais trop lentement ;-) Mais c'est vrai que ça prend du temps sur certaines catégories Je tente de filer un coup de main ;-) et c'est clair que ce n'est pas si simple, il faut mener une petite recherche pour ne pas faire que survoler. Il est vrai que les commentaires étaient succincts ;-) Par exemple, pour la 511, il faudrait d'abord regarder s'il n'y a aucun polygone de fleuve qui pourrait nous être utile et si OSM a déjà couvert tous les fleuves et si c'est vraiment plus précis avant de décider d'abandonner cette classe. Dans l'absolu, ça vaudrait le coût de se creuser la tête, mais dans le cas français (que nous traitons ici, avant de propager chez les autres qui en feront un peu ce qu'ils veulent) il n'y a que peu de polygones, et mes recherches rhône, Isère, Saône des coins que je connais un peu me montre que OSM est quasiment à chaque fois plus précis. Pareil pour le Doubs où les étangs sont fondus dans la rivière à Saint-Vit. Et Saint-Jean-de-Losne où CLC a mélangé la Saône, le canal, le port fluvial de plaisance. Sur 59 polygones on n'en aura pas beaucoup de potable (si je puis me permettre) J'ai supposé aussi que la mer, c'était fait de longue date, avec les estuaires. Seul les 512 et 521 semblent intéressant (et assez nombreux pour qu'on se penche sur un import massif). L'importation avec une relation de type riverbank va créer une complexité à l'import pour pas grand chose à mon avis. Reste qu'il n'est pas idiot de proposer un dépot pour tout corine où chacun ira piocher pour faire du manuel. J'ai démarré un proto d'interface, mais la peinture n'est pas seiche. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
Reste qu'il n'est pas idiot de proposer un dépot pour tout corine où chacun ira piocher pour faire du manuel. Bon, tu viens de répondre à ma question dans le mail que je viens d'envoyer. :) Je vote pour. ;-) --- En date de : Jeu 28.5.09, sly (sylvain letuffe) sylv...@letuffe.org a écrit : De: sly (sylvain letuffe) sylv...@letuffe.org Objet: Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau À: Discussions sur OSM en français talk-fr@openstreetmap.org Date: Jeudi 28 Mai 2009, 16h40 On Thursday 28 May 2009 16:26, Pieren wrote: 2009/5/28 sly (sylvain letuffe) sylv...@letuffe.org: J'aide un peu pieren à avancer, courage on y est presque ;-) Il fallait le dire si j'avançais trop lentement ;-) Mais c'est vrai que ça prend du temps sur certaines catégories Je tente de filer un coup de main ;-) et c'est clair que ce n'est pas si simple, il faut mener une petite recherche pour ne pas faire que survoler. Par exemple, pour la 511, il faudrait d'abord regarder s'il n'y a aucun polygone de fleuve qui pourrait nous être utile et si OSM a déjà couvert tous les fleuves et si c'est vraiment plus précis avant de décider d'abandonner cette classe. Dans l'absolu, ça vaudrait le coût de se creuser la tête, mais dans le cas français (que nous traitons ici, avant de propager chez les autres qui en feront un peu ce qu'ils veulent) il n'y a que peu de polygones, et mes recherches rhône, Isère, Saône des coins que je connais un peu me montre que OSM est quasiment à chaque fois plus précis. L'importation avec une relation de type riverbank va créer une complexité à l'import pour pas grand chose à mon avis. Reste qu'il n'est pas idiot de proposer un dépot pour tout corine où chacun ira piocher pour faire du manuel. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.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] Corine Land Cover : nomenclature 5 Surfaces en eau
2009/5/28 Etienne T gustrimai...@yahoo.fr: Est-ce qu'il va exister un plugin pour télécharger les données corine dans JOSM ? Ou alors va-t-il y avoir un fichier superposable avec les données OSM dans notre éditeur pour rajouter des données qui ne seront pas importées ? Car, autant défois Corine est imprécise sur les forêts autour de chez moi, et qu'il va falloir que j'adapte avec le terrain, autant défois Corine met en avant des plans d'eau qui ne sont pas dans OSM, et les plans cadastraux non encore disponibles. Donc corine reste ma seule source pour rajouter des surfaces en eau (ou alors pour corriger la cadastre, car comme dit dans un autre fil aujourd'hui, les zones bleus sur le cadastre sont défois pas très réelles). Dans le cas de Fleury Les Aubrais, j'ai remarque que le cadastre donne de tres bonnes formes pour les plans d'eau artificiels de la ville. J'ai verifie en regardant les photos de Yahoo pour confirmer cela. De plus, ca reste coherent avec ce dont je me rappelle. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Corine Land Cover : nomenclature 5 Surfaces en eau
+1 De : Etienne T gustrimai...@yahoo.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Jeudi, 28 Mai 2009, 16h51mn 50s Objet : Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau Est-ce qu'il va exister un plugin pour télécharger les données corine dans JOSM ? Ou alors va-t-il y avoir un fichier superposable avec les données OSM dans notre éditeur pour rajouter des données qui ne seront pas importées ? Car, autant défois Corine est imprécise sur les forêts autour de chez moi, et qu'il va falloir que j'adapte avec le terrain, autant défois Corine met en avant des plans d'eau qui ne sont pas dans OSM, et les plans cadastraux non encore disponibles. Donc corine reste ma seule source pour rajouter des surfaces en eau (ou alors pour corriger la cadastre, car comme dit dans un autre fil aujourd'hui, les zones bleus sur le cadastre sont défois pas très réelles). --- En date de : Jeu 28.5.09, Pieren pier...@gmail.com a écrit : De: Pieren pier...@gmail.com Objet: Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau À: Discussions sur OSM en français talk-fr@openstreetmap.org Date: Jeudi 28 Mai 2009, 16h26 2009/5/28 sly (sylvain letuffe) sylv...@letuffe.org: J'aide un peu pieren à avancer, courage on y est presque ;-) Il fallait le dire si j'avançais trop lentement ;-) Mais c'est vrai que ça prend du temps sur certaines catégories : il faut bien comprendre ce que veut dire CLC, voir s'il peut y avoir des tags équivalents autres que ceux proposés, examiner la carte en ligne et les photos satellites pour voir à quoi ça correspond dans les faits. Par exemple, pour la 511, il faudrait d'abord regarder s'il n'y a aucun polygone de fleuve qui pourrait nous être utile et si OSM a déjà couvert tous les fleuves et si c'est vraiment plus précis avant de décider d'abandonner cette classe. Pieren ___ 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] Corine Land Cover : nomenclature 5 Surfaces en eau
2009/5/28 Emilie Laffray emilie.laff...@gmail.com: c'est generalement typique de certaines zones, mais il doit y avoir peu de polygones. Il y en a 30 si c'est le chiffre entre parenthèses et s'il est juste ;-) Je ne suis pas sure que ca soit dans OSM. La derniere fois que j'ai lu quelques choses a propos des mers et des oceans c'est qu'ils inversaient les coastlines pour obtenir les mers et les oceans. Si c'est effectivement le cas, ce tag pourrait etre utile. Il y aurait 4 polygones... et c'est les coastlines qui définissent la limite effectivement. Je pense qu'on peut aussi laisser tomber (il y a d'autres sources potentielles et plus intéressantes pour ça) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
Reste qu'il n'est pas idiot de proposer un dépot pour tout corine où chacun ira piocher pour faire du manuel. J'ai démarré un proto d'interface, mais la peinture n'est pas seiche. Previens moi quand tu as besoin d'aide pour produire les fichiers OSM facilement. Je pense qu'il serait plus facile de commencer par des bbox. Ca serait aussi plus facile pour les autres pays de reprendre potentiellement l'interface. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
2009/5/28 sly (sylvain letuffe) sylv...@letuffe.org: Reste qu'il n'est pas idiot de proposer un dépot pour tout corine où chacun ira piocher pour faire du manuel. Facile : un plugin JOSM qui irait chercher tout ou partie des classes CLC (sélectionnable) en vectoriel directement dans une base PostGIS dans les limites de la bbox en cours bien-sûr. Pas de besoin de tracer par dessus. Juste effacer/ajuster les polygones mal placés. Y-a-pu-ka Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ( était Surfaces en eau) - Pr éparation à l'importation (poly en conflict avec osm)
Previens moi quand tu as besoin d'aide pour produire les fichiers OSM facilement. Je pense qu'il serait plus facile de commencer par des bbox. Et que pensez vous de mon idée qui consiste à produire un dépot (contenant les polygones qui ne seront pas importés automatiquement) qui contiendrait un fichier par polygone ? - J'y vois comme avantage une plus grande simplicité à produire - Plus facile à traiter avec JOSM qu'un découpage par département - Plus facile à lister ce qui a été importé de ce qui ne l'a pas été (Restera tout de même une petite interface de sélection pour trouver ceux qui intéressent par zone, mais qui me semble plus simple qu'un découage et génération de fichier osm à la volée ) L'idée bbox avec plugin JOSM peut faire rêver, mais honnêtement, je ne crois pas que nous ayons la ressource pour le mettre en place. KIFS -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bug sur beta ou restes de pâté dans le Jura ?
wouldsmina a écrit : j'ai remarqué ca il y a pas longtemps, c'est juste des restes. Sur JOSM, on ne récupère rien... On ne se débarrasse pas si facilement, d'une telle œuvre d'art!!! Je suis en train d'importer les communes du jura, ca corrigera certainement les problèmes... Pour les ratures violettes : possible. Mais j'ai repéré quelques problèmes dans l'import : Les relations sont présentes quater fois. Ce qui me semble être 3 en trop. On va se retrouver avec 132 000 communes en France. Voir : Le Villey, Sellière et autres... Or ces communes ne sont pas rouge-sang su beta. Il y a un autre problème pour les communes rouge-sang que je n'ai pas encore identifié. Je crois qu'il serait bon de bien repérer ce qui ne va pas, et de réparer pour éviter de reproduire ces erreurs. Bon courage. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
Hum, j'avoue que je ne saurais pas par ou commencer pour creer un plugin JOSM. Que fait on vis a vis des polygones dont les ways ont plus de 2000 points? Emilie Laffray 2009/5/28 Pieren pier...@gmail.com: 2009/5/28 sly (sylvain letuffe) sylv...@letuffe.org: Reste qu'il n'est pas idiot de proposer un dépot pour tout corine où chacun ira piocher pour faire du manuel. Facile : un plugin JOSM qui irait chercher tout ou partie des classes CLC (sélectionnable) en vectoriel directement dans une base PostGIS dans les limites de la bbox en cours bien-sûr. Pas de besoin de tracer par dessus. Juste effacer/ajuster les polygones mal placés. Y-a-pu-ka Pieren ___ 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] Bug sur beta ou restes de pâté dans le Jura ?
Les relations sont présentes quater fois. Ce qui me semble être 3 en trop. On va se retrouver avec 132 000 communes en France. Voir : Le Villey, Sellière et autres... Or ces communes ne sont pas rouge-sang su beta. Il y a un autre problème pour les communes rouge-sang que je n'ai pas encore identifié. Je dirais pas Or, je dirais donc. Si il y a 4 communes ayant la même surface, alors ça fait 4 couches de rouge ;-) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
Emilie Laffray a écrit : Reste qu'il n'est pas idiot de proposer un dépot pour tout corine où chacun ira piocher pour faire du manuel. J'ai démarré un proto d'interface, mais la peinture n'est pas seiche. Previens moi quand tu as besoin d'aide pour produire les fichiers OSM facilement. Je pense qu'il serait plus facile de commencer par des bbox. Ca serait aussi plus facile pour les autres pays de reprendre potentiellement l'interface. Emilie Laffray Je suis bien incapable de faire tourner osmosis. J'ai bien un petit bout de serveur mutualisé, mais il ne connaît que le php (ça tombe bien moi aussi). Je peux bien essayer de traiter de l'xml avec du php pour faire des extraits à partir des fichiers que tu produits. Mais ça suppose que j'écrive le script complet. Pas d'appel de programme externe. Il faudrait alors renommer les fichiers en fonction de la classe clc et de l'overlap. Mais c'est peut-être plus malin d'utiliser osmosis. Voila, brut de décoffrage, la GUI. Pour l'instant, il n'y a rien derrière. Attention à la peinture. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ( était Surfaces en eau) - Pr éparation à l'importation (poly en conflict avec osm)
2009/5/28 sly (sylvain letuffe) sylv...@letuffe.org: L'idée bbox avec plugin JOSM peut faire rêver, mais honnêtement, je ne crois pas que nous ayons la ressource pour le mettre en place. Il suffirait peut-être juste d'adapter le plugin WMS pour qu'il fonctionne avec celui de l'ifen. Je l'ai déjà fait avec le cadastre, alors il n'y a rien d'insurmontable... Après, ça dépend aussi du format des données qu'on récupère. Quelqu'un a déjà réussi à utiliser le WMS de l'Ifen ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ( était Surfaces en eau) - Pr éparation à l'importation (poly en conflict avec osm)
Hum, j'ai une dedibox que j'utilise peu. Il faut d'ailleurs que je la mettre a jour avec une nouvelle distribution. Elle pourrait facilement contenir une petite base de donnee Postgis pour servir des polygones. Je ne sais pas comment la forme doit etre; la seule chose que je sais c'est que je ne veux pas exposer la bdd directement :) Je pense qu'il serait assez facile de creer un script PHP (name your favorite poison) permettant de generer un fichier OSM pour chaque polygone on the fly. La requete SQL serait assez rapide. La taille de la bd est petite et donc une bbox serait tres rapide. Pour la generation du fichier OSM, je n'ai pas idee du cout. La solution d'avoir un fichier par polygone me parait effrayante de devoir gerer autant de fichiers. Il faut bien soir voir la taille du depot mais on parle en millier de polygones. L'autre solution qui a ete aborde est d'utiliser Osmosis pour creer le fichier OSM a la volee mais je ne suis pas convaincue que ca soit viable en terme de ressources. Emilie Laffray 2009/5/28 sly (sylvain letuffe) sylv...@letuffe.org: Previens moi quand tu as besoin d'aide pour produire les fichiers OSM facilement. Je pense qu'il serait plus facile de commencer par des bbox. Et que pensez vous de mon idée qui consiste à produire un dépot (contenant les polygones qui ne seront pas importés automatiquement) qui contiendrait un fichier par polygone ? - J'y vois comme avantage une plus grande simplicité à produire - Plus facile à traiter avec JOSM qu'un découpage par département - Plus facile à lister ce qui a été importé de ce qui ne l'a pas été (Restera tout de même une petite interface de sélection pour trouver ceux qui intéressent par zone, mais qui me semble plus simple qu'un découage et génération de fichier osm à la volée ) L'idée bbox avec plugin JOSM peut faire rêver, mais honnêtement, je ne crois pas que nous ayons la ressource pour le mettre en place. KIFS -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.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] Bug sur beta ou restes de pâté d ans le Jura ?
sly (sylvain letuffe) a écrit : Les relations sont présentes quater fois. Ce qui me semble être 3 en trop. On va se retrouver avec 132 000 communes en France. Voir : Le Villey, Sellière et autres... Or ces communes ne sont pas rouge-sang su beta. Il y a un autre problème pour les communes rouge-sang que je n'ai pas encore identifié. Je dirais pas Or, je dirais donc. Si il y a 4 communes ayant la même surface, alors ça fait 4 couches de rouge ;-) Exemple : http://beta.letuffe.org/?zoom=13lat=46.78451lon=5.55025layers=B0FFTF Arlay : quatre relations correctes : 147597, 147696, 147799, 147909 rose sur beta Mantry : quatre relations correctes : 147586, 147685, 147788, 147898 rouge sang sur beta Why ? Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Pbs d'accès au site
Bonsoir, depuis qq jours j'ai de très grandes difficultés à accéder au site www.openstreetmap.org. Le chargement des cartes est d'une lenteur désespérante (quand il a lieu) et je suis obligé de bricoler à plusieurs reprises la sélection du moteur de rendu pour finir à visionner la carte. Et, à chaque nouveau zoom, ça recommence :( Il n'est pas rare que l'affichage de la carte initiale prenne plus de 15 minutes ! Dans bien des cas, il n'apparaît que le More OSM soon. Je précise que ce symptôme se produit sous Mandriva 2009.1 / firefox 3 en wifi et sous windows XP / firefox 2 en ethernet. Le ping est souvent hors délais. Naturellement, aucun changement récent de la config de ces machines. J'ai essayé de modifier les DNS automatiques du FAI pour ceux d'OpenDNS, sans succès. Très subjectivement, je daterais ce phénomène de l'arrivée de Potlatch 1.0. Mais c'est vraiment à vue de nez. Avez-vous ce pb ? Des suggestions ? -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bug sur beta ou restes de pâté d ans le Jura ?
Arlay : quatre relations correctes : 147597, 147696, 147799, 147909 rose sur beta Mantry : quatre relations correctes : 147586, 147685, 147788, 147898 rouge sang sur beta Why ? Aucune idée, 3 des 4 Arlay n'ont pas été importé. Yaka nettoyer on y verra plus clair. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Pbs d'accès au site
Il y avait un article sur slashdot hier parlant d'osm. Je ne sais pas si ça a quoi que ce soit à voir, mais à part ça je n'ai pas d'idée... Yann Le 28 mai 09 à 18:06, Jean-Francois Nifenecker a écrit : Bonsoir, depuis qq jours j'ai de très grandes difficultés à accéder au site www.openstreetmap.org. Le chargement des cartes est d'une lenteur désespérante (quand il a lieu) et je suis obligé de bricoler à plusieurs reprises la sélection du moteur de rendu pour finir à visionner la carte. Et, à chaque nouveau zoom, ça recommence :( Il n'est pas rare que l'affichage de la carte initiale prenne plus de 15 minutes ! Dans bien des cas, il n'apparaît que le More OSM soon. Je précise que ce symptôme se produit sous Mandriva 2009.1 / firefox 3 en wifi et sous windows XP / firefox 2 en ethernet. Le ping est souvent hors délais. Naturellement, aucun changement récent de la config de ces machines. J'ai essayé de modifier les DNS automatiques du FAI pour ceux d'OpenDNS, sans succès. Très subjectivement, je daterais ce phénomène de l'arrivée de Potlatch 1.0. Mais c'est vraiment à vue de nez. Avez-vous ce pb ? Des suggestions ? -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Pbs d'accès au site
aucun soucis pour ma part... De : Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Jeudi, 28 Mai 2009, 18h06mn 12s Objet : [OSM-talk-fr] Pbs d'accès au site Bonsoir, depuis qq jours j'ai de très grandes difficultés à accéder au site www.openstreetmap.org. Le chargement des cartes est d'une lenteur désespérante (quand il a lieu) et je suis obligé de bricoler à plusieurs reprises la sélection du moteur de rendu pour finir à visionner la carte. Et, à chaque nouveau zoom, ça recommence :( Il n'est pas rare que l'affichage de la carte initiale prenne plus de 15 minutes ! Dans bien des cas, il n'apparaît que le More OSM soon. Je précise que ce symptôme se produit sous Mandriva 2009.1 / firefox 3 en wifi et sous windows XP / firefox 2 en ethernet. Le ping est souvent hors délais. Naturellement, aucun changement récent de la config de ces machines. J'ai essayé de modifier les DNS automatiques du FAI pour ceux d'OpenDNS, sans succès. Très subjectivement, je daterais ce phénomène de l'arrivée de Potlatch 1.0. Mais c'est vraiment à vue de nez. Avez-vous ce pb ? Des suggestions ? -- Jean-Francois Nifenecker, Bordeaux ___ 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] Pbs d'accès au site
2009/5/28 Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net: Avez-vous ce pb ? non ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ( était Surfaces en eau) - Pr éparation à l'importation (poly en conflict avec osm)
2009/5/28 sly (sylvain letuffe) sylv...@letuffe.org: Il faut aussi voir comment on fait pour savoir quelles zones ont été traitée et lesquelles restent à faire. C'est l'avantage avec la méthode par département comme pour les limites communales. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ( était Surfaces en eau) - Pr éparation à l'importation (poly en conflict avec o sm)
Pour ca, il faut juste tenir une base de donnee pour savoir ou se trouve chaque polygone. Cela implique de maintenir une petite base de donnee (postgis de preference) pour servir les bons fichiers. L'autre solution est d'utiliser dans le nom de fichier les informations comme le departement et sa bbox. Ca pourrait etre un moyen aussi. Emilie Laffray Pieren wrote: 2009/5/28 sly (sylvain letuffe) sylv...@letuffe.org: Il faut aussi voir comment on fait pour savoir quelles zones ont été traitée et lesquelles restent à faire. C'est l'avantage avec la méthode par département comme pour les limites communales. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Pbs d'accès au site
THEVENON Julien wrote: aucun soucis pour ma part... ditto et je passe pas mal de temps sur le site. Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Corine Land Cover : nomenclature 3 3 Espaces ouverts, sans ou avec peu de vég étation
Rappel : ce fil de discussion aborde les tags à adopter lors de l'intégration des données Corine Land Cover France (CLCF). Voir http://lists.openstreetmap.org/pipermail/talk-fr/2009-May/009395.html pour le début de la discussion. Le document de référence est la page wiki : http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature Aucun fil de discussion n'est clos par le suivant. Tous les commentaires sont les bienvenues et vous pouvez revenir à tout moment sur les plus anciens. Une catégorie avec 5 classes mais étonnamment faiblement représentées en nombre de polygones. * la classe 331 Plages, dunes et sable serait traduite en natural=beach . Pas d'objection bien que ces polygones soient assez mal délimités et débordent souvent sur des quais ou des zones urbaines souvent adjacentes. La description du tag (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dbeach) propose d'ajouter un tag surface mais ça devra être fait à la main. * la classe 332 Roches nues est proposée en natural=cliff (falaises) ou natural=scree (caillasse) sur le wiki. En fait, c'est tous les endroits où la roche est à nue. J'aurais tendance à dire que là où il n'y a rien, on ne met rien d'autant plus que cela concerne un faible nombre de polygones (~1300). Mais j'entends déjà les randonneurs et grimpeurs qui vont râler. Donc à eux de s'exprimer ici. * la classe 333 Végétation clairsemée est proposée en natural=scrub comme la classe 323 mais sur les photos, c'est très proche du type de terrain 332 Roches nues mais avec un peu de végétation parmi les rochers. Donc si on adopte la classe 332, je serais plutôt pour choisir le même tag ici (natural=scree par exemple) * 64 polygones sont de la classes 334 Zones incendiées. Je n'ai pas trouvé de proposition sur ce sujet brûlant. Ça serait pourtant intéressant de recouper les zones incendiées transformées en zones urbaines et les noms des promoteurs immobiliers concernés. * 144 polygones pour la classe 335 Glaciers et neiges éternelles qui seraient tagués en natural=glacier (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dglacier) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ( était Surfaces en eau) - Pr éparation à l'importation (poly en conflict avec osm)
2009/5/28 Emilie Laffray emilie.laff...@gmail.com: Pour ca, il faut juste tenir une base de donnee pour savoir ou se trouve chaque polygone. Cela implique de maintenir une petite base de donnee (postgis de preference) pour servir les bons fichiers. L'autre solution est d'utiliser dans le nom de fichier les informations comme le departement et sa bbox. Ca pourrait etre un moyen aussi. Emilie Laffray Je ne comprend pas. Comment feras-tu pour savoir si quelqu'un a comparé les polygones en overlap avec la base OSM et s'il aura ajusté les données OSM ou adopté les données CLC ou décidé qu'il fallait mettre autre chose de plus pertinent ? Comment faire pour éviter de passer sur des zones en overlap déjà examinées par d'autres ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ( était Surfaces en eau) - Pr éparation à l'importation (poly en conflict avec o sm)
Je pensais que la base de donnee pourrait servir a indiquer le polygone a telecharger si tu fais une requete. Peut etre faudrait il sur la page dire que l'on a telecharge tel ou tel polygone afin de s'en servir. Une fois qu'on s'en serait servi, il faudrait revenir sur le site pour donner le status. J'avoue avoir plus pense au mechanisme de distribution du fichier plutot que de savoir qui a fait quoi avec le polygone. Emilie Laffray Pieren wrote: comparé les polygones en overlap avec la base OSM et s'il aura ajusté les données OSM ou adopté les données CLC ou décidé qu'il fallait mettre autre chose de plus pertinent ? Comment faire pour éviter de passer sur des zones en overlap déjà examinées par d'autres ? Pieren signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Corine Land Cover : nomenclature 4 1 Zones humides intérieures
Rappel : ce fil de discussion aborde les tags à adopter lors de l'intégration des données Corine Land Cover France (CLCF). Voir http://lists.openstreetmap.org/pipermail/talk-fr/2009-May/009395.html pour le début de la discussion. Le document de référence est la page wiki : http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature Aucun fil de discussion n'est clos par le suivant. Tous les commentaires sont les bienvenues et vous pouvez revenir à tout moment sur les plus anciens. Deux classes très faiblement présentent composent cette catégorie qui a un tag sur le wiki qui correspond assez bien (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwetland). * la classe 411 Marais intérieurs est titrée Inland marshes dans la nomenclature CLC en anglais. Le wiki propose natural=wetland + wetland=marsh. * la classe 412 Tourbières (Peat bogs) serait traduite en natural=wetland + wetland=bog Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bug sur beta ou restes de pâté d ans le Jura ?
Punaise!! j'avais pas vue ça!!! Pourtant j'ai pas eu d'erreur à l'import!! Je suis maudit... c'est sur ce changeset que le probleme est arrivée: http://www.openstreetmap.org/browse/changeset/1325953?relation_page=6 Le 28 mai 2009 18:07, sly (sylvain letuffe) sylv...@letuffe.org a écrit : Arlay : quatre relations correctes : 147597, 147696, 147799, 147909 rose sur beta Mantry : quatre relations correctes : 147586, 147685, 147788, 147898 rouge sang sur beta Why ? Aucune idée, 3 des 4 Arlay n'ont pas été importé. Yaka nettoyer on y verra plus clair. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.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
[OSM-talk-fr] Corine Land Cover : nomenclature 42 Zones humides maritimes
Rappel : ce fil de discussion aborde les tags à adopter lors de l'intégration des données Corine Land Cover France (CLCF). Voir http://lists.openstreetmap.org/pipermail/talk-fr/2009-May/009395.html pour le début de la discussion. Le document de référence est la page wiki : http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature Aucun fil de discussion n'est clos par le suivant. Tous les commentaires sont les bienvenues et vous pouvez revenir à tout moment sur les plus anciens. Dernier message sur cette catégorie elle aussi faiblement représentée. * la classe 421 Marais maritimes serait traduit en natural=wetland + wetland=saltmarsh * 33 polygones pour 422 Marais salants et convertis en landuse=salt_pond, un tag que Sly pousse sur la ML anglaise pour l'officialiser. * la classe 423 Zones intertidales correspond à des Étendues de vase, de sable ou de rochers généralement sans végétation, comprises entre le niveau des hautes et des basses eaux.. Bref tout ce qu'on adore traverser avant d'atteindre la plage. Pas d'équivalent dans OSM. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
Emilie Laffray a écrit : Hum, j'avoue que je ne saurais pas par ou commencer pour creer un plugin JOSM. Que fait on vis a vis des polygones dont les ways ont plus de 2000 points? Emilie Laffray Combien sont-ils ? Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 4 1 Zones humides intérieures
Pieren a écrit : Rappel : ce fil de discussion aborde les tags à adopter lors de l'intégration des données Corine Land Cover France (CLCF). Voir http://lists.openstreetmap.org/pipermail/talk-fr/2009-May/009395.html pour le début de la discussion. Le document de référence est la page wiki : http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature Aucun fil de discussion n'est clos par le suivant. Tous les commentaires sont les bienvenues et vous pouvez revenir à tout moment sur les plus anciens. Deux classes très faiblement présentent composent cette catégorie qui a un tag sur le wiki qui correspond assez bien (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwetland). * la classe 411 Marais intérieurs est titrée Inland marshes dans la nomenclature CLC en anglais. Le wiki propose natural=wetland + wetland=marsh. * la classe 412 Tourbières (Peat bogs) serait traduite en natural=wetland + wetland=bog Pieren Ok pour moi. Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 3 3 Espaces ouverts, sans ou avec peu de végétation
Pieren a écrit : * la classe 332 Roches nues est proposée en natural=cliff (falaises) ou natural=scree (caillasse) sur le wiki. En fait, c'est tous les endroits où la roche est à nue. J'aurais tendance à dire que là où il n'y a rien, on ne met rien d'autant plus que cela concerne un faible nombre de polygones (~1300). Mais j'entends déjà les randonneurs et grimpeurs qui vont râler. Donc à eux de s'exprimer ici. En tant que randonneur, je suis d'accord avec le « là où il n'y a rien, on ne met rien » * la classe 333 Végétation clairsemée est proposée en natural=scrub comme la classe 323 mais sur les photos, c'est très proche du type de terrain 332 Roches nues mais avec un peu de végétation parmi les rochers. Donc si on adopte la classe 332, je serais plutôt pour choisir le même tag ici (natural=scree par exemple) Ou donc ne rien mettre... * 144 polygones pour la classe 335 Glaciers et neiges éternelles qui seraient tagués en natural=glacier (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dglacier) Quand on regarde par exemple le massif du Mont-Blanc dans OSM où on a déjà les glaciers vs Corine, c'est pas tout à fait la même chose... Neiges éternelles glaciers ? A+ Didier (Zedh dans OSM) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 42 Zones humides maritimes
Pieren a écrit : Rappel : ce fil de discussion aborde les tags à adopter lors de l'intégration des données Corine Land Cover France (CLCF). Voir http://lists.openstreetmap.org/pipermail/talk-fr/2009-May/009395.html pour le début de la discussion. Le document de référence est la page wiki : http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Nomenclature Aucun fil de discussion n'est clos par le suivant. Tous les commentaires sont les bienvenues et vous pouvez revenir à tout moment sur les plus anciens. Dernier message sur cette catégorie elle aussi faiblement représentée. * la classe 421 Marais maritimes serait traduit en natural=wetland + wetland=saltmarsh +1 * 33 polygones pour 422 Marais salants et convertis en landuse=salt_pond, un tag que Sly pousse sur la ML anglaise pour l'officialiser. +1 * la classe 423 Zones intertidales correspond à des Étendues de vase, de sable ou de rochers généralement sans végétation, comprises entre le niveau des hautes et des basses eaux.. Bref tout ce qu'on adore traverser avant d'atteindre la plage. Pas d'équivalent dans OSM. C'est à cheval sur la coastline, théoriquement. C'est la baie du mont Saint-Michel... http://www.openstreetmap.org/?lat=48.63253lon=-1.50852zoom=16layers=B000FTF C'est sûr que ce serait intéressant de reprendre au moins la partie haute côté 'terre' de la coastline. A la mano, parce qu'il y a de la découpe Mais quel tag : ntarual=* ? Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 2 4 Zones agricoles hétérogènes
2009/5/26 Vincent Pottier vpott...@gmail.com: Je serais partisan d'abandonner toute la catégorie 24. Ces polygones ne représentent pas soit farm, soit meadow, soit forest mais un mélange. Pourquoi créer des polygones qui devront être décomposés et refaits ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes révolutionaires
+--On 28 mai 2009 16:31:50 +0200 sly (sylvain letuffe) sylv...@letuffe.org wrote: | On Thursday 28 May 2009 16:14, Yann Coupin wrote: | Bon je confirme ça ne stocke pas le timestamp, mais osm2pgsql a un | code simple et je pense que je pourrais faire la modif en une heure, | tu veux que j'y jete un coup d'œil ce soir ? | | Ha ben si tu as le courage ! Mais le jeu en vaut il la chandelle ? à toi | de voir. | L'ajout d'un timestamp unix correspondant à la dernière modification de | la relation dans un champ de la table marcherait au poil. Dernière modif ou date d'ajout ? -- Mathieu Arnold ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
Le jeudi 28 mai 2009 21:50, Vincent Pottier a écrit : Emilie Laffray a écrit : Hum, j'avoue que je ne saurais pas par ou commencer pour creer un plugin JOSM. Que fait on vis a vis des polygones dont les ways ont plus de 2000 points? Emilie Laffray Combien sont-ils ? Pas mal, (je compte 551) mon avis idéaliste dirait : découpons les en relations. Mais est-ce simple ? est-ce réalisable ? si oui, alors plus de 2000 ou moins de 2000 point je ne vois pas de raison de les traiter différemment = importons les -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 2 4 Zones agricoles hétérogènes
Le jeudi 28 mai 2009 22:17, Pieren a écrit : 2009/5/26 Vincent Pottier vpott...@gmail.com: Je serais partisan d'abandonner toute la catégorie 24. Ces polygones ne représentent pas soit farm, soit meadow, soit forest mais un mélange. Pourquoi créer des polygones qui devront être décomposés et refaits ? Un bazar reste un bazar, on pourrait refaire un : landuse=farm;meadow;forest note=on ne sait pas ce que c'est mais autant ne pas avoir dans osm de truc de ce type qui vont rester la vie des rats. Pour ne rien importer donc. -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 3 3 Espaces ouverts, sans ou avec peu de végétation
Didier HALATRE a écrit : Pieren a écrit : * la classe 332 Roches nues est proposée en natural=cliff (falaises) ou natural=scree (caillasse) sur le wiki. En fait, c'est tous les endroits où la roche est à nue. J'aurais tendance à dire que là où il n'y a rien, on ne met rien d'autant plus que cela concerne un faible nombre de polygones (~1300). Mais j'entends déjà les randonneurs et grimpeurs qui vont râler. Donc à eux de s'exprimer ici. En tant que randonneur, je suis d'accord avec le « là où il n'y a rien, on ne met rien » Rien, c'est pas rien disait quelqu'un. Il n'y a pas de valeur natural=nothing Rien, c'est un trou, une crevasse, la falaise au bout du monde ? Alors tag map=end Rien, c'est pas de végétation : du sable, de la roche, du caillou ? Rien, c'est le revêtement par défaut, le paysage naturel ? voir : http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Grassland Ceci dit, je ne sais pas quoi mettre. Il y a encore des choses à inventer sur OSM... Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 42 Zones humides maritimes
* la classe 421 Marais maritimes serait traduit en natural=wetland + wetland=saltmarsh * 33 polygones pour 422 Marais salants et convertis en landuse=salt_pond, un tag que Sly pousse sur la ML anglaise pour l'officialiser. ok * la classe 423 Zones intertidales correspond à des Étendues de vase, de sable ou de rochers généralement sans végétation, comprises entre le niveau des hautes et des basses eaux.. Bref tout ce qu'on adore traverser avant d'atteindre la plage. Pas d'équivalent dans OSM. Heu... il n'y a pas de proposition pour le tager. Mais d'après : http://wiki.openstreetmap.org/wiki/Tag:natural=coastline, la ligne de côte doit refléter le niveau haut de la marrée. intertidales venant de l'anglais entre les marées cette zone ne me semble pas intéressante à importer puisque logiquement dans l'eau (selon le wiki osm) -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération
Bonsoir à tous, Merci pour vos réponses. J'aurais du répondre plut tot car il y a maintenant des tonnes de choses à dire ;) Je vais donc vous citer un peu tous dans le désordre. Je viens de créer la page 'Toulouse' : http://wiki.openstreetmap.org/wiki/Toulouse Vous pouvez l'éditer, la modifier... OK, faisons vivre cette page. Oui, OK pour utiliser ce vecteur pour discuter des implémentations locales des usages globaux... en effet bien mieux que les messages privés. Ca permettra également de garder trace des débats ayant déjà eu lieu pour éventuellement recadrer certaines situations. Cela dit, je doute qu'un utilisateur qui commence son édition par des recolorations de rues existantes (avec une certaine impatience qui s'en dégage) prenne le temps de lire le Wiki avant de poster. La réflexion sur les outils devant inciter au collaboratif est très bonne : on pourrait par exemple créer un tag zone couverte par une page wiki qui ferait alors apparaitre une mise en garde et un lien à tout utilisateur potlatch ou JOSM lorsqu'il se trouve dans le périmètre. Maintenant, il est possible que vos choix correspondent aux règles communes, auquel cas vous pouvez avoir affaire à un débutant qui n'a pas saisi la portée de ses modifications. Ce n'est pas si simple : les règles dites communes ne sont pas claires au point d'être applicables par un robot (loin de la). Il est dit à plusieurs endroits que tout doit s'adapter au terrain et aux modifications récentes comme la modification de plans de circulation par exemple. En plus de ça toute règle génère des exceptions. Donc si on reprend l'exemple de la N 224, elle a été récemment qualifiée en route nationale pour des raisons liées au transport des pièces de l'A380. Il s'agit en fait des tronçons de voirie publique réquisitionnés pour former l'itinéraire d'acheminement. Donc des tronçons par ci par là sont N 224, dont de très très très petites routes de campagne. Pour le choix secondary / tertiary / unclassified c'est encore pire : il y a des quartiers ou toutes les voiries ont la même largeur, ou encore de vieilles départementales charcutées en multiples impasses au gré de l'évolution de l'urbanisme, mais qui gardent leur statut départemental... Ou encore des voies où les municipalités font tout ce qu'ils peuvent pour éjecter le trafic de transit alors que les rues sont larges et départementales. La liste est longue. Donc je dirais que l'on implémente en local des principes généraux et il est clair qu'il faut se concerter avant de faire des choix. Ca ne peut et ne pourra jamais relever de la volonté d'un seul contributeur, d'autant plus que l'on parle du réseau routier structurant, la colonne vertébrale de la carte de la voirie. est ce que tu as essaye de contacter les auteurs des modifications pour en parler avec eux ? meme si j en conviens la logique voudrait que se soient eux qui contactent avant de tout casser Oui mais c'est trop chronophage pour être un fonctionnement normal, et puis si la personne en face est un peu rigide c'est encore pire... Je me vois mal passer tous mes dimanches à faire la police (je n'en aurais de toute façon pas la légitimité), et je me vois encore plus mal expliquer à des futurs contributeurs officiels qu'ils devront mettre au budget un poste à plein temps pour vérifier que Joe the mapper n'est pas en train de repeindre le quartier en rouge ;) Allons au bout de la question : La base OSM peut-elle servir à quelquechose d'autre que de la remplir ? Actuellement, les moteurs de routages servent à vérifier qu'ils savent retrouver, dans OSM, le chemin qu'on connait dans la réalité, plus qu'à guider le voyageur qui ne connait pas le terrain. /// OSM sera-t-elle LA base de données référentielle citoyenne ? Merci pour cette formulation ! Dans l'expression proposée, le mot référentiel est la clé de la discussion : Si OSM sur certains territoires aspire à le devenir, comment le faire sans règles de gestion ? OSM est basé sur le même principe que wikipedia et consort. Et comme dans wikipedia, il peut y avoir du vandalisme ou des erreurs de débutants. Mais le fondement de ce genre de projet est basé sur la confiance que l'on met dans la masse des contributeurs, qui dans l'ensemble fait évoluer le projet dans le bon sens et corrige ses erreurs. Je trouve que l'analogie avec Wikipedia et son autorégulation n'est pas forcément adéquate : la subjectivité est l'essence même de l'encyclopédie, où la notion de vérité n'existe pas ou bien correspond à une espèce de compromis instable et subtil ;) Sur OSM les rues médiévales d'un centre ville ne bougent pas depuis des siècles. Une fois que la communauté aurait validé un georéférencement pour celles-ci, quel intérêt d'en permettre la modification à un contributeur lambda quasi anonyme, face au risque de ne jamais pouvoir atteindre ce stade de base référentielle ? Et on ne parle pas encore de vandalisme délibéré... (à prévoir) Mais la réponse peut aussi être non, OSM
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 42 Zones humides maritimes
Mais d'après : http://wiki.openstreetmap.org/wiki/Tag:natural=coastline, la ligne de côte doit refléter le niveau haut de la marrée. intertidales venant de l'anglais entre les marées cette zone ne me semble pas intéressante à importer puisque logiquement dans l'eau (selon le wiki osm) On devrait toujours continuer à lire les liens qu'on envoi, il y a cette proposition : http://wiki.openstreetmap.org/wiki/Proposed_features/Water_cover water=tidal -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 5 Surfaces en eau
Je verrais pour obtenir ce nombre ce week end. Je serais au London hack week end dans les bureaux de Cloudmade a Londres, donc je risque d'etre occupee. Emilie Laffray Pieren wrote: 2009/5/28 sylvain letuffe sylv...@letuffe.org: Le jeudi 28 mai 2009 21:50, Vincent Pottier a écrit : Emilie Laffray a écrit : Hum, j'avoue que je ne saurais pas par ou commencer pour creer un plugin JOSM. Que fait on vis a vis des polygones dont les ways ont plus de 2000 points? Emilie Laffray Combien sont-ils ? Pas mal, (je compte 551) mon avis idéaliste dirait : découpons les en relations. Mais est-ce simple ? est-ce réalisable ? si oui, alors plus de 2000 ou moins de 2000 point je ne vois pas de raison de les traiter différemment = importons les Sur les 550, combien sont dans les overlap ? Si on parle d'un plugin dans JOSM, on peut faire ça à la mano et créer la relation multipolygone soi-même. S'il y en a 5 par département... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 2 4 Zones agricoles hétérogènes
Pieren a écrit : 2009/5/26 Vincent Pottier vpott...@gmail.com: Je serais partisan d'abandonner toute la catégorie 24. Ces polygones ne représentent pas soit farm, soit meadow, soit forest mais un mélange. Pourquoi créer des polygones qui devront être décomposés et refaits ? Pieren Pour le 241 (pas d'occurrences) et 244 (2 polygones), pas de regrets. Pour le 243, c'est ce que j'ai sous mes fenêtres : c'est compliqué, même sur place... C'est sur que le polygone n'aide pas beaucoup... Et bien on va regretter que CLC ne soit pas plus fin. L'équivalent des 66 194 polygones qu'il faudra se taper à la main après 36 000 communes... Mais, consolons-nous, en France on a le cadastre qui aide à repérer les parcelles : 'ça c'est en herbe, ça en bois, ça c'est en blé' Nos voisins, eux... Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 3 3 Espaces ouverts, sans ou avec peu de vég étation
2009/5/28 Vincent Pottier vpott...@gmail.com: Rien, c'est pas de végétation : du sable, de la roche, du caillou ? Voila, c'est ça. Mais des cailloux, il peut y en avoir des gros, des petits, des moyens. Ça peut être plat, ça peut être un mur. Il n'y a aucune végétation en 332 et quelques végétaux en 333. Maintenant, un géologue pourrait voir une mine d'informations là où nous ne voyons rien. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 3 3 Espaces ouverts, sans ou avec peu de végétation
Bref potentiellement une mine d'or pour des geologues. (oui je sais c'est mauvais) Emilie Laffray Pieren wrote: 2009/5/28 Vincent Pottier vpott...@gmail.com: Rien, c'est pas de végétation : du sable, de la roche, du caillou ? Voila, c'est ça. Mais des cailloux, il peut y en avoir des gros, des petits, des moyens. Ça peut être plat, ça peut être un mur. Il n'y a aucune végétation en 332 et quelques végétaux en 333. Maintenant, un géologue pourrait voir une mine d'informations là où nous ne voyons rien. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 42 Zones humides maritimes
sylvain letuffe a écrit : Heu... il n'y a pas de proposition pour le tager. Mais d'après : http://wiki.openstreetmap.org/wiki/Tag:natural=coastline, la ligne de côte doit refléter le niveau haut de la marrée. Je crois que ça n'est pas le cas au mont Saint-Michel, seul lieu que j'ai regardé. (ici, il y a longtemps que la mer s'est retirée) La coastline serait à corriger dans la baie. intertidales venant de l'anglais entre les marées cette zone ne me semble pas intéressante à importer puisque logiquement dans l'eau (selon le wiki osm) -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cohérence des voiries, mises à jour / modération
2009/5/28 Hugues Romain (RCS) hrom...@reseaux-conseil.com: Quelques petites réflexions qui, j'espère, feront avancer le débat: Cela dit, je doute qu'un utilisateur qui commence son édition par des recolorations de rues existantes (avec une certaine impatience qui s'en dégage) prenne le temps de lire le Wiki avant de poster. La réflexion sur les outils devant inciter au collaboratif est très bonne : on pourrait par exemple créer un tag zone couverte par une page wiki qui ferait alors apparaitre une mise en garde et un lien à tout utilisateur potlatch ou JOSM lorsqu'il se trouve dans le périmètre. Hum, idée originale mais il y aura toujours des gens qui voudront mettre leur petite contribution sans vouloir lire aucune doc. Je pense que plus la zone est dense en données OSM, plus les gens font attention ou passent leur tour (pour ceux de bonne foi). Pour le choix secondary / tertiary / unclassified c'est encore pire : il y a des quartiers ou toutes les voiries ont la même largeur, ou encore de vieilles départementales charcutées en multiples impasses au gré de l'évolution de l'urbanisme, mais qui gardent leur statut départemental... Oui, je suis bien placé pour savoir à quel point il est difficile de décrire la classification des highways en France. Il y a aussi une certaine part de subjectivité dans cette classification. Mettez dix personnes sur une grosse agglomération et vous aurez dix versions, même avec des contributeurs expérimentés. Oui mais c'est trop chronophage pour être un fonctionnement normal, et puis si la personne en face est un peu rigide c'est encore pire... Je me vois mal passer tous mes dimanches à faire la police (je n'en aurais de toute façon pas la légitimité), et je me vois encore plus mal expliquer à des futurs contributeurs officiels qu'ils devront mettre au budget un poste à plein temps pour vérifier que Joe the mapper n'est pas en train de repeindre le quartier en rouge ;) J'ai du mal à saisir votre démarche. Vous voulez un système ouvert mais pas de Joe the mapper. Ou si je comprend, des contributeurs consciencieux et formés comme vous et surtout bénévoles. Sur OSM les rues médiévales d'un centre ville ne bougent pas depuis des siècles. Une fois que la communauté aurait validé un georéférencement pour celles-ci, quel intérêt d'en permettre la modification à un contributeur lambda quasi anonyme, face au risque de ne jamais pouvoir atteindre ce stade de base référentielle ? Je confirme qu'une rue médiévale change rarement de position. Mais elle peut passer en rue piétonne ou en sens unique, une secondary devenir une tertiary, etc... toutes ces choses que les fournisseurs de données ont tant de mal à maintenir à jour. C'est exactement ce qu'on étudie pour Toulouse, mais au stade actuel il est clair qu'ils ne se lanceront pas dans l'aventure s'ils n'arrivent pas à borner le volume de travail qui sera déjà conséquent rien qu'à gérer les effets de bord des mises à jour utiles et les erreurs inévitables (ex changement d'ID d'un objet, relation mal conservée, etc.) Des choses que l'on peut surveiller avec certains outils intelligents (changements de position sans incidence grave, re-création d'objets avec nouvel ID mais avec les mêmes tags ou similaires, signalement sur les changements importants non corrigés dans un délai raisonnable, analyses statistiques, etc.). Si on leur dit qu'ils devront aussi passer du temps à filtrer Joe the mapper qui a envie de peindre la ville en tertiary... ils ne viendront pas car ce sera trop cher au vu des avantages comparé à rester sur du Navteq/Téléatlas. Pour l'instant, la base est en phase de constitution. On peut imaginer que les classements de highways seront beaucoup plus stables avec le temps et que des cartes spécialisées se chargeront de pointer des changements de classification à la communauté qui saura faire la part des choses. Oui, mais en ce cas il est fort à prévoir que le flux sera unidirectionnel. Et OSM y perdrait un potentiel énorme. Ex : si la collectivité veut renseigner les numéros d'adresse à ses frais, elle le fera sur sa base et non sur OSM et donc n'uploadera pas. Non, il y a une troisième voie : elle conserve et entretient sa version de sa base adresse et met à disposition une copie libre. A charge des contributeurs de faire l'import et les mises à jour dans OSM. La communauté urbaine pourra toujours utiliser d'autres données d'OSM et ignorer toutes les modifications de sa base adresse dans OSM si elle pense que sa version est toujours la plus fiable. Oui et donc OSM perdrait de gros volumes de contributions qui demanderait peut être des années de travail à la communauté de bénévoles pour l'obtenir, temps qui pourrait probablement être utilisé pour autre chose ? Sauf si cette administration accepte de libérer ses propres données tout en sachant qu'elle devra conserver le référentiel chez-elle. Elle pourra ensuite profiter en retour des contributions bénévoles mais pas sans un
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 2 4 Zones agricoles hétérogènes
2009/5/28 Vincent Pottier vpott...@gmail.com: Sinon, il reste l'option de créer un nouveau landuse qui décrive ce mélange. Pourquoi se limiter aux tags existants ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 42 Zones humides maritimes
2009/5/28 sylvain letuffe sylv...@letuffe.org: On devrait toujours continuer à lire les liens qu'on envoi, il y a cette proposition : http://wiki.openstreetmap.org/wiki/Proposed_features/Water_cover water=tidal Ah zut, je l'avais oublié celui-là. Bonne pioche. Même si ça n'est pas rendu sur une carte, ça peut être une information intéressante à importer. Je vote pour water=tidal. Pour la surface, il faudra faire une mapping party et visiter les 293 polygones sur place. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 2 4 Zones agricoles hétérogènes
Pieren a écrit : 2009/5/28 Vincent Pottier vpott...@gmail.com: Sinon, il reste l'option de créer un nouveau landuse qui décrive ce mélange. Pourquoi se limiter aux tags existants ? C'est ce que j'allais proposer en lisant le fil. Les descriptions CLC sont assez claires : systèmes culturaux et parcellaires *complexes*. Ces petites parcelles doivent voir des rotations de culture avec retour à la prairie par moments ; il est inutile àmha de vouloir dans OSM définir plus précisément ces espaces sauf à avoir un résultat super précis... valable un an. Il conviendrait donc de proposer un nouveau tag... pour lequel je n'ai aucune idée à cette heure-ci :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes révolutionaires
Et voilà, c'était finalement un peu plus long que prévu mais pas très compliqué... Yann timestamp.diff Description: Binary data Le 28 mai 09 à 23:01, Mathieu Arnold a écrit : +--On 28 mai 2009 16:31:50 +0200 sly (sylvain letuffe) sylv...@letuffe.org wrote: | On Thursday 28 May 2009 16:14, Yann Coupin wrote: | Bon je confirme ça ne stocke pas le timestamp, mais osm2pgsql a un | code simple et je pense que je pourrais faire la modif en une heure, | tu veux que j'y jete un coup d'œil ce soir ? | | Ha ben si tu as le courage ! Mais le jeu en vaut il la chandelle ? à toi | de voir. | L'ajout d'un timestamp unix correspondant à la dernière modification de | la relation dans un champ de la table marcherait au poil. Dernière modif ou date d'ajout ? -- Mathieu Arnold ___ 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] Corine Land Cover : nomenclature 3 1 Forêts
Vincent Pottier a écrit : Pieren a écrit : Trois types de forêts sont distingués dans CLC. * la classe 311 Forêts de feuillus est proposée sur le wiki en landuse=forest, natural=wood, wood=deciduous. Pourtant la documentation de landuse=forest (http://wiki.openstreetmap.org/wiki/Forest) précise que natural=wood devrait être réservée aux forêts naturelles (non gérées/primaires), ce qui est rarement le cas. Je proposerais donc de se limiter à landuse=forest, wood=deciduous. landuse=forest + natural=wood est un usage répandu mais qui me semblait fautif. C'est parce qu'il est répandu que je l'avais mis. Cela me gênait justement de voir dans le wiki qu'on allait continuer à copier l'erreur juste parce que c'était souvent le cas ailleurs. Contente de voir qu'on supprime le tag natural de la proposition. * la classe 312 Forêts de conifères serait, pour les mêmes raisons traduite en landuse=forest, wood=coniferous. * la classe 313 Forêts mélangées serait traduite en landuse=forest, wood=mixed. Ok donc pour les 3. VE ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Corine Land Cover : nomenclature 32 Milieux à végétation arbustive et/ou herbac ée
Vincent Pottier a écrit : Pieren a écrit : * la classe 324 Forêt et végétation arbustive en mutation est de loin la plus présente dans cette catégorie (~15000). Elle est proposée en natural=wood + wood=mixed sur le wiki. Le sous-titre parle de Végétation arbustive ou herbacée avec arbres épars. Formations pouvant résulter de la dégradation de la forêt ou d’une re-colonisation / régénération par la forêt.. Les quelques photos ici : http://etc-lusi.eionet.europa.eu/CLC2000/classes/Pictures?CLCcategory=3/3.2/3.2.4CLCtitle=Transitional%20woodland-shrub montrent une grande variété de cas. Mais un examen sur la carte en ligne et google désigne plutôt des espaces de jeunes arbrisseaux, donc une future forêt (dans le sud, ça peut concerner d'anciennes zones brûlées). Marquer ces zones comme de la forêt me parait abusif dans la majorité des cas mais je n'ai pas d'autre proposition à soumettre. J'aurais tendance à ne pas importer ces polygones. Je crois que c'est l'exploitation forestière par coupe rase qui est la principale cause de ce grand nombre : [...] Faut-il attendre que ça repousse pour savoir si c'est du 311, 312 ou 313 ? Je pense aussi qu'il s'agit de parcelles en mutation suite à l'exploitation forestière et pour les mêmes raisons que les parcellaires agricoles complexes (vouloir cartographier plus précisément reviendrait à cartographier à très court terme), je vote plutôt pour un import avec les tags proposés sur le wiki (natural=wood + wood=mixed) [enfin pour le premier tag j'hésite entre natural=wood et landuse=forest]. VE ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr