date:20090526

Oui c'est bien quelque chose de cet ordre que je supposais. En fait le  
from-to ne sert qu'à connaître le sens contrôlé, pas la direction  
visée par la caméra. Mais tu soulève un point intéressant et qui  
mérite discussion : comment noter que les photos sont prises par  
l'avant ou par l'arrière. Rien dans la spec ne permet de le décrire,  
et c'est une info utile. Il va falloir qu'on en discute sur la page  
originale je pense...

Yann

Le 27 mai 09 à 00:50, Marc SIBERT a écrit :

> C'est à moi, mais je crois avoir un problème de calcul Avant /  
> Arrière.
> Angle entre nodes "from" / "to" et nodes "device" / "to".
> J'ai hâtivement supposé que la photo était faite sur le "to" depuis le
> "device" (ce que j'écris dans la page du wiki).


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Encore plus de fichiers Corine

Pieren wrote:
> La relation multipolygone sera aussi nécessaire pour les polygones
> complexes avec trous. C'est peut-être ce que fait le script, mais
> uniquement dans ces cas-là.
> Pieren
>   
En effet, apres relecture du script, il n'utilise des relations que pour
les polygones complexes. Il faudra donc ajouter la gestion des polygones
de plus de 2000 points dans le systeme.
Je regarderais ca quand je porterais le script pour produire des
fichiers en 0.6 au lieu de 0.5.

Emilie Laffray



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] Encore plus de fichiers Corine

2009/5/27 Emilie Laffray :
> Il y a 439 polygones dans Corine avec plus de 2000 points.
> Le detail est le suivant:
>
> "211";150
> "311";147
> "231";112
> "242";29
> "312";28
> "321";19
> "221";14
> "332";11
> "323";9
> "511";8
> "313";7
> "112";6
> "324";3
> "523";3
> "423";3
> "335";1
> "411";1
>
> Il faudra donc que je vois pour decouper certaines ways en plusieurs
> ways pour former une relation.
>
> Emilie Laffray
>

La relation multipolygone sera aussi nécessaire pour les polygones
complexes avec trous. C'est peut-être ce que fait le script, mais
uniquement dans ces cas-là.
Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Corine Land Cover : nomenclature 1 4 "Espaces verts artificialisés, non agricoles"

2009-05-26 Par sujet Valerie-Emma Leroux

Pieren a écrit :

[classes 141 et 142]
> 
> J'ai encore un peu examiné ces deux classes. J'ai aussi trouvé un
> hippodrome en 142 comme un golf et un circuit automobile. Le 141 se
> retrouve sur les grands parcs en ville ou à côté mais on voit aussi
> l'imprécision des polygones qui débordent largement sur les zones
> résidentielles voisines. Comme les parcs sont souvent déjà tagués dans
> OSM et avec une meilleure précision, je proposerais donc d'abandonner
> ces deux classes.

Cela semble le plus pertinent.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Corine Land Cover : nomenclature 3 1 "Forêts"

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.

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".

* 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".

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Re : Encore plus de fichiers Corine

Bonsoir,

Euh il n'y a pas grand chose a admirer honnetement. Maintenant c'est une
grosse requete sql que je modifie pour chaque nouvelle categorie. La
deuxieme etape est juste d'utiliser des outils standards.
Le plus long est de loin d'ecrire les scripts initiaux. Je suis en train
de finaliser une page sur le wiki de Open street map expliquant toutes
les etapes pour generer ces fichiers.

Emilie Laffray

THEVENON Julien wrote:
> euh pareil...il me semble qu il y a du boulot pour faire toutes les
> conversions necessaires pour obenir ces fichiers :-) mais je me
> demandais si on peut deja essayer de les exploiter ou si il faut
> attendre quelque chose d automatique genre ce qu a fait sly en
> experi,ental sur beta letuffe ?
>
> Julien

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] Encore plus de fichiers Corine

Il y a 439 polygones dans Corine avec plus de 2000 points.
Le detail est le suivant:

"211";150
"311";147
"231";112
"242";29
"312";28
"321";19
"221";14
"332";11
"323";9
"511";8
"313";7
"112";6
"324";3
"523";3
"423";3
"335";1
"411";1

Il faudra donc que je vois pour decouper certaines ways en plusieurs
ways pour former une relation.

Emilie Laffray

Yann Coupin wrote:
> Et pourquoi on ne pourrait pas faire comme avec le les surfaces  
> cadastrales après tout ? Bon je sais qu'on ne tagge pas pour le rendu  
> mais c'est vrai que ça risque de mieux marcher avec des polygones...  
> Mais n'empêche qu'on risque d'avoir plein de polygones mitoyens et  
> avec bcp de points pour certains (genre zone urbaine d'une grande  
> ville). Passer aux relations fait sens.
>
> Sly, tu nous sors le nombre de points du plus grand polygone, stp ? On  
> en a combien qui dépassent les 2 000 points ?
>
> Yann
>
> Le 27 mai 09 à 00:31, Pieren a écrit :
>
>   
>> Euh, j'ai peur de ne pas comprendre.Fusionner les ways et utiliser un
>> way pour deux landuse voisins ? mais les landuse sont des polygones,
>> pas des relations.
>> 
>
>
> ___
> 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] Key:enforcement

C'est à moi, mais je crois avoir un problème de calcul Avant / Arrière. 
Angle entre nodes "from" / "to" et nodes "device" / "to".
J'ai hâtivement supposé que la photo était faite sur le "to" depuis le 
"device" (ce que j'écris dans la page du wiki).

--
Marc

Yann Coupin a écrit :
> C'est un site géré par quelqu'un qui traine ici ? Oui alors s'il lit 
> ça, je voudrais savoir comment est déterminé le fait que le flash se 
> fait "par l'avant" ou "par l'arrière", car les infos sont les mêmes et 
> j'ai peur qu'une mauvaise lecture de la spec lui ait fait conclure 
> certaines choses de manière hâtive...
>
> Yann

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Encore plus de fichiers Corine

Pieren wrote:
> 2009/5/26 Emilie Laffray :
>   
>> Les autres categories seront produites a mesure qu'un consensus se
>> degagera. A noter que j'ai trouve le moyen de fusionner les points de
>> polygones existants. Il faut que je regarde s'il est possible de faire
>> cela avec les ways mais je pense que cela compliquera les choses car ca
>> implique de casser les ways en petit morceau. Je verrais ce qui est
>> faisable.
>> 
>
> Euh, j'ai peur de ne pas comprendre.Fusionner les ways et utiliser un
> way pour deux landuse voisins ? mais les landuse sont des polygones,
> pas des relations.
>   
Euh oui, pour je ne sais quelle raison, j'etais convaincue que le
fichier produisait des relations. Apres lecture du code Python, le code
peut en effet generer des relations mais dans le cas present, il n;y en
a pas.
Je vais juste donc appliquer la fusion des nodes la ou c'est possible.

Emilie Laffray



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] Encore plus de fichiers Corine

Et pourquoi on ne pourrait pas faire comme avec le les surfaces  
cadastrales après tout ? Bon je sais qu'on ne tagge pas pour le rendu  
mais c'est vrai que ça risque de mieux marcher avec des polygones...  
Mais n'empêche qu'on risque d'avoir plein de polygones mitoyens et  
avec bcp de points pour certains (genre zone urbaine d'une grande  
ville). Passer aux relations fait sens.

Sly, tu nous sors le nombre de points du plus grand polygone, stp ? On  
en a combien qui dépassent les 2 000 points ?

Yann

Le 27 mai 09 à 00:31, Pieren a écrit :

> Euh, j'ai peur de ne pas comprendre.Fusionner les ways et utiliser un
> way pour deux landuse voisins ? mais les landuse sont des polygones,
> pas des relations.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique (suite)

2009/5/27 sylvain letuffe :
>
>> Absolument, les deux codes se trouvent normalement dans le node place.
>> Si tu créés le lien entre relation et place avec admin_centre, on
>> pourra facilement faire la migration vers la relation losrque le temps
>> sera venu.
>
> Je m'imaginais même ne pas avoir besoin de faire la saisie, car la relation
> qu'il y a entre le chef lieu et la commune dans laquelle il est, c'est une
> relation géographique. (un point dans une surface)
>
> Ça peut donc se retrouver par requête spatiale sans avoir besoin d'une liaison
> style "relationnel classique" entre la relation et le point du chef lieu.
>
> Et donc, le feignant parle, ça évite d'ajouter le role admin_center puisqu'on
> pourra l'ajouter de façon automatique, ainsi que, au passage les tags que
> l'on jugera utiles.
>

Sauf qu'il y a souvent plusieurs nodes places dans la surface... mais
un seul chef-lieu.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Encore plus de fichiers Corine

2009/5/26 Emilie Laffray :
> Les autres categories seront produites a mesure qu'un consensus se
> degagera. A noter que j'ai trouve le moyen de fusionner les points de
> polygones existants. Il faut que je regarde s'il est possible de faire
> cela avec les ways mais je pense que cela compliquera les choses car ca
> implique de casser les ways en petit morceau. Je verrais ce qui est
> faisable.

Euh, j'ai peur de ne pas comprendre.Fusionner les ways et utiliser un
way pour deux landuse voisins ? mais les landuse sont des polygones,
pas des relations.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Re : Encore plus de fichiers Corine

2009-05-26 Par sujet THEVENON Julien

euh pareil...il me semble qu il y a du boulot pour faire toutes les conversions 
necessaires pour obenir ces fichiers :-) mais je me demandais si on peut deja 
essayer de les exploiter ou si il faut attendre quelque chose d automatique 
genre ce qu a fait sly en experi,ental sur beta letuffe ?

Julien





De : Vincent Pottier 
À : Discussions sur OSM en français 
Envoyé le : Mercredi, 27 Mai 2009, 0h19mn 19s
Objet : Re: [OSM-talk-fr] Encore plus de fichiers Corine

Emilie Laffray a écrit :
> Bonsoir,
>
> je viens de mettre a disposition plus de fichiers Corine notamment pour
> les villes ainsi que pour la categorie 13.
>
> Les fichiers peuvent etre telecharges a l'adresse suivante:
> http://www.grayonox.com/nooverlaptown.osm.bz2
> http://www.grayonox.com/overlaptown.osm.bz2
> http://www.grayonox.com/smalloverlaptown.osm.bz2
> http://www.grayonox.com/nooverlapmdc.osm.bz2
> http://www.grayonox.com/overlapmdc.osm.bz2
> http://www.grayonox.com/smalloverlapmdc.osm.bz2
>
> No overlap correspond a aucune intersection avec un polygone existant de
> OSM.
> Small overlap correspond a une intersection avec un ou plusieurs
> polygones existants de OSM entre 0% et 5%.
> Overlap correspond a une intersection avec un ou plusieurs polygones
> existants de OSM au dessus de 5%.
>
> Les autres categories seront produites a mesure qu'un consensus se
> degagera. A noter que j'ai trouve le moyen de fusionner les points de
> polygones existants. Il faut que je regarde s'il est possible de faire
> cela avec les ways mais je pense que cela compliquera les choses car ca
> implique de casser les ways en petit morceau. Je verrais ce qui est
> faisable.
> Peut etre que l'outil utilise pour les limites administratives des
> villes sera utile.
>
> Emilie Laffray
>
>  
J'admire ! Mais je ne sais pas quoi en faire ;-)

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

Re: [OSM-talk-fr] Key:enforcement

C'est un site géré par quelqu'un qui traine ici ? Oui alors s'il lit  
ça, je voudrais savoir comment est déterminé le fait que le flash se  
fait "par l'avant" ou "par l'arrière", car les infos sont les mêmes et  
j'ai peur qu'une mauvaise lecture de la spec lui ait fait conclure  
certaines choses de manière hâtive...


Yann

Le 26 mai 09 à 23:35, Marc SIBERT a écrit :


Ces 2 là sont codés depuis quelques minutes.

Le résultat ici http://freeroute.fr/enforcements.htm quand la XAPI se
sera mise à jour.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Encore plus de fichiers Corine

Emilie Laffray a écrit :
> Bonsoir,
>
> je viens de mettre a disposition plus de fichiers Corine notamment pour
> les villes ainsi que pour la categorie 13.
>
> Les fichiers peuvent etre telecharges a l'adresse suivante:
> http://www.grayonox.com/nooverlaptown.osm.bz2
> http://www.grayonox.com/overlaptown.osm.bz2
> http://www.grayonox.com/smalloverlaptown.osm.bz2
> http://www.grayonox.com/nooverlapmdc.osm.bz2
> http://www.grayonox.com/overlapmdc.osm.bz2
> http://www.grayonox.com/smalloverlapmdc.osm.bz2
>
> No overlap correspond a aucune intersection avec un polygone existant de
> OSM.
> Small overlap correspond a une intersection avec un ou plusieurs
> polygones existants de OSM entre 0% et 5%.
> Overlap correspond a une intersection avec un ou plusieurs polygones
> existants de OSM au dessus de 5%.
>
> Les autres categories seront produites a mesure qu'un consensus se
> degagera. A noter que j'ai trouve le moyen de fusionner les points de
> polygones existants. Il faut que je regarde s'il est possible de faire
> cela avec les ways mais je pense que cela compliquera les choses car ca
> implique de casser les ways en petit morceau. Je verrais ce qui est
> faisable.
> Peut etre que l'outil utilise pour les limites administratives des
> villes sera utile.
>
> Emilie Laffray
>
>   
J'admire ! Mais je ne sais pas quoi en faire ;-)

Vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique (suite)

2009-05-26 Par sujet sylvain letuffe


> Absolument, les deux codes se trouvent normalement dans le node place.
> Si tu créés le lien entre relation et place avec admin_centre, on
> pourra facilement faire la migration vers la relation losrque le temps
> sera venu.

Je m'imaginais même ne pas avoir besoin de faire la saisie, car la relation 
qu'il y a entre le chef lieu et la commune dans laquelle il est, c'est une 
relation géographique. (un point dans une surface) 

Ça peut donc se retrouver par requête spatiale sans avoir besoin d'une liaison 
style "relationnel classique" entre la relation et le point du chef lieu.

Et donc, le feignant parle, ça évite d'ajouter le role admin_center puisqu'on 
pourra l'ajouter de façon automatique, ainsi que, au passage les tags que 
l'on jugera utiles.

--
sly

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique (suite)

sylvain letuffe a écrit :
>> Un autre truc : autant ajouter tout de suite dans les relations le point
>> 'admin_center'. Je l'ai fait pour l'exemple sur Saint-Pryvé. Ainsi que
>> d'autres infos (ref qui est la reprise du code INSEE)
>> 
>
> Oulla, je suis un mauvais élève alors, je ne fais ni l'un ni l'autre, je 
> m'étais dis que comme les deux étaient en "gestation", il fallait laisser le 
> temps de mûrir et qu'on ferait ça automatiquement avec un robot une fois 
> d'accord.
>
> --
> sly
>   
Je m'étais dit la même chose mais en pensant qu'il était plus facile au
robot d'enlever que d'ajouter s'il y a plusieurs nodes place (village,
hamlet, suburb...)
Et je me disais aussi que population, c'était mieux, porté sur la
relation (disons 1000 h), si le village central comporte une partie
seulement de celle-ci (800 h) et les hameaux le reste (2 x 100).
Mais je n'ai pas fait dès le début. Il y a des manques et je suis flemmard.

Vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Encore plus de fichiers Corine

Bonsoir,

je viens de mettre a disposition plus de fichiers Corine notamment pour
les villes ainsi que pour la categorie 13.

Les fichiers peuvent etre telecharges a l'adresse suivante:
http://www.grayonox.com/nooverlaptown.osm.bz2
http://www.grayonox.com/overlaptown.osm.bz2
http://www.grayonox.com/smalloverlaptown.osm.bz2
http://www.grayonox.com/nooverlapmdc.osm.bz2
http://www.grayonox.com/overlapmdc.osm.bz2
http://www.grayonox.com/smalloverlapmdc.osm.bz2

No overlap correspond a aucune intersection avec un polygone existant de
OSM.
Small overlap correspond a une intersection avec un ou plusieurs
polygones existants de OSM entre 0% et 5%.
Overlap correspond a une intersection avec un ou plusieurs polygones
existants de OSM au dessus de 5%.

Les autres categories seront produites a mesure qu'un consensus se
degagera. A noter que j'ai trouve le moyen de fusionner les points de
polygones existants. Il faut que je regarde s'il est possible de faire
cela avec les ways mais je pense que cela compliquera les choses car ca
implique de casser les ways en petit morceau. Je verrais ce qui est
faisable.
Peut etre que l'outil utilise pour les limites administratives des
villes sera utile.

Emilie Laffray



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] problème avec les limites cadastra les automatique (suite)

>> Ah bon ? C'est marqué ou ? Ah tu parles du ref qui est le code postal ;-)
> Hum, farceur...
>

hehe. C'est justement le problème avec ref.

2009/5/26 sylvain letuffe :
> Oulla, je suis un mauvais élève alors, je ne fais ni l'un ni l'autre, je
> m'étais dis que comme les deux étaient en "gestation", il fallait laisser le
> temps de mûrir et qu'on ferait ça automatiquement avec un robot une fois
> d'accord.

Absolument, les deux codes se trouvent normalement dans le node place.
Si tu créés le lien entre relation et place avec admin_centre, on
pourra facilement faire la migration vers la relation losrque le temps
sera venu.
Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Key:enforcement

Ces 2 là sont codés depuis quelques minutes.

Le résultat ici http://freeroute.fr/enforcements.htm quand la XAPI se 
sera mise à jour.

--
Marc

Antoine a écrit :
> Je me répond à moi-même :
> Cela semble effectivement être un point kilométrique, car 2 radars (1 
> dans chaque sens) situés au même endroit portent la même référence :
> http://www2.securiteroutiere.gouv.fr/data/radars/iledefrance.htm#Liste%204
>
> Antoine

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastrale s automatique (suite)

2009-05-26 Par sujet sylvain letuffe


> Un autre truc : autant ajouter tout de suite dans les relations le point
> 'admin_center'. Je l'ai fait pour l'exemple sur Saint-Pryvé. Ainsi que
> d'autres infos (ref qui est la reprise du code INSEE)

Oulla, je suis un mauvais élève alors, je ne fais ni l'un ni l'autre, je 
m'étais dis que comme les deux étaient en "gestation", il fallait laisser le 
temps de mûrir et qu'on ferait ça automatiquement avec un robot une fois 
d'accord.

--
sly

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Key:enforcement

2009-05-26 Par sujet Antoine


Je me répond à moi-même :
Cela semble effectivement être un point kilométrique, car 2 radars (1 
dans chaque sens) situés au même endroit portent la même référence :

http://www2.securiteroutiere.gouv.fr/data/radars/iledefrance.htm#Liste%204

Antoine

Antoine a écrit :
Si c'était un point kilométrique, on aurait pas de valeur supérieure à 
1000 derrière le +, non ?

Exemple : relation #147 659

Antoine

Yann Coupin a écrit :
Je ne vois pas de quelle référence tu parles, sauf si ce sont les 
références du genre PR7+800 par exemple qui veut juste dire que le 
radar est situé au point kilométrique 7 + 800m mais ça n'est pas 
vraiment une référence, juste une information sur sa position...


Yann

Le 26 mai 09 à 18:41, Antoine a écrit :


Bonjour,

Le site de la sécurité routière [1] semble avoir des références pour 
les 
radars automatiques.

Doit-on les mettre dans une clé "ref" dans la relation ?

[1] http://www2.securiteroutiere.gouv.fr/data/radars/index.html
Antoine




___
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] problème avec les limites cadastra les automatique (suite)

Axel Rousseau a écrit :
> merci beaucoup pour vos conseils, je pense que je vais m'en sortir.
>
> En fait, j'ai vraiment pas fait grand chose, j'ai juste mis des noms de 
> villes dans un fichier et lancé les scripts de délimitation automatique. 
> C'est donc la partie "peaufinage" que j'apprends à faire :)
>
> Je n'avais pas l'habitude de travailler avec les relations jusqu'à 
> présent, mais c'est un forgeant que l'on devient cartographe...
>
> Encore merci,
>
> Axel
>   
En fait, le peaufinage, c'est de retirer beaucoup de redondance, pour
n'avoir qu'un chemin pour deux communes et de mettre les valeurs qui
vont bien sur les éléments qui vont bien.

Vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] problème avec les limites cadastr ales automatique (suite)

2009-05-26 Par sujet Axel Rousseau

merci beaucoup pour vos conseils, je pense que je vais m'en sortir.

En fait, j'ai vraiment pas fait grand chose, j'ai juste mis des noms de 
villes dans un fichier et lancé les scripts de délimitation automatique. 
C'est donc la partie "peaufinage" que j'apprends à faire :)

Je n'avais pas l'habitude de travailler avec les relations jusqu'à 
présent, mais c'est un forgeant que l'on devient cartographe...

Encore merci,

Axel

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique (suite)

2009-05-26 Par sujet sylvain letuffe

Le mardi 26 mai 2009 22:29, Axel Rousseau a écrit :
> Donc si j'ai bien compris le "code couleur", c'est quand les communes
> sont en gris qu'il y a des problèmes ?

Et surtout quand elles n'apparaissent pas du tout : il y a un problème et là 
il faut s'aider du super outils d'étienne "osmose" pour avoir plus d'infos 
sur le problème.

Le mien donne un rapide aperçu des zones à problème, mais l'outil d'étienne 
est génial pour préciser quel est "le" problème.

Quand une couche de gris s'ajoute c'est pour indiquer un problème léger (en 
fait, je me demande si c'est vraiment un problème) mais pour indiquer qu'a un 
endroit (mais on ne sait pas lequel ! chasse au trésor !) la 
surface "s'auto-croise" ou se tangente elle même

Attention ! dessin :
auto-croissement
  __
  \ /
   /\
  /   \
 / \


> D'autre part, je n'arrive pas à corriger le problème de la ville
> d'Ormes, je pensais avoir tout corrigé. L'outil utilise t'il les données
> dès qu'on les upload via josm ?

Après un petit suivi sur cet outils ici :
http://forum.letuffe.org/viewtopic.php?f=3&t=36
--
sly


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique (suite)

Hey,

ne cassez pas ma belle ville d'Orleans :)

Emilie Laffray

Pieren wrote:
> 2009/5/26 Vincent Pottier :
>   
>> 'admin_center'. Je l'ai fait pour l'exemple sur Saint-Pryvé.
>> 
>
> 'admin_centre', version anglaise ;-)
>
>
>   
>> Ainsi que d'autres infos (ref qui est la reprise du code INSEE)
>> 
> Ah bon ? C'est marqué ou ? Ah tu parles du ref qui est le code postal ;-)
>
> Mais sinon, bonne révision. Le pauvre Alex va croire qu'il a foutu une
> merde sans nom mais tout ça est assez facile et rapide à corriger.
> Et il a encore plein d'autres choses qui mériteraient correction
> (l'Avenue du Général de Gaulle en ref D902 (D 902); elle se transforme
> en double oneways après le rond-point mais un seul way porte le nom
> "Route d'Ormes").
> Alex, si tu veux un coup de main, dis-le nous.
> 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] problème avec les limites cadastra les automatique (suite)

2009/5/26 Vincent Pottier :
> 'admin_center'. Je l'ai fait pour l'exemple sur Saint-Pryvé.

'admin_centre', version anglaise ;-)


>Ainsi que d'autres infos (ref qui est la reprise du code INSEE)
Ah bon ? C'est marqué ou ? Ah tu parles du ref qui est le code postal ;-)

Mais sinon, bonne révision. Le pauvre Alex va croire qu'il a foutu une
merde sans nom mais tout ça est assez facile et rapide à corriger.
Et il a encore plein d'autres choses qui mériteraient correction
(l'Avenue du Général de Gaulle en ref D902 (D 902); elle se transforme
en double oneways après le rond-point mais un seul way porte le nom
"Route d'Ormes").
Alex, si tu veux un coup de main, dis-le nous.
Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique (suite)

2009-05-26 Par sujet Vincent MEURISSE

On Tuesday 26 May 2009 22:29:11 Axel Rousseau wrote:
> Donc si j'ai bien compris le "code couleur", c'est quand les communes
> sont en gris qu'il y a des problèmes ?
> Parce que c'est le cas de Saint Pryvé Saint Mesmin (commune au sud ouest
> d'Orléans) et en testant la relation avec l'outil de Matthieu, il
> indique que la relation est correcte.
les relations checkers ne testent que si la relation est en un seul morceau et 
fermée.
Le serveur beta.letuffe.org teste également si la forme est bonne. Si la 
relation est en forme de O c'est bon. Si elle est en forme de 8 c'est gris. 
L'outil d'import automatique a tendance a inverser les points quand les 
cadastres des deux communes sont pas d'accords.

-- 
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 2 4 "Zones agricoles hétérogènes "

sly (sylvain letuffe) a écrit :
> yop là :
>   
Yaka demander je vois ! Merci.
Effectivement, ça aide à réfléchir
J'ajoute sur la page 'Nomenclature' !

Vincent
> Ben on aurait dû commencer par là, ça en aurait déjà fait quelques une où il 
> n'est pas nécessaire de se prendre la tête.
> pas de 241 et deux 244.
> et un gros paquet pour les autres, ça sent le fourre tout ;-)
>
> ( je pense pas m'être gouré, mais c'est étrange tout de même)
>
> not_osm=# select  count(*) as nombre,code_06 from corine group by code_06 
> order by code_06;
>
>  nombre | code_06
> +-
> 494 | 111
>   24633 | 112
>4410 | 121
> 795 | 122
> 123 | 123
> 253 | 124
>1684 | 131
> 146 | 132
> 185 | 133
> 428 | 141
>2155 | 142
>   26425 | 211
>   5 | 212
>  29 | 213
>4035 | 221
>2085 | 222
> 134 | 223
>   36057 | 231
>   42309 | 242
>   23883 | 243
>   2 | 244
>   39569 | 311
>   14692 | 312
>   14109 | 313
>5464 | 321
>3595 | 322
>1509 | 323
>   14785 | 324
> 341 | 331
>1272 | 332
>3329 | 333
>  64 | 334
> 144 | 335
> 692 | 411
>  65 | 412
> 280 | 421
>  33 | 422
> 293 | 423
>  59 | 511
>2373 | 512
>  90 | 521
>  30 | 522
>   4 | 523
> (43 rows)
>
>
>   


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastrale s automatique (suite)

Axel Rousseau a écrit :
> Bonjour,
> J'ai fini par réussir à avoir les délimitations pour les villes 
> d'orléans et alentours, mais sur le serveur, ils apparaissent en rouge.
> http://beta.letuffe.org/?zoom=11&lat=47.87759&lon=2.0359&layers=B0FFTF
>
> Quelqu'un pourrait il m'expliquer comment corriger ça ?
> Si j'ai bien compris, les délimitations sont des relations et pour les 
> "frontières" il faut mettre "deux relations" sur le chemin ? C'est bien 
> ça ?
> J'ai essayé de faire ça entre Ormes et Saran, si quelqu'un veut bien 
> jeter un coup d'oeil pour me dire si j'ai bien fait les choses comme il 
> faut.
>
> J'ai aussi remarqué que les noms des communes du cadastre ne 
> correspondent pas à celles de l'INSEE (tout en majuscule par exemple), 
> donc je vais corriger ça.
>
> Si vous avez d'autres conseils à me donner, je suis preneur. J'aimerai 
> bien à terme m'occuper de l'ensemble du Loiret, donc n'hésitez pas à me 
> donner des conseils ;)
>
> Merci,
>
> Axel
Bon à y regarder de près, j'ai l'impression qu'il y a quelques problèmes.

Pour la limite Orléans - Saint-Jean-de-la-ruelle, il y a deux chemins :
l'un qui est la limite d'Orléans, l'autre qui est la limite de
Saint-Jean. C'est un en trop : le même chemin doit porter les deux
relations. (j'ai ajouté un point et déplacé pour voir apparaître les
deux chemins tout à fait dans le sud, au dessus de la Loire.) Un chemin
est la limite de deux communes et non deux chemins limites chacun d'une
commune.

Pour la limite Orléans - Saint-Jean-de-la-Ruelle -
Saint-Pryvé-Saint-Mesmin, il y a un triangle qui n'est sur aucune
commune et un chemin qui fait deux points pour rattraper une 'fuite' de
la relation 'Saint-Pryvé-Saint-Mesmin'. Le dernier point du chemin
'Orléans - Saint-Jean-de-la-ruelle' doit être sur les deux chemins de
Saint-Pryvé-Saint-Mesmin'. Bref, on doit avoir un point appartenant à
trois chemins, chacun de ces chemins étant la limite de deux communes.

La relation 147550 (Saint-Pryvé-Saint-Mesmin) contient 17 segments dont :
2 nœuds : 1 chemin
3 nœuds : 7 chemins
4 nœuds : 1 chemin
11 nœuds : 1
14 nœuds : 1
15 nœuds : 1
18 nœuds : 1
27 nœuds : 1
39 nœuds : 1
40 nœuds : 1
125 nœuds : 1
Ça sent la rustine dans les fuites de continuité. Pour fermer, il faut
prolonger le chemin, voire le fusionner avec le suivant s'il a la même
fonction (sur JOSM : sélection des deux chemins à fusionner et touche
'c') et non lui ajouter une rustine.

Au carrefour de la D 951 et d'une highway=unclassified, il y a un angle
dans la limite de commune. À fort zoom, on voit bien encore un trou, un
triangle qui n'appartient ni à Orléans, ni à Saint-Pryvé. Là encore,
chaque commune a sa limite alors qu'il devrait y avoir une limite commune.

À la limite Orléans - Saint-Pryvé - Olivet, à fort zoom, c'est
bizarrement tricoté ! Rappel du principe : À la limite de trois
communes, un point de jonction de trois chemins, chacun étant la limite
de deux communes.

Il y a même un carré au dessus du Loiret qui est en enclave mais qui
n'est à personne :
http://beta.letuffe.org/?zoom=15&lat=47.87207&lon=1.85735&layers=B0FFTF

Il semble qu'il y ait d'autres problèmes.
http://beta.letuffe.org/?zoom=13&lat=47.87207&lon=1.85735&layers=B0FFTF
Mais qoui ?

Un petit truc. Un chemin, plus il est long, plus il est facile à
entretenir. S'il y a trente-six morceaux entre disons Orléans et Olivet,
je vais devoir manipuler trente-six chemins pour changer un tag.

Un autre truc : autant ajouter tout de suite dans les relations le point
'admin_center'. Je l'ai fait pour l'exemple sur Saint-Pryvé. Ainsi que
d'autres infos (ref qui est la reprise du code INSEE)

Enfin, Les noms des communes s'écrivent sans abréviation, en minuscule
avec une majuscule au début de chaque mot sauf les articles.
Saint-Pryvé-Saint-Mesmin est bien écrit. Je pense que les corrections
sont en cours...

Bon courage pour la suite... Je sais : c'est long... Je n'ai pas fini le
Doubs (600 communes, j'aurais du habiter uns île !)

Vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Key:enforcement

2009-05-26 Par sujet Antoine

Si c'était un point kilométrique, on aurait pas de valeur supérieure à 
1000 derrière le +, non ?

Exemple : relation #147 659

Antoine

Yann Coupin a écrit :
Je ne vois pas de quelle référence tu parles, sauf si ce sont les 
références du genre PR7+800 par exemple qui veut juste dire que le 
radar est situé au point kilométrique 7 + 800m mais ça n'est pas 
vraiment une référence, juste une information sur sa position...


Yann

Le 26 mai 09 à 18:41, Antoine a écrit :


Bonjour,

Le site de la sécurité routière [1] semble avoir des références pour les 
radars automatiques.

Doit-on les mettre dans une clé "ref" dans la relation ?

[1] http://www2.securiteroutiere.gouv.fr/data/radars/index.html
Antoine




___
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] problème avec les limites cadastra les automatique (suite)

2009/5/26 Matthieu Lochegnies :

Le way commun entre Saran et Ormes (id: 35,071,842) a effectivement
une portion qui partiellement doublée par deux autres ways (id:
35,071,899 avec 13 nœuds et 35,81,411 qui n'a que deux nœuds ) qui
utilisent les même nœuds et les mêmes tags.
Il y a en plus un troisième way (id: 25,321,684) qui porte le tag
"highway=unclassified" mais il est légèrement décalé.
Je pense que tu as voulu utilisé un way pour symboliser la frontière
physique qui est cette route au sud du rond-point. Mais comme ce way
existait déjà auparavant, il suffisait de le conserver et fusionner
les points communs avec la frontière administrative (avec JOSM,
sélectionner deux nodes proches et raccourci 'm' pour merge). C'est la
méthode que je préfère mais qui est une des méthodes possibles
lorsqu'une frontière administrative utilise une frontière physique
(voir la discussion sur le wiki
http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tracer_les_limites_administratives#Limites_administratives_utilisant_des_.C3.A9l.C3.A9ments_physiques)

En passant, j'ajouterais que le rond-point est plutôt moche (pas le
rond-point mais la primary qui arrive par le nord-est). Et il ne doit
pas porter de ref. C'est une erreur que je vois souvent mais un
rond-point est une intersection. On y met aucune référence ou alors on
y met toutes les références. Sur une intersection simple sur un seul
node, on ne met pas les refs des routes que croisent, donc il n'y
aucune raison de le faire avec les rond-points. Il porte aussi un name
mais c'est la même chose. Le tag name doit porter le name du
rond-point lui-même lorsque celui-ci est baptisé (ça arrive) mais pas
porter le nom d'une des rues. Ou alors il devrait porter tous les noms
des rues, etc...

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Key:enforcement

Bah, si c'est nuisible, un robot l'enlèvera. Le site .gouv l'indique, 
j'en profite pour rajouter l'info...
Je mets aussi la ville, ce qui ne sert à rien car avec les polygones des 
villes on pourra bientôt localiser la localité du radar.

Les panneaux indicateurs des radars ne servent à rien, avec le flash on 
les repère très bien ;-)
--
Marc

Marc SIBERT a écrit :
> S'il s'agit bien de ça, moi j'ajoute un tag milestone = valeur, une 
> extension personnelle du tag Node highway = milestone + ref = entier qui 
> est en proposition.
>
> --
> Marc
>
> Yann Coupin a écrit :
>   
>> Je ne vois pas de quelle référence tu parles, sauf si ce sont les 
>> références du genre PR7+800 par exemple qui veut juste dire que le 
>> radar est situé au point kilométrique 7 + 800m mais ça n'est pas 
>> vraiment une référence, juste une information sur sa position...
>>
>> Yann
>>
>> Le 26 mai 09 à 18:41, Antoine a écrit :
>>
>> 
>>> Bonjour,
>>>
>>> Le site de la sécurité routière [1] semble avoir des références pour les 
>>> radars automatiques.
>>> Doit-on les mettre dans une clé "ref" dans la relation ?
>>>
>>> [1] http://www2.securiteroutiere.gouv.fr/data/radars/index.html
>>> Antoine
>>>   
>> 
>>
>> ___
>> 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] problème avec les limites cadastra les automatique (suite)

2009/5/26 Axel Rousseau 

> Donc si j'ai bien compris le "code couleur", c'est quand les communes
> sont en gris qu'il y a des problèmes ?


Yep

Parce que c'est le cas de Saint Pryvé Saint Mesmin (commune au sud ouest
> d'Orléans) et en testant la relation avec l'outil de Matthieu, il
> indique que la relation est correcte.
>

(c'est pas mon outil :p)


> D'autre part, je n'arrive pas à corriger le problème de la ville
> d'Ormes, je pensais avoir tout corrigé. L'outil utilise t'il les données
> dès qu'on les upload via josm ?
>

La date des données prises en compte pour le rendu est indiquée sous la
carte : par exemple
DB update : 200905261954 UTC

-- 
Matthieu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique (suite)

2009/5/26 Cavok 

> La couleur rouge veut dire : relation très récente... jusqu'à vert qui
>> veut dire relation un peu plus ancienne.
>
> Il y a aussi du marron et du jaune, je suppose aussi que c'est en rapport
> de son ancienneté.
> Et encore plus de couleur avec les autres limites administratives.
> Existe t'il une nomenclature de toutes ces couleurs ?
>

Faut cliquouiller sur "explained here" en bas de la carte :
http://wiki.openstreetmap.org/index.php/Yet_another_validation_tool_for_osm_data#admin_level.3D8

-- 
Matthieu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique (suite)

2009-05-26 Par sujet Cavok

>
> La couleur rouge veut dire : relation très récente... jusqu'à vert qui
> veut dire relation un peu plus ancienne.

Il y a aussi du marron et du jaune, je suppose aussi que c'est en rapport de
son ancienneté.
Et encore plus de couleur avec les autres limites administratives.
Existe t'il une nomenclature de toutes ces couleurs ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] problème avec les limites cadastr ales automatique (suite)

2009-05-26 Par sujet Axel Rousseau

Donc si j'ai bien compris le "code couleur", c'est quand les communes 
sont en gris qu'il y a des problèmes ?
Parce que c'est le cas de Saint Pryvé Saint Mesmin (commune au sud ouest 
d'Orléans) et en testant la relation avec l'outil de Matthieu, il 
indique que la relation est correcte.

D'autre part, je n'arrive pas à corriger le problème de la ville 
d'Ormes, je pensais avoir tout corrigé. L'outil utilise t'il les données 
dès qu'on les upload via josm ?

Merci pour votre aide,

Axel

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Key:enforcement

Mouais...

A mon avis ça ne sert absolument à rien de stocker l'info.  
Premièrement car c'est une info de positionnement approximative qui  
n'a de sens que dans le cas d'une liste pas dans le cas d'une carte,  
ensuite car les panneaux de positions ne sont pas sur le radar (ni  
même potentiellement juste à côté), ni là pour l'identifier.

Yann

Le 26 mai 09 à 21:29, Marc SIBERT a écrit :

> S'il s'agit bien de ça, moi j'ajoute un tag milestone = valeur, une
> extension personnelle du tag Node highway = milestone + ref = entier  
> qui
> est en proposition.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Key:enforcement

2009/5/26 Marc SIBERT :

euh, si c'est la position, on l'a déjà avec le lat/lon du node...

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique (suite)

2009/5/26 Matthieu Lochegnies 

> 2009/5/26 Axel Rousseau 
>
>> J'ai essayé de faire ça entre Ormes et Saran, si quelqu'un veut bien
>> jeter un coup d'oeil pour me dire si j'ai bien fait les choses comme il
>> faut.
>
>
> La relation est ouverte, comme le montre cet outil pratique :
>
>
> http://osmose.openstreetmap.fr/tools/relation_analyser/cgi-bin/relation.py?NumRelation=147551
>

Pour être plus précis, tu as plusieurs ways qui se chevauchent aux endroits
où elle apparaît coupée.

-- 
Matthieu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique (suite)

2009/5/26 Axel Rousseau 

> J'ai essayé de faire ça entre Ormes et Saran, si quelqu'un veut bien
> jeter un coup d'oeil pour me dire si j'ai bien fait les choses comme il
> faut.


La relation est ouverte, comme le montre cet outil pratique :

http://osmose.openstreetmap.fr/tools/relation_analyser/cgi-bin/relation.py?NumRelation=147551

-- 
Matthieu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique (suite)

Axel Rousseau a écrit :
> Bonjour,
> J'ai fini par réussir à avoir les délimitations pour les villes 
> d'orléans et alentours, mais sur le serveur, ils apparaissent en rouge.

La couleur rouge veut dire : relation très récente... jusqu'à vert qui 
veut dire relation un peu plus ancienne.

-- 
Etienne

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] problème avec les limites cadastra les automatique (suite)

2009-05-26 Par sujet Axel Rousseau

Bonjour,
J'ai fini par réussir à avoir les délimitations pour les villes 
d'orléans et alentours, mais sur le serveur, ils apparaissent en rouge.
http://beta.letuffe.org/?zoom=11&lat=47.87759&lon=2.0359&layers=B0FFTF

Quelqu'un pourrait il m'expliquer comment corriger ça ?
Si j'ai bien compris, les délimitations sont des relations et pour les 
"frontières" il faut mettre "deux relations" sur le chemin ? C'est bien 
ça ?
J'ai essayé de faire ça entre Ormes et Saran, si quelqu'un veut bien 
jeter un coup d'oeil pour me dire si j'ai bien fait les choses comme il 
faut.

J'ai aussi remarqué que les noms des communes du cadastre ne 
correspondent pas à celles de l'INSEE (tout en majuscule par exemple), 
donc je vais corriger ça.

Si vous avez d'autres conseils à me donner, je suis preneur. J'aimerai 
bien à terme m'occuper de l'ensemble du Loiret, donc n'hésitez pas à me 
donner des conseils ;)

Merci,

Axel

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Key:enforcement

S'il s'agit bien de ça, moi j'ajoute un tag milestone = valeur, une 
extension personnelle du tag Node highway = milestone + ref = entier qui 
est en proposition.

--
Marc

Yann Coupin a écrit :
> Je ne vois pas de quelle référence tu parles, sauf si ce sont les 
> références du genre PR7+800 par exemple qui veut juste dire que le 
> radar est situé au point kilométrique 7 + 800m mais ça n'est pas 
> vraiment une référence, juste une information sur sa position...
>
> Yann
>
> Le 26 mai 09 à 18:41, Antoine a écrit :
>
>> Bonjour,
>>
>> Le site de la sécurité routière [1] semble avoir des références pour les 
>> radars automatiques.
>> Doit-on les mettre dans une clé "ref" dans la relation ?
>>
>> [1] http://www2.securiteroutiere.gouv.fr/data/radars/index.html
>> Antoine
>
> 
>
> ___
> 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 2 4 "Zones agricoles hétérogènes "

2009/5/26 sly (sylvain letuffe) :

J'ai examiné quelques exemples de 242 et 243 et ça ressemble souvent à
de la terre arable cultivée (211). Mais s'il y a un peu de verdure
(des arbres le long d'un ruisseau par exemple), ça devient du 242. Si
la proportion d'arbres augmente (un bosquet), ça passe en 243.
Mettre "landuse=farm;forest" n'aurait aucun sens à mon avis. Ça n'est
pas soit l'un, soit l'autre mais les deux plus ou moins mélangés...
Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de tag highway=escape_lane

Lionel Maraval a écrit :
> Bonjour,
> 
> La page wiki pour les dispositifs d'arrêt d'urgence est créée :
> http://wiki.openstreetmap.org/wiki/Escape_lane

Déplacé vers :
http://wiki.openstreetmap.org/wiki/Proposed_features/escape_lane

> À vos remarques avant de passer à l'étape suivante.
> Comme c'est la première fois que je fais ce genre de choses, n'hésitez 
> pas à surveiller/conseiller/corriger.

Je trouve cela suffisant.

-- 
Etienne

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Key:enforcement

Je ne vois pas de quelle référence tu parles, sauf si ce sont les  
références du genre PR7+800 par exemple qui veut juste dire que le  
radar est situé au point kilométrique 7 + 800m mais ça n'est pas  
vraiment une référence, juste une information sur sa position...


Yann

Le 26 mai 09 à 18:41, Antoine a écrit :


Bonjour,

Le site de la sécurité routière [1] semble avoir des références pour  
les

radars automatiques.
Doit-on les mettre dans une clé "ref" dans la relation ?

[1] http://www2.securiteroutiere.gouv.fr/data/radars/index.html
Antoine


___
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-26 Par sujet Denis

Art Penteur a écrit :
> Hugues Romain disait :
> 
>> Cela l'est d'autant plus qu'il y a de bons potentiels de contributions
>> "officielles" de la part de partenaires institutionnels et qu'en tant que
>> professionnel j'ai jusqu'à présent pris le parti de vanter la solution
>> Openstreetmap ...
> 
> A l'OSSIF (Open Source Software Industry Forum), ce matin, à Toulouse,
> Pierre Cohen (Député-Maire) a fait un éloge marqué de l'Open-Source,
> des standards ouverts, et de l'implication de l'administration dans
> des service numériques ouverts.
> 
> C'est peut-être une occasion de demander si on peut copier le SIG de
> Toulouse (ou de la communauté urbaine) dans OSM ?

Mieux, le Conseil Général du Val de Marne est très intéressé pour 
utiliser OSM comme socle de son SIG. Si quelqu'un a des infos plus 
détaillées, je suis preneur (en privé si nécessaire).

Denis

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Proposition de tag highway=escape_lane

2009-05-26 Par sujet Lionel Maraval

Bonjour,

La page wiki pour les dispositifs d'arrêt d'urgence est créée :
http://wiki.openstreetmap.org/wiki/Escape_lane

À vos remarques avant de passer à l'étape suivante.
Comme c'est la première fois que je fais ce genre de choses, n'hésitez pas à
surveiller/conseiller/corriger.

Lionel
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Key:enforcement

2009-05-26 Par sujet Antoine

Bonjour,

Le site de la sécurité routière [1] semble avoir des références pour les 
radars automatiques.
Doit-on les mettre dans une clé "ref" dans la relation ?

[1] http://www2.securiteroutiere.gouv.fr/data/radars/index.html
Antoine

Marc SIBERT a écrit :
> Bonsoir,
>
> Suite à la validation du tag enforcement (contrôle routier/respect des 
> limitations), je me suis lancé dans la mise au point de la page
> http://wiki.openstreetmap.org/wiki/FR:Key:enforcement, en tout cas pour 
> la version française. Je m'inspire évidemment de 
> http://wiki.openstreetmap.org/wiki/Approved_features/Relation:enforcement. 
> Je suis à la recherche de forces vives pour m'aider (et me corriger) 
> dans cette tache, voir dans sa traduction en anglais.
>
> Finalité : coder les emplacements des différents radars et autres 
> appareils de mesure présents sur le réseau routier.
>
> --
> Marcus
> On a pas le temps de s'ennuyer avec OSM.
>
> ___
> 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 2 4 "Zones agricoles hétérogènes "

On Tuesday 26 May 2009 18:07, Vincent Pottier wrote:
> Sly : une petite stat sur les 241, 242, 243, 244 pour savoir combien ça
> nous encombre ces surfaces hétérogènes ?
> Si ça représente des milliers de polygones et la surface d'un
> département, on cherche une vraie solution. Si ça représente une
> broutille, on zappe...
yop là :

Ben on aurait dû commencer par là, ça en aurait déjà fait quelques une où il 
n'est pas nécessaire de se prendre la tête.
pas de 241 et deux 244.
et un gros paquet pour les autres, ça sent le fourre tout ;-)

( je pense pas m'être gouré, mais c'est étrange tout de même)

not_osm=# select  count(*) as nombre,code_06 from corine group by code_06 
order by code_06;

 nombre | code_06
+-
494 | 111
  24633 | 112
   4410 | 121
795 | 122
123 | 123
253 | 124
   1684 | 131
146 | 132
185 | 133
428 | 141
   2155 | 142
  26425 | 211
  5 | 212
 29 | 213
   4035 | 221
   2085 | 222
134 | 223
  36057 | 231
  42309 | 242
  23883 | 243
  2 | 244
  39569 | 311
  14692 | 312
  14109 | 313
   5464 | 321
   3595 | 322
   1509 | 323
  14785 | 324
341 | 331
   1272 | 332
   3329 | 333
 64 | 334
144 | 335
692 | 411
 65 | 412
280 | 421
 33 | 422
293 | 423
 59 | 511
   2373 | 512
 90 | 521
 30 | 522
  4 | 523
(43 rows)


-- 
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 2 4 "Zones agricoles hétérogènes"

simon a écrit :
>> * la classe 244 "Territoires agro-forestiers" avec le sous-titre
>> "Cultures annuelles ou pâturages sous couvert arboré composé d'espèces
>> forestières" n'a pas d'équivalent direct dans OSM. Je n'ai pas trouvé
>> d'exemple sur la carte et je ne sais pas à quelle densité de forêt on
>> fait référence. Est-ce suffisamment dense pour parler de
>> "landuse=forest" ?
>>
>> Pieren
>>  
>> 
>
> L'agro Foresterie pour simplifier une culture de céréale entre des
> arbres. L'espacement des arbres est souvent définie en fonction des
> engins agricoles.
>
> http://www.agroforesterie.fr/definition-agroforesterie.pdf
>
>   
ou pâture : les chèvres sont moins larges que les tracteurs.

Sly : une petite stat sur les 241, 242, 243, 244 pour savoir combien ça
nous encombre ces surfaces hétérogènes ?
Si ça représente des milliers de polygones et la surface d'un
département, on cherche une vraie solution. Si ça représente une
broutille, on zappe...

Vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Des données libres pour la montagn e pour bientôt

> La séquence des gènes est 
> considéré comme des informations qui sont dans la nature et que la seule 
> mensuration ne justifie pas en avoir l'exclusivité de son usage. Il n'y a 
> aucune "invention" en cela.
>  Tout comme les altitudes des sommets, à mon avis.
C'est bien le cas ! Mais le problème n'est pas là...

> Évidement mesurer l'altitude d'un sommet n'est pas une création artistique.
Tout à fait...
  

> 1990/2, p. 38, note Ph. Gaudrat.
>   Un travail de compilation d'informations n'est pas protégé en soi par le 
> droit d'auteur. L'effort de recherche et la composition nouvelle ne
> suffisent  
> pas pour prétendre à la protection.
C'était vrai en 1990, mais cela ne l'est plus :
http://www.les-infostrateges.com/article/031027/fiche-technique-pratique-droit-des-producteurs-de-bases-de-donnees

Avec mes mots approximatifs :
La compilation d'informations dont chaque élément pris séparément peut être 
non brevetable ou non soumis à un autre droit peut être protégé par celui 
ayant constitué cette compilation ( IGN dans notre cas)

La constitution d'une base de donnée par recopie du géoportail rentrerait dans 
ce cadre il me semble.

PS: sur mon lien je découvre un point intéressant :

Les droits prévus à l'article L. 342-1 prennent effet à compter de 
l'achèvement de la fabrication de la base de données. Ils expirent quinze ans 
après le 1er janvier de l'année civile qui suit celle de cet achèvement.
Lorsqu'une base de données a fait l'objet d'une mise à la disposition du 
public avant l'expiration de la période prévue à l'alinéa précédent, les 
droits expirent quinze ans après le 1er janvier de l'année civile suivant 
celle de cette première mise à disposition.

2006+15 = 2021, rendez vous dans 12 ans pour avoir le droit de relever les 
informations des sommets ?

-- 
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 2 4 "Zones agricoles hétérogènes"

2009-05-26 Par sujet simon

> * la classe 244 "Territoires agro-forestiers" avec le sous-titre
> "Cultures annuelles ou pâturages sous couvert arboré composé d'espèces
> forestières" n'a pas d'équivalent direct dans OSM. Je n'ai pas trouvé
> d'exemple sur la carte et je ne sais pas à quelle densité de forêt on
> fait référence. Est-ce suffisamment dense pour parler de
> "landuse=forest" ?
>
> Pieren
>  

L'agro Foresterie pour simplifier une culture de céréale entre des
arbres. L'espacement des arbres est souvent définie en fonction des
engins agricoles.

http://www.agroforesterie.fr/definition-agroforesterie.pdf



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] CORINE maintenant disponible pour l'Estonie

Bonjour,

Je viens de voir que CORINE est maintenant disponible pour la
Lettonie. Le fichier qu'ils ont est 10 fois inferieur a ce que l'on a
pour le fichier France.
C'est vraiment interessant de voir que cela va faire avancer OSM pour
l'Europe de maniere assez fantastique.

Emilie Laffray

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Des données libres pour la montagne pour bientôt

2009-05-26 Par sujet Stéphane Brunner

Hello !

Je ne sais pas si une altitude est protégée mais si c'est la cas ce
n'est pas par un brevet mais par un copyright ou droit d'auteur (pour
moi c'est la même chose !).

CU
Stéphane


2009/5/26 sly (sylvain letuffe) :
> From: Dani Bach :
>  Salut à tous.
>
>  Je ne sais pas si ce que je vais dire peut contribuer ou débat ou pas... mais
> je me lance:
>
>  Dans le domaine de la propriété intellectuelle, toute découverte, nouvelle
> information...etc est protégéable par un brevet, uniquement à condition
>
> que cette information n'aie pas été divulguée avant de la dépose du brevet!
> que cette nouvelle information, découverte... etc ne soit pas évidente - il
> doit avoir un composant d'originalité, de nouveauté.
>
>  Exemple: un scientifique découvre une molécule pour traiter le cancer.
>  s'il publie l'information avant de déposer le brevet (structure de la
> molécule, effets contre les tumeurs... etc) cette information n'est plus
> patentable
>  Elle devienne ce que l'on appel "domaine publique" et ni lui (l'inventeur) ni
> personne d'autre peut bloquer qui ce soit de copier ou même exploiter
> commercialement l'invention.
>
>  Exemple2: je ne peux pas déposer un brevet pour patenter une mélange de
> citron + miel en tant que thérapie pour les maux de gorge, parce que c'est
> quelque chose du domaine publique. Je ne peux pas bloquer qui que ce soit de
> préparer des mélanges citron+miel et de les vendre en tant que thérapie.
>
>  Exemple3: je ne peux pas breveter la séquence d'un gène que j'ai découvert.
> Parce qu'il n'y a aucune originalité à lire la séquence d'un gène, même si
> personne ne l'a fait avant, si ça m'a coûté beaucoup d'efforts et si le
> produit de ce travail a beaucoup d'utilités possibles. Et je ne peux pas
> empêcher la copie et distributions de cette information une foi je l'ai
> publiée.
>
>
>  Mesurer les altitudes des sommets est similaire, à mon avis, à lire la
> séquence d'un gène. Au début de la génomique (dans les années 80)  c'était la
> mode de  patenter  les gènes, et au passage tout usage que l'on pouvait faire
> de cette information. Et les bureaux de patentes jouaient le jeu.
>  Maintenant ce n'est plus possible et les anciens brevets autrefois acceptés
> ne sont pas "reinforceables" (en anglais). La séquence des gènes est
> considéré comme des informations qui sont dans la nature et que la seule
> mensuration ne justifie pas en avoir l'exclusivité de son usage. Il n'y a
> aucune "invention" en cela.
>  Tout comme les altitudes des sommets, à mon avis.
>
>
>  Autre que les brevets il y a le code de la propriété intellectuelle, qui
> empêche la copie des créations artistiques ("créations de l'esprit").
> Évidement mesurer l'altitude d'un sommet n'est pas une création artistique.
>
>  Voir quel genre d'ouvres est protégé par le droit d'auteur et voir aussi les
> commentaires. Par exemple celui-ci (mettez-le dans le contexte de
> la "lecture" des gènes ou des altitudes)
>
>  L'Expansion industrielle / Coprosa, C.Cass., 1ère ch. civile, 2 mai 1989, DIT
> 1990/2, p. 38, note Ph. Gaudrat.
>  Un travail de compilation d'informations n'est pas protégé en soi par le
> droit d'auteur. L'effort de recherche et la composition nouvelle ne suffisent
> pas pour prétendre à la protection.
>
>
>  D.
>
> --
> 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
>



-- 
Stéphane Brunner
mail : stephane.brun...@gmail.com
messageries instantanées : stephane.brun...@gmail.com (http://talk.google.com)
--
Un peu d'espace qui vous suis partout -
https://www.getdropbox.com/referrals/NTk2OTU2Mjk
--
http://www.ubuntu-fr.org - Distribution Linux

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Des données libres pour la montagn e pour bientôt

From: Dani Bach :
 Salut à tous.
 
 Je ne sais pas si ce que je vais dire peut contribuer ou débat ou pas... mais 
je me lance:
 
 Dans le domaine de la propriété intellectuelle, toute découverte, nouvelle 
information...etc est protégéable par un brevet, uniquement à condition 
 
que cette information n'aie pas été divulguée avant de la dépose du brevet!
que cette nouvelle information, découverte... etc ne soit pas évidente - il 
doit avoir un composant d'originalité, de nouveauté.

 Exemple: un scientifique découvre une molécule pour traiter le cancer.
 s'il publie l'information avant de déposer le brevet (structure de la 
molécule, effets contre les tumeurs... etc) cette information n'est plus 
patentable 
 Elle devienne ce que l'on appel "domaine publique" et ni lui (l'inventeur) ni 
personne d'autre peut bloquer qui ce soit de copier ou même exploiter 
commercialement l'invention.
 
 Exemple2: je ne peux pas déposer un brevet pour patenter une mélange de 
citron + miel en tant que thérapie pour les maux de gorge, parce que c'est 
quelque chose du domaine publique. Je ne peux pas bloquer qui que ce soit de 
préparer des mélanges citron+miel et de les vendre en tant que thérapie.
 
 Exemple3: je ne peux pas breveter la séquence d'un gène que j'ai découvert. 
Parce qu'il n'y a aucune originalité à lire la séquence d'un gène, même si 
personne ne l'a fait avant, si ça m'a coûté beaucoup d'efforts et si le 
produit de ce travail a beaucoup d'utilités possibles. Et je ne peux pas 
empêcher la copie et distributions de cette information une foi je l'ai 
publiée.
 
 
 Mesurer les altitudes des sommets est similaire, à mon avis, à lire la 
séquence d'un gène. Au début de la génomique (dans les années 80)  c'était la 
mode de  patenter  les gènes, et au passage tout usage que l'on pouvait faire 
de cette information. Et les bureaux de patentes jouaient le jeu.
 Maintenant ce n'est plus possible et les anciens brevets autrefois acceptés 
ne sont pas "reinforceables" (en anglais). La séquence des gènes est 
considéré comme des informations qui sont dans la nature et que la seule 
mensuration ne justifie pas en avoir l'exclusivité de son usage. Il n'y a 
aucune "invention" en cela.
 Tout comme les altitudes des sommets, à mon avis.
 
 
 Autre que les brevets il y a le code de la propriété intellectuelle, qui 
empêche la copie des créations artistiques ("créations de l'esprit"). 
Évidement mesurer l'altitude d'un sommet n'est pas une création artistique.
 
 Voir quel genre d'ouvres est protégé par le droit d'auteur et voir aussi les 
commentaires. Par exemple celui-ci (mettez-le dans le contexte de 
la "lecture" des gènes ou des altitudes)
 
 L'Expansion industrielle / Coprosa, C.Cass., 1ère ch. civile, 2 mai 1989, DIT 
1990/2, p. 38, note Ph. Gaudrat.
  Un travail de compilation d'informations n'est pas protégé en soi par le 
droit d'auteur. L'effort de recherche et la composition nouvelle ne suffisent 
pas pour prétendre à la protection.
 
 
 D.

-- 
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 maintenant disponible pour l'Estonie

2009/5/26 Pieren :
> Lettonie ou Estonie ?
>

Estonie (le titre était juste)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique

2009-05-26 Par sujet f . rodrigo

Salut,
Il s'agit des identifiants de way pour les quelles la commune n'a pas peut être
déterminée lors du découpage des polygones de contours en limites. Il y a
probablement un petit trou entres des communes. Il y a des chances que ce soit à
l'intersection entres plusieurs communes.

Fred

> Bonjour,
> J'ai essayé de suivre le tutoriel ici :
>
http://wiki.openstreetmap.org/wiki/WikiProject_France/Import_assist%C3%A9_des_limites_cadastrales
> Et j'ai un petit soucis :
> Arhg impossible de savoir sur quelle commune je suis [[-2402, -1245],
> -3526, -1195, -1195]
>
> c'est un message qui apparait au dernier moment (quand je lance le split
> en Ruby)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] CORINE maintenant disponible pour l'Estonie

2009/5/26 Emilie Laffray :
Lettonie ou Estonie ?

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème avec les limites cadastra les automatique

2009/5/26 Axel R. :
Il faudrait que tu nous en dises plus. Tu lances le script sur une
liste de commune, sur une seule commune ? Est-tu sûr que cette commune
est vectorisée dans le cadastre ? A priori, les coordonnées que tu
donnes montre une commune non vectorisée.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] problème avec les limites cadastra les automatique

2009-05-26 Par sujet Axel R.

Bonjour,
J'ai essayé de suivre le tutoriel ici :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Import_assist%C3%A9_des_limites_cadastrales
Et j'ai un petit soucis :
Arhg impossible de savoir sur quelle commune je suis [[-2402, -1245], 
-3526, -1195, -1195]

c'est un message qui apparait au dernier moment (quand je lance le split 
en Ruby)

Que faire ?

Merci,

Axel



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un bruit qui court...

Julien D. a écrit :
> Super !
> 
> Une petite remarque, il semble que certaines erreurs sont compatiblisées 
> par 2 détections différentes :
> node 323192555Francois AudiracPermalink 
> 
> Browse 
> Edit 
> JOSM 
> 
>  
>   *amenity=*school
> *name=*Ecole Maternelle   Mot mal écrit 
> 
>  
> (École)
> node 323192555Francois AudiracPermalink 
> 
> Browse 
> Edit 
> JOSM 
> 
>  
>   *amenity=*school
> *name=*Ecole Maternelle   Type de voie mal écrit 
> 
>  
> (École)
> 
> 
> Es-ce normal ?

Non, je viens de virer un des deux tests... faudra attendre la prochaine 
génération demain.

-- 
Etienne

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un bruit qui court...

2009-05-26 Par sujet Julien D.

Super !

Une petite remarque, il semble que certaines erreurs sont compatiblisées par
2 détections différentes :
node 323192555 Francois Audirac
Permalink
Browse 
Edit 
JOSM
*amenity=*school
*name=*Ecole Maternelle Mot mal
écrit(École)
 node
323192555 Francois Audirac
Permalink
Browse 
Edit 
JOSM
*amenity=*school
*name=*Ecole Maternelle Type de voie mal
écrit(École)
Es-ce normal ?

2009/5/25 Etienne Chové 

> Bonsoir,
>
> On me souffle dans l'oreillette que :
>  - le backend d'osmose veut bien traiter les relations boundary
>ce test n'est visible que sur un nouveau frontend
>  - un nouveau front-end va voir le jour :
>http://osmose.openstreetmap.fr/cgi-bin/osmose.py
>
> Il paraitrait que le front-end a été codé très salement durant cette
> dure journée pluvieuse... il lui reste peut être encore des bugs.
>
> Mon voisin de bureau commence déjà à râler parce qu'il ne voit pas la
> liste des utilisateurs...
>
> On me souffle aussi que pour le moment on ne peut pas ignorer d'erreur.
>
> --
> Etienne
>
> ___
> 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] trouver un exemple pour un tag donné

2009-05-26 Par sujet Julien D.

Bonjour, ce n'est peut-être pas la solution la plus simple, mais en partant
des tags :
  http://tagwatch.stoecker.eu/France/En/tags.html

tu as le lien foot dans la ligne route :

  http://osmxapi.hypercube.telascience.org/api/0.5/*[route=foot]

On comprends facilement comment est faite l'url, facilement modifiable pour
tout autre élément.
Le numéro de l'API n'a pas encore été changé... tu le remplaces par 0.6 :

  http://osmxapi.hypercube.telascience.org/api/0.6/*[route=foot]

et ça télécharge un fichier .osm qui contient ta relation route=foot.

Un exemple de route=foot trouvé dans ce fichier .osm :
http://www.openstreetmap.org/?lat=50.0711&lon=9.0871&zoom=14

2009/5/26 Axel R. 

> Bonjour,
> Je voulais savoir comment utiliser la relation "route=foot" et je me
> demandais si y'avait moyen de trouver un exemple d'un tag donné, j'ai
> trouvé tagwatch, mais il ne me dit pas exactement où se trouve les cas
> (il dit juste combien il y en a)
> Avez vous une idée de comment les trouver ?
> Si j'ai bien compris la page suivante :
> http://tagwatch.stoecker.eu/France/En/relationstats_route.html
>
> il y aurait 3 relations avec le tag route=foot
>
> 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

[OSM-talk-fr] trouver un exemple pour un tag donn é

2009-05-26 Par sujet Axel R.

Bonjour,
Je voulais savoir comment utiliser la relation "route=foot" et je me 
demandais si y'avait moyen de trouver un exemple d'un tag donné, j'ai 
trouvé tagwatch, mais il ne me dit pas exactement où se trouve les cas 
(il dit juste combien il y en a)
Avez vous une idée de comment les trouver ?
Si j'ai bien compris la page suivante :
http://tagwatch.stoecker.eu/France/En/relationstats_route.html

il y aurait 3 relations avec le tag route=foot

Merci pour votre aide,

Axel


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un bruit qui court...

2009-05-26 Par sujet Steven Le Roux

Bravo :)

2009/5/26 Mathieu Arnold 

>
>
> +--le 26.05.2009 13:31:17 +0200, Etienne Chové écrivait :
> | Mathieu Arnold a écrit :
> |> +--On 26 mai 2009 01:06:25 +0200 Vincent Pottier 
> |> wrote:
> |> | Mois aussi.
> |> | Mai je ne trouve plus le timestamp du test.
> |>
> |> +1 (et +s).
> |
> | done...
>
> Je vais faire mon chieur, mais j'aimais bien quand c'était dans le titre
> de la page, c'était tout de suite accessible :-)
>
> | Désolé pour le style pourri, j'ai la flemme de mettre tout ça en page.
>
> Oh, c'est simple, net, précis :-)
>
> --
> Mathieu Arnold
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Steven Le Roux
Jabber-ID : ste...@jabber.fr
0x39494CCB 
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un bruit qui court...

Mathieu Arnold a écrit :
> 
> +--le 26.05.2009 13:31:17 +0200, Etienne Chové écrivait :
> | Mathieu Arnold a écrit :
> |> +--On 26 mai 2009 01:06:25 +0200 Vincent Pottier 
> |> wrote:
> |> | Mois aussi.
> |> | Mai je ne trouve plus le timestamp du test.
> |> 
> |> +1 (et +s).
> | 
> | done...
> 
> Je vais faire mon chieur, mais j'aimais bien quand c'était dans le titre
> de la page, c'était tout de suite accessible :-)

done

> | Désolé pour le style pourri, j'ai la flemme de mettre tout ça en page.
> 
> Oh, c'est simple, net, précis :-)

en effet

-- 
Etienne

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Corine Land Cover : nomenclature 23 "Prairies"

2009-05-26 Par sujet Mathieu Arnold

+--le 26.05.2009 01:42:49 +0200, Pieren écrivait :
| * la classe 231 "Prairies" est proposée sur le wiki en
| "landuse=meadow" qui est déjà assez largement utilisé (2700 sur
| l'Europe d'après tagwatch) et documenté dans Map Features.

Je vais dire que je suis d'accord :-)

-- 
Mathieu Arnold

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un bruit qui court...

2009-05-26 Par sujet Mathieu Arnold



+--le 26.05.2009 13:31:17 +0200, Etienne Chové écrivait :
| Mathieu Arnold a écrit :
|> +--On 26 mai 2009 01:06:25 +0200 Vincent Pottier 
|> wrote:
|> | Mois aussi.
|> | Mai je ne trouve plus le timestamp du test.
|> 
|> +1 (et +s).
| 
| done...

Je vais faire mon chieur, mais j'aimais bien quand c'était dans le titre
de la page, c'était tout de suite accessible :-)

| Désolé pour le style pourri, j'ai la flemme de mettre tout ça en page.

Oh, c'est simple, net, précis :-)

-- 
Mathieu Arnold

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un bruit qui court...

Etienne Chové a écrit :
> Mathieu Arnold a écrit :
>   
>> +--On 26 mai 2009 01:06:25 +0200 Vincent Pottier  wrote:
>> | Mois aussi.
>> | Mai je ne trouve plus le timestamp du test.
>>
>> +1 (et +s).
>> 
>
> done...
>
> L'interface est maintenant directement sur la page d'accueil :
> http://osmose.openstreetmap.fr/
>
> Désolé pour le style pourri, j'ai la flemme de mettre tout ça en page.
>
>   
excellent !
Merci

Vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Un bruit qui court...

Mathieu Arnold a écrit :
> +--On 26 mai 2009 01:06:25 +0200 Vincent Pottier  wrote:
> | Mois aussi.
> | Mai je ne trouve plus le timestamp du test.
> 
> +1 (et +s).

done...

L'interface est maintenant directement sur la page d'accueil :
http://osmose.openstreetmap.fr/

Désolé pour le style pourri, j'ai la flemme de mettre tout ça en page.

-- 
Etienne

___
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-26 Par sujet Art Penteur

Hugues Romain disait :

> Cela l'est d'autant plus qu'il y a de bons potentiels de contributions
> "officielles" de la part de partenaires institutionnels et qu'en tant que
> professionnel j'ai jusqu'à présent pris le parti de vanter la solution
> Openstreetmap ...

A l'OSSIF (Open Source Software Industry Forum), ce matin, à Toulouse,
Pierre Cohen (Député-Maire) a fait un éloge marqué de l'Open-Source,
des standards ouverts, et de l'implication de l'administration dans
des service numériques ouverts.

C'est peut-être une occasion de demander si on peut copier le SIG de
Toulouse (ou de la communauté urbaine) dans OSM ?

Art.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Maintenir sa base OSM à jour

On Tuesday 26 May 2009 12:13, OSM Léon wrote:
> Bonjour à tous,
> 
> J'ai probablement mal cherché sur Internet mais quelqu'un aurait il un
> script simple pour maintenir sa base de données à jour à partir des fichiers
> dits "daily diffs" ? Merci d'avance.
> 
> Thomas
> 
http://wiki.openstreetmap.org/wiki/Minutely_Mapnik
-- 
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] Des données libres pour la montag ne pour bientôt

Merci beaucoup pour votre intervention, et bravo encore pour cette ouverture 
vers le libre !

Pas simple que ces histoires de licence...

On Monday 25 May 2009 21:51, Frédéric Bunoz wrote:
> Bonjour,

>  Sur c2c, il n'y a aucune garantie d'origine des données : un contributeur
>  peut saisir les coordonnées d'un sommet à la main (issues d'un relevé GPS
>  ou sur une carte), ou en cliquant sur une carte OSM, mais en fin de compte
>  on ne sait pas d'où ça vient (l'origine n'est pas enregistrée).   
Si le positionnement a été fait grâce à une carte OSM, on se retrouve dans le 
cas de l'oeuf et la poule, c'est donc peu probable, la base c2c étant bien 
plus fournie que celle d'osm.

Mais comme tu l'as bien dit en définitif "on ne sait pas" , ne reste que des 
suppositions. Et parmi celles-ci, avec un peu de recul sur le milieu de la 
montagne, et le GPS n'ayant que quelques année de "grand public", il est à 
craindre qu'une grande partie soit en provenance direct d'un relevé carte 
papier IGN ou géoportail


>  De toute façon, les coordonnées trop précises sont arrondies (dégré à 6
>  décimales il me semble). 
Oui, mais ça devrait aller, après calcul, à nos latitudes, un 6ème de degré ça 
fait 9cm

>  Par ailleurs, je ne vois pas comment sur OSM vous garantissez plus
>  l'origine des données ??? 
Pas mieux hélas, mais comme disent les anglais :
Don't add sewage to the already polluted pond
 

>  Si je saisis une trace d'un chemin sur Cartoexplorer par exemple, en
>  vérifiant sur une photo aérienne que la carte est juste (pas de grosse
>  erreur), et que je l'enregistre sur OSM en disant qu'elle provient de GPS,
>  comment pouvez vous détecter la supercherie ? 
On peut pas, la défense est "a la wikipedia" : le maximum a été fait pour 
limiter
- indiquer qu'il est interdit de prendre sur googlemaps ou géoportail
- ne pas autoriser les outils qui permettent de saisir sur une carte sous 
copyright
- surveiller les imports de masse

  
>>  Concernant les altitudes, on peut déjà copier sans scrupule les altitudes
>>  des cartes qui ont plus de 70 ans :-)) 
>  
>  Personnellement (ce n'est pas l'avis du CA de c2c), je préfère bien plus un
>  sommet avec une altitude juste mais limite du point du vue licence, qu'avec
>  une altitude fausse mais bien dans les clous (alors que tout ça devrait
>  être publique sans condition ! et quid du droit de citation ?).   

Tout dépend de ce qu'on veut, certains ici préfèrent rien que litigieux. La 
question est de déterminer a quel point "litigieux". L'utilisateur final qui 
ne prend aucun risque, quant à lui, préférera toujours de la donnée juste. 
Mais osm n'est pas vraiment un produit fini, c'est une base de donnée qui à 
vocation à être réutilisée. Et ceux qui la réutilise pour la diffuser en bout 
de chaîne sont en situation de risque juridique avec des données litigieuses.


>  En effet, dans la culture montagnarde, l'altitude d'un sommet, col, refuge
>  est importante et fait quasiment partie du nom du sommet 
Je commence à penser (comme l'expliquait Eric il y a peu) aussi que l'altitude 
n'est plus une donnée originale au sens de la loi, sur google, il y aura 
plein de site qui vont me donner l'altitude du crêt de la neige, et pourtant 
la provenance vient sans doute d'IGN, mais la connaissance de cette info et 
vieille comme la première ascension du sommet (ou presque)


>  Alors que l'altitude d'un sommet, c'est 4 chiffres, et quel que soit son
>  auteur, si elle est juste, il n'y a pas de raison de la modifier. 
Oui, je commence à revoir mes positions sur l'altitude.

Alors reste la position... je dis pas non, je dis pas oui... j'en sais 
rien ;-)

Mais je ne m'opposerais pas à un import avec la source=contributeurs camp2camp 
en bonne est dû forme pour revenir dessus en cas de problème avéré et pour 
respecter la licence tout en remerciant c2c

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

[OSM-talk-fr] Maintenir sa base OSM à jour

2009-05-26 Par sujet OSM Léon

Bonjour à tous,

J'ai probablement mal cherché sur Internet mais quelqu'un aurait il un
script simple pour maintenir sa base de données à jour à partir des fichiers
dits "daily diffs" ? Merci d'avance.

Thomas
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Corine Land Cover : nomenclature 2 4 "Zones agricoles hétérogènes"

Pieren a écrit :
> 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 plus difficile qui dessine des zones agricoles mixtes.
>
> * la classe 241 "Cultures annuelles associées aux cultures
> permanentes" est proposée sur le wiki en "landuse=farm" alors que la
> description plus détaillée dit "Cultures temporaires (terres arables
> ou prairies) en association avec des cultures permanentes sur les
> mêmes parcelles.". Donc cela pourrait aussi bien être
> "landuse=meadow". La solution pourrait être de suivre l'exemple de la
> classe 121 et taguer avec "landuse=farm;meadow" et une note
> explicative.
>
> * la classe 242 "Systèmes culturaux et parcellaires complexes" est
> sous-titrée "Juxtaposition de petites parcelles de cultures annuelles
> diversifiées, de prairies et / ou de cultures permanentes complexes.".
> Là aussi, je proposerais la même solution que pour la classe 241 avec
> "landuse=farm;meadow" et une note explicative.
>
> * la classe 243 "Surfaces essentiellement agricoles, interrompues par
> des espaces naturels importants" est délicate à traduire. C'est
> majoritairement agricole mais on prend un risque à mettre
> "landuse=farm", qui confondrait la zone avec du terrain purement
> agricole comme dans la catégorie 21. De plus, on masquerait les
> espaces naturels apparemment trop petits pour mériter leur propre
> polygone (mais qui pourraient porter un tag "natural").
>
> * la classe 244 "Territoires agro-forestiers" avec le sous-titre
> "Cultures annuelles ou pâturages sous couvert arboré composé d'espèces
> forestières" n'a pas d'équivalent direct dans OSM. Je n'ai pas trouvé
> d'exemple sur la carte et je ne sais pas à quelle densité de forêt on
> fait référence. Est-ce suffisamment dense pour parler de
> "landuse=forest" ?
>
> Pieren
>   
Voila la partie difficile : traiter l'hétérogène

le 241, c'est, par exemple, du orchard et meadow, ou du orchard et farm
sur une même parcelle (peu de chance qu'il y ait des carottes au milieu
de la vigne). On  du constant : orchard et du variable : meadow/farm et
du mélange des deux. On peut mettre "landuse=orchard;farm;meadow" avec
la note ? Mais pour aboutir à terme à quel(s) tag(s) OSM ? Le doute est
sur "farm/meadow" pas sur le caractère composite qui devra demeurer.

le 242, c'est des parcelles intriquées en orchard , farm et meadow,
polygone qui a vocation à être découpé, détaillé, précisé. On sait vers
quoi on va.

Le 243, comme le 242, il a vocation à être éclaté. Je verrai bien
"landuse=farm;forest" avec note.

Le 244, d'accord pour le "landuse=forest" le tag CLC:code permettra
d'aller plus loin, plus tard, quand on saura gérer la complexité.

Vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Corine Land Cover : nomenclature 14 " Espaces verts artificialisés, non agricoles"

2009-05-26 Par sujet Julien D.

>
> Faudra mettre des GPS sur les Formule 1 pour mapper les circuits...
>

Pas forcément : pour les *24h du Mans Rollers* et on peut participer à la
parade d'ouverture sur le circuit
Bugattipour
5€ et enregistrer les traces personnellement :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Corine Land Cover : nomenclature 23 "Prairies"

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.
>
> La catégorie 23 est assez simple. Elle ne contient qu'une seule classe
> qui devrait faire consensus. Mais bon, j'en parle quand même pour le
> principe.
>
> * la classe 231 "Prairies" est proposée sur le wiki en
> "landuse=meadow" qui est déjà assez largement utilisé (2700 sur
> l'Europe d'après tagwatch) et documenté dans Map Features.
>
> Pieren
>   
+1
Vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Corine Land Cover : nomenclature 1 4 "Espaces verts artificialisés, non agricoles"

Pieren a écrit :
> 2009/5/23 Pieren :
>
>   
>> * la classe 141 "Espaces verts urbains" est proposée sur le wiki en
>> "landuse=village_green" ou "leisure=park". Je pense que village_green
>> n'est pas approprié car c'est une notion typiquement anglaise.
>> "leisure=park" peut coller mais un exemple que je vois dans la région
>> de Mulhouse montre que cela s'applique aussi à des zones agricoles ou
>> de forêts proche de la ville mais qui ne sont pas des parcs. Donc je
>> ne sais pas.
>>
>> * la classe 142 "Équipements sportifs et de loisirs" est proposée sur
>> le wiki en "leisure=sports_centre", "leisure=park" ou
>> "landuse=recreation_ground". Les quelques exemples que j'ai rencontré
>> montrent que cette classe est un peu fourre-tout et se trompe aussi.
>> Je proposerais de ne pas l'importer.
>>
>> 
>
> J'ai encore un peu examiné ces deux classes. J'ai aussi trouvé un
> hippodrome en 142 comme un golf et un circuit automobile. Le 141 se
> retrouve sur les grands parcs en ville ou à côté mais on voit aussi
> l'imprécision des polygones qui débordent largement sur les zones
> résidentielles voisines. Comme les parcs sont souvent déjà tagués dans
> OSM et avec une meilleure précision, je proposerais donc d'abandonner
> ces deux classes.
>
> Pieren
Bien d'accord, ce sont, en général des éléments bien identifiés (pour
les stades) faciles à parcourir (pour les parcs) donc facile d'obtenir
des traces gpx qui permette de repérer les parcelles cadastrales, donc
faciles à saisir au cadastre.

Ces éléments urbains, ou péri-urbains, sont dans des zones denses du
point de vu cartographique : l'imprécision de CLC (polygone et code)
devient un handicap.

S'ils sont stockés dans un dépôt (comme les zones à conflit), peut-être
qu'il pourront servir à expliquer les trous dans la carte, donc à
orienter la recherche : je n'ai pas les outils, les compétences, pour
faire une extraction sur CLC... Bon c'est une idée en l'air

Faudra mettre des GPS sur les Formule 1 pour mapper les circuits...

Vincent


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Des données libres pour la montagn e pour bientôt


> Une relecture du Code de la Propriété Intellectuelle s'impose.
(...)
> Dire, dans OSM, que le Mont-Blanc est situé à 4810 m. d'altitude n'est 
> pas un violation du droit d'auteur de l'IGN (quand bien même il est seul 
> habilité à en déterminer l'altitude) 

Oui, mais au regard du droit sur les constitutions de bases de donnée, c'est 
déjà plus délicat.

Tous ceux qui ont tenté de "pomper" la base des pages jaunes par exemple pour 
obtenir les adresses et nom, certes, il aurait été possible de le faire "sur 
le terrain", mais le résultat est que ça c'est mal fini.

on revient sur l'histoire de citation, je publie un bouquin et dedans 
j'indique la position et l'alti données par IGN de 50 sommets, je pense que 
tout ira bien.

Maintenant je duplique la base sommet de l'IGN sur toute la france et... je 
publie une carte de substitution (au hasard, osm) et ça risque d'aller 
beaucoup moins bien.

La parano me semble alors assez justifiée dans l'état actuel de notre 
fonctionnement en société au regard du droit et du nombre de dossier traités 
par les magistrats sur ce thème !

-- 
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] Un bruit qui court...

2009-05-26 Par sujet Mathieu Arnold

+--On 26 mai 2009 01:06:25 +0200 Vincent Pottier  wrote:
| Mois aussi.
| Mai je ne trouve plus le timestamp du test.

+1 (et +s).


-- 
Mathieu Arnold

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Utiliser une relation de type route pour décrire un way


> Moi, je rêve d'une relation "river" qui puisse inclure les morceaux de
> chemin (waterway=river) qui indiquent le flux, la navigabilité..., les
> polygones (waterway=riverbank) qui décrivent sa surface et ses rives
> (baignable... ), ses accidents (barrage...) et qui permette de placer le
> nom ailleurs que sur la terre ferme dans les boucles.
> Un cas de 'route' ?

pas de chance, mais le mot route n'est pas le mieux choisi, de par son 
ambiguïté dans notre langue. 
Mais je ferais du "..." noté dans  
route=road / bicycle / foot / hiking / bus / ferry /pilgrimage / detour / 
railway / tram / mtb (mountainbike) / roller_skate / running / horse / ...

un river ou river_way (pourquoi exclure les ruisseaux) que ça ne me paraîtrait 
pas illogique

Collected_Ways avait le mérite de bien donne la teneur générique de la 
relation
-- 
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] Utiliser une relation de type route pour décrire un way

On Monday 25 May 2009 23:49, Etienne T wrote:
> Honnetement, mais après, je suis loin d'être expert OSM, mais je trouve
> l'idée de Sly pas mal. Beaucoup de route non pas de tag ref, ou alors lors
> de la dénationnalisation des routes de France il y a quelques années, les
> relations simplifient le travail. 
ça c'est l'argument du fainéant ;-) Mais c'est déjà (un peu) valable selon 
moi. 
L'aspect intéressant est l'augmentation de la cohérence, moins d'erreur 
possible sur ref, name, etc. si on doit les recopier autant de fois qu'il y a 
de way.

> C'est qu'un exemple bidon que j'ai pu trouvé, mais si par exemple j'ai envie
> d'obtenir le fichier gpx de la LGV ? Pas facile quand se sont que des petits
> bouts. 

C'est l'autre aspect qui me semble très intéressant. A la question, "quelle 
est la longueur du rhône", l'algorithme de regoupement par nom,type et noeud 
de jonction est assez délicat. Possible, mais délicat. 
La relation peut rendre ça plus simple.


> Après, si c'est pas le but d'une relation "route", je veux bien changer, il
> n'y a aucun soucis. Faut-il créer les relation de type "way" ? :p Ou alors
> qu'est-ce qu'on peut faire pour représenter ce que j'ai envie ? (je sais
> bien que je suis pas le seul, mais on a le droit d'émetre des idées).   
route me semble bien, et le gros avantage, c'est que si on doit changer pour 
une des autres propositions, il n'y a que les tags de la relation à changer.

-- 
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] Cohérence des voiries, mises à jour / modération

2009/5/26 Etienne T :
> Mais il faut avouer que défois, cela reste ambigu. Ou alors il faudrait
> définir les termes utilisés.
>

N'hésitez pas à intervenir sur la page wiki ou dans la partie
discussion (ou ici) pour améliorer ce qui doit l'être. Cette page est
un mixte de traduction de la page allemande qui était la plus avancée
à l'époque et de nos pratiques en France. Elle n'a pas subie beaucoup
de retouches sur le fond depuis sa création.
Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Utiliser une relation de type route pour décrire un way

> De plus, il faut conserver le tag principal highway ou railway sur le
> way lui-même. 
Ce sont les usages en cours...

> Cette idée de vouloir tout transférer dans la relation 
> vient de Sly uniquement, qui en a fait une idée fixe lorsqu'il est
> arrivé sur le projet mais il est bien le seul à raisonner de cette
> manière au niveau international. 

hopopop ! C'est que je suis un précurseur voilà tout ;-)
Vu les réponses, d'autres commencent à voir l'intérêt que cela peut 
représenter.

Sinon, pas de désinformation, le sujet chauffe depuis un moment et la seule 
chose dont on est sûr, c'est que c'est pas simple :
http://wiki.openstreetmap.org/wiki/Relation:route
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street

( les idées vont loin et certaines propositions ne se limitent pas aux rails, 
aux autoroute et au chemins de randos regroupés mais impliquent tout ce qui 
peut aurait contenu 2 way ou plus du même nom/ref/paramètre )

Je pense que le premier frein c'est la complexité que cela implique ensuite à 
tagger. Actuellement les primitives de OSM on les taguent direct dans 
JOSM/potlatch, ça implique qu'il faut comprendre ce qui se passe et forcément 
c'est chiant, si l'editeur faisait le boulot, ça ne poserait plus de 
problème.

Mais faut pas aller trop vite, les solutions viendront après les problèmes.
(ce qui ne m'empêche pas de tagguer de temps en temps comme ça histoire de 
montrer que ce n'est pas que virtuel )

> Et je regrette que ces commentaires 
> induisent d'autres personnes en erreur. Même en amendant le forum, il
> y aura toujours des gens comme toi qui ne liront pas le topic en
> entier...
Alors j'ai mis un message clair juste avant que je n'ouvre ma gueule ;-)



-- 
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] Des données libres pour la montagn e pour bientôt

2009-05-26 Par sujet Etienne T

 >Nous avons l'accord de Swisstopo pour diffuser ces coordonnées sous licence 
 >libre  :

On doit pouvoir importer les sommets Suisse alors, non ?

Concernant le placage des points avec l'aide de la NASA, je suis d'accord, cela 
peut aider. Un plugin pour JOSM serait le bienvenue peut-être. On en a parlé du 
début du fil. Cela serait utile pour voir si les routes ont bien placés en 
regardant si la forme colle avec le relief. Bien sur, à prendre avec modération 
à mon avis : les données SRTM nesont pas toujours précise. Mais c'est mieux que 
rien pour aider.

Je préfere la carte 
http://opencyclemap.org/?zoom=10&lat=46.04953&lon=6.96464&layers=000B00
 beaucoup moins pixelisé que la version Hiking ;-)

--- En date de : Mar 26.5.09, Stéphane Brunner  a 
écrit :

De: Stéphane Brunner 
Objet: Re: [OSM-talk-fr] Des données libres pour la montagne pour bientôt
À: "Discussions sur OSM en français" 
Date: Mardi 26 Mai 2009, 9h11

Hello !

On peut aussi les placer d'après les donnée SRTM, cela prend un peux
de temps à trouver le sommet, mais cela doit être assez précis !
http://beta.letuffe.org/?zoom=10&lat=46.04953&lon=6.96464&layers=000B00

CU
Stéphane


2009/5/25 Pieren :
> 2009/5/25 Frédéric Bunoz :
>> Les coordonnées des sommets suisses ont été relevées pour la plupart sur les
>> cartes Swisstopo. Nous avons l'accord de Swisstopo pour diffuser ces
>> coordonnées sous licence libre  :
>>
>> Vous pouvez utiliser et publier sans outre les coordonnées de points des
>> Cartes nationales.
>> Ces données sont libres de droits et aucune autorisation n'est nécessaire.
>>
>
> Ca fait rêver ;-) Malheureusement, en France, l'IGN n'a pas le même
> altruisme (ni peut-être les moyens) qu'en Suisse.
> Je pense aussi que les altitudes sont du domaine public mais quid des
> positions ? Si vous les placez à partir d'images yahoo et/ou des
> lignes de contours, pourquoi pas. Mais je ne pense pas qu'on puisse
> utiliser les cartes de l'IGN pour ça. Sinon pourquoi se l'autoriser
> pour les sommets et pas pour les routes, les lacs, etc ?
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Stéphane Brunner
mail : stephane.brun...@gmail.com
messageries instantanées : stephane.brun...@gmail.com (http://talk.google.com)
--
Un peu d'espace qui vous suis partout -
https://www.getdropbox.com/referrals/NTk2OTU2Mjk
--
http://framasoft.net - Annuaire de logiciel libre

___
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 2 4 "Zones agricoles hétérogènes "


> * la classe 241 "Cultures annuelles associées aux cultures
> permanentes" 

Cette classe m'a l'air un peu le fourre tout de CLC pour englober les surfaces 
trop petites pour obtenir leur propre tag et pour dire :
"y'a un peu d'arbres ou y'a un peu de tout"

ça me semble bien vague, je me prononcerais plutôt pour pas d'import de cette 
classe plutôt que de conserver dans osm des 
landuse=farm;meadow;forest;orchard car finalement c'est un regroupement de 
plusieurs cultures difficile à différencier par leurs photos d'avion

-- 
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] Utiliser une relation de type route pour décrire un way

2009-05-26 Par sujet Etienne T

>tu parles de ça ? : 
>
> (faut dézoomer et attendre un peu que ça se 
>charge)
>Bon d'accord c'est pas trop fait pour mais ça affiche. D'ailleurs faudrait 
>faire 
>du ménage parce que 34 morceaux ça fait beaucoup.

J'aime découvrir des liens comme çà. Même si c'est peut-être pas trop fait 
pour, ca marche pour visualiser une relation en grand. ;-)

Pour faire le ménage, cela ne tient qu'à nous de faire la relation ne contenir 
que 2 extremités : 1 node à Saint-Brévin les pins à l'océan Atlantique, et un 
autre à la frontière Franco Allemande vers Bâle. Bon, je suis d'accord, faut 
être motivé pour le faire :p
Dommage, je l'ai fait l'année dernière au départ de Baume les dames à côté de 
Besançon jusqu'à Saint-Nazaire : voir ma carte Google Maps (c'est une carte 
très grossière de mon itinéraire) Mais à l'époque (il y a 1 an déjà), je ne 
connaissais pas OSM. J'aurai pu cartographié toute la partie française :(

PS : on voit les ovnis de très près sur le lien donné à Orléans ! :s

--- En date de : Mar 26.5.09, Vincent MEURISSE  a 
écrit :

De: Vincent MEURISSE 
Objet: Re: [OSM-talk-fr] Utiliser une relation de type route pour décrire un way
À: talk-fr@openstreetmap.org
Date: Mardi 26 Mai 2009, 8h48

On Tuesday 26 May 2009 01:10:28 Etienne T wrote:
> Merci la relation 28 853 :
> http://www.openstreetmap.org/browse/relation/28853 Manquerait juste une
> carte à faire pour afficher la relation voulu sur une grande carte, mais
> ça, il ne manque que quelques lignes de codes, et chacun est libre de se
> pencher dessus. Merci OSM de pouvoir développer ce qu'on veut
tu parles de ça ? :  (faut dézoomer et attendre un peu que ça se 
charge)
Bon d'accord c'est pas trop fait pour mais ça affiche. D'ailleurs faudrait 
faire 
du ménage parce que 34 morceaux ça fait beaucoup.
-- 
Vincent MEURISSE

___
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] Comment taguer une voie de détress e ?

2009-05-26 Par sujet Jean-Francois Nifenecker

g.d a écrit :
> La proposition me semble être la bonne,
> surtout que le terme anglais/international est "escape lane",

C'est ainsi que c'est signalé sur l'autoroute A 89, dans la descente sur
Clermont-Ferrand.

-- 
Jean-Francois Nifenecker, Bordeaux

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Corine Land Cover : nomenclature 23 "Prairies"