date:20090526


 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.
Alors je répond, sans problème pour moi (pour le principe)

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

2009-05-26 Par sujet Etienne T

tu parles de ça ? : 
http://betaplace.emaitie.de/webapps.relation-analyzer/osm.jsp?relationId=28853
 (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 osm-talk...@meurisse.org a 
écrit :

De: Vincent MEURISSE osm-talk...@meurisse.org
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 ? : http://betaplace.emaitie.de/webapps.relation-
analyzer/osm.jsp?relationId=28853 (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] 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] 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=10lat=46.04953lon=6.96464layers=000B00
 beaucoup moins pixelisé que la version Hiking ;-)

--- En date de : Mar 26.5.09, Stéphane Brunner stephane.brun...@gmail.com a 
écrit :

De: Stéphane Brunner stephane.brun...@gmail.com
Objet: Re: [OSM-talk-fr] Des données libres pour la montagne pour bientôt
À: Discussions sur OSM en français talk-fr@openstreetmap.org
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=10lat=46.04953lon=6.96464layers=000B00

CU
Stéphane


2009/5/25 Pieren pier...@gmail.com:
 2009/5/25 Frédéric Bunoz frederic.bu...@camptocamp.org:
 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] 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] Cohérence des voiries, mises à jour / modération

2009/5/26 Etienne T gustrimai...@yahoo.fr:
 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

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

2009-05-26 Par sujet Mathieu Arnold

+--On 26 mai 2009 01:06:25 +0200 Vincent Pottier vpott...@gmail.com 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] 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] Corine Land Cover : nomenclature 1 4 Espaces verts artificialisés, non agricoles

Pieren a écrit :
 2009/5/23 Pieren pier...@gmail.com:

   
 * 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] 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 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
Bugattihttp://www.informationfreeway.org/?lat=47.95350849884392lon=0.21202504270713823zoom=15layers=0F0B0Fpour
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 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

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

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

Mathieu Arnold a écrit :
 +--On 26 mai 2009 01:06:25 +0200 Vincent Pottier vpott...@gmail.com 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] Un bruit qui court...

Etienne Chové a écrit :
 Mathieu Arnold a écrit :
   
 +--On 26 mai 2009 01:06:25 +0200 Vincent Pottier vpott...@gmail.com 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...

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 vpott...@gmail.com
| 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] 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...

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 vpott...@gmail.com
 | 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] Un bruit qui court...

2009-05-26 Par sujet Steven Le Roux

Bravo :)

2009/5/26 Mathieu Arnold m...@mat.cc



 +--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 vpott...@gmail.com
 | 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 ste...@le-roux.info
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

[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] 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.0711lon=9.0871zoom=14

2009/5/26 Axel R. a...@esperanto-jeunes.org

 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

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
Permalinkhttp://www.openstreetmap.org/?lat=48.063552lon=2.891757zoom=17
Browse http://www.openstreetmap.org/browse/node/323192555
Edit http://www.openstreetmap.org/edit?lat=48.063552lon=2.891757zoom=17
JOSMjavascript:openJOSM(2.888757,%2048.060552,%202.894757,%2048.066552,%20'node',%20323192555)
*amenity=*school
*name=*Ecole Maternelle Mot mal
écrithttp://osmose.openstreetmap.fr/cgi-bin/osmose.py?cookie=norun=yesusername=e701=on(École)
 node
323192555 Francois Audirac
Permalinkhttp://www.openstreetmap.org/?lat=48.063552lon=2.891757zoom=17
Browse http://www.openstreetmap.org/browse/node/323192555
Edit http://www.openstreetmap.org/edit?lat=48.063552lon=2.891757zoom=17
JOSMjavascript:openJOSM(2.888757,%2048.060552,%202.894757,%2048.066552,%20'node',%20323192555)
*amenity=*school
*name=*Ecole Maternelle Type de voie mal
écrithttp://osmose.openstreetmap.fr/cgi-bin/osmose.py?cookie=norun=yesusername=e702=on(École)
Es-ce normal ?

2009/5/25 Etienne Chové ch...@crans.org

 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] 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 
 http://www.openstreetmap.org/?lat=48.063552lon=2.891757zoom=17
 Browse http://www.openstreetmap.org/browse/node/323192555
 Edit http://www.openstreetmap.org/edit?lat=48.063552lon=2.891757zoom=17
 JOSM 
 javascript:openJOSM(2.888757,%2048.060552,%202.894757,%2048.066552,%20'node',%20323192555)
  
   *amenity=*school
 *name=*Ecole Maternelle   Mot mal écrit 
 http://osmose.openstreetmap.fr/cgi-bin/osmose.py?cookie=norun=yesusername=e701=on
  
 (École)
 node 323192555Francois AudiracPermalink 
 http://www.openstreetmap.org/?lat=48.063552lon=2.891757zoom=17
 Browse http://www.openstreetmap.org/browse/node/323192555
 Edit http://www.openstreetmap.org/edit?lat=48.063552lon=2.891757zoom=17
 JOSM 
 javascript:openJOSM(2.888757,%2048.060552,%202.894757,%2048.066552,%20'node',%20323192555)
  
   *amenity=*school
 *name=*Ecole Maternelle   Type de voie mal écrit 
 http://osmose.openstreetmap.fr/cgi-bin/osmose.py?cookie=norun=yesusername=e702=on
  
 (É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

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

2009/5/26 Axel R. a...@esperanto-jeunes.org:
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

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

2009/5/26 Emilie Laffray emilie.laff...@gmail.com:
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-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] 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] 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) sylv...@letuffe.org:
 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

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

2009/5/26 Pieren pier...@gmail.com:
 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] 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

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

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] 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] Corine Land Cover : nomenclature 2 4 Zones agricoles hétérogènes

2009/5/26 sly (sylvain letuffe) sylv...@letuffe.org:

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

[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=11lat=47.87759lon=2.0359layers=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] 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

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

2009-05-26 Par sujet Matthieu Lochegnies

2009/5/26 Axel Rousseau a...@esperanto-jeunes.org

 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)

2009-05-26 Par sujet Matthieu Lochegnies

2009/5/26 Matthieu Lochegnies matthieu.lochegn...@gmail.com

 2009/5/26 Axel Rousseau a...@esperanto-jeunes.org

 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] Key:enforcement

2009/5/26 Marc SIBERT m...@sibert.fr:

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

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

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

2009-05-26 Par sujet Matthieu Lochegnies

2009/5/26 Axel Rousseau a...@esperanto-jeunes.org

 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] 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 Matthieu Lochegnies matthieu.lochegn...@gmail.com:

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

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 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=11lat=47.87759lon=2.0359layers=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=15lat=47.87207lon=1.85735layers=B0FFTF

Il semble qu'il y ait d'autres problèmes.
http://beta.letuffe.org/?zoom=13lat=47.87207lon=1.85735layers=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] 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 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] 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 vpott...@gmail.com:
   
 '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 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

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 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 sylv...@letuffe.org:
 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

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

[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 vpott...@gmail.com
À : Discussions sur OSM en français talk-fr@openstreetmap.org
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] Encore plus de fichiers Corine

2009/5/26 Emilie Laffray emilie.laff...@gmail.com:
 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

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

2009/5/27 sylvain letuffe sylv...@letuffe.org:

 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

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

Pieren wrote:
 2009/5/26 Emilie Laffray emilie.laff...@gmail.com:
   
 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] 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

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

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

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

2009/5/27 Emilie Laffray emilie.laff...@gmail.com:
 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] 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] Key:enforcement