Re: [OSM-talk-fr] Communes Nodes Ways

2009-05-28 Par sujet Etienne Chové
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

2009-05-28 Par sujet Emilie Laffray
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

2009-05-28 Par sujet Antoine
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

2009-05-28 Par sujet Antoine
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

2009-05-28 Par sujet Marc SIBERT
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

2009-05-28 Par sujet Axel R.
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

2009-05-28 Par sujet Julien D.
Ç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

2009-05-28 Par sujet Yann Coupin
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

2009-05-28 Par sujet Lionel Maraval
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-05-28 Par sujet Pieren
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

2009-05-28 Par sujet wouldsmina
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-05-28 Par sujet Pieren
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

2009-05-28 Par sujet Axel R.
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 ?)

2009-05-28 Par sujet Sébastien Pierrel
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 ?)

2009-05-28 Par sujet Art Penteur
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

2009-05-28 Par sujet Ratzillas Da Rats' Prince
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

2009-05-28 Par sujet gnunux
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

2009-05-28 Par sujet Vincent MEURISSE
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 ?)

2009-05-28 Par sujet Vincent Pottier
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

2009-05-28 Par sujet Vincent Pottier
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

2009-05-28 Par sujet Pierre Mauduit
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?)

2009-05-28 Par sujet THEVENON Julien
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 ?

2009-05-28 Par sujet Vincent Pottier
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

2009-05-28 Par sujet sly (sylvain letuffe)
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 ?

2009-05-28 Par sujet sly (sylvain letuffe)
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

2009-05-28 Par sujet sly (sylvain letuffe)

 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

2009-05-28 Par sujet Yann Coupin
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

2009-05-28 Par sujet sly (sylvain letuffe)
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

2009-05-28 Par sujet Yann Coupin
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

2009-05-28 Par sujet Vincent Pottier
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

2009-05-28 Par sujet Vincent MEURISSE
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-05-28 Par sujet Pieren
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 ?

2009-05-28 Par sujet wouldsmina
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

2009-05-28 Par sujet sly (sylvain letuffe)
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

2009-05-28 Par sujet sly (sylvain letuffe)
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

2009-05-28 Par sujet Etienne T
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-05-28 Par sujet Emilie Laffray
+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

2009-05-28 Par sujet Vincent Pottier
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

2009-05-28 Par sujet Etienne T
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-05-28 Par sujet Emilie Laffray
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

2009-05-28 Par sujet THEVENON Julien
+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-05-28 Par sujet Pieren
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

2009-05-28 Par sujet Emilie Laffray
 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-05-28 Par sujet Pieren
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)

2009-05-28 Par sujet sly (sylvain letuffe)

 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 ?

2009-05-28 Par sujet Vincent Pottier
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

2009-05-28 Par sujet Emilie Laffray
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 ?

2009-05-28 Par sujet sly (sylvain letuffe)

 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

2009-05-28 Par sujet Vincent Pottier
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-05-28 Par sujet Pieren
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)

2009-05-28 Par sujet Emilie Laffray
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 ?

2009-05-28 Par sujet Vincent Pottier
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

2009-05-28 Par sujet Jean-Francois Nifenecker
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 ?

2009-05-28 Par sujet sly (sylvain letuffe)

 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

2009-05-28 Par sujet Yann Coupin
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

2009-05-28 Par sujet THEVENON Julien
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-05-28 Par sujet Pieren
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-05-28 Par sujet Pieren
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)

2009-05-28 Par sujet Emilie Laffray
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

2009-05-28 Par sujet Emilie Laffray
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

2009-05-28 Par sujet Pieren
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-05-28 Par sujet Pieren
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)

2009-05-28 Par sujet Emilie Laffray
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

2009-05-28 Par sujet Pieren
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 ?

2009-05-28 Par sujet wouldsmina
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

2009-05-28 Par sujet Pieren
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

2009-05-28 Par sujet Vincent Pottier
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

2009-05-28 Par sujet Vincent Pottier
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

2009-05-28 Par sujet Didier HALATRE
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

2009-05-28 Par sujet Vincent Pottier
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-05-28 Par sujet Pieren
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

2009-05-28 Par sujet Mathieu Arnold


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

2009-05-28 Par sujet sylvain letuffe
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

2009-05-28 Par sujet sylvain letuffe
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

2009-05-28 Par sujet Vincent Pottier
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

2009-05-28 Par sujet sylvain letuffe

 * 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

2009-05-28 Par sujet Hugues Romain (RCS)
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

2009-05-28 Par sujet sylvain letuffe

 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

2009-05-28 Par sujet Emilie Laffray
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

2009-05-28 Par sujet Vincent Pottier
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-05-28 Par sujet Pieren
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

2009-05-28 Par sujet Emilie Laffray
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

2009-05-28 Par sujet Vincent Pottier
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-05-28 Par sujet Pieren
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-05-28 Par sujet Pieren
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-05-28 Par sujet Pieren
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

2009-05-28 Par sujet Valerie-Emma Leroux
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

2009-05-28 Par sujet Yann Coupin
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

2009-05-28 Par sujet Valerie-Emma Leroux
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

2009-05-28 Par sujet Valerie-Emma Leroux
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