Re: [OSM-talk-fr] cimetière et religion
Bonjour, Pour continuer dans les exceptions, il y a l'Alsace et la Moselle, non soumises à la loi de 1905 (Strasbourg a d'ailleurs ouvert un cimetière musulman en 2012). Le ven. 27 juil. 2018 à 17:10, Topographe Fou a écrit : > Bonjour, > > Attention, il peut y avoir des exceptions françaises : carrés musulmans ( > https://fr.m.wikipedia.org/wiki/Carr%C3%A9_musulman), cimetières juifs > (ex : https://fr.m.wikipedia.org/wiki/Cimeti%C3%A8re_juif_de_Besan%C3%A7on), > cimetières de communautés religieuses (majoritairement chrétiennes dans le > cas français) et peut être aussi quelques autres cimetières privés > jouissant de dérogations ou de statuts pré-1905. > > Bref les lois ont évoluées depuis 1905. A tenir compte dans la mise à jour > de la page des cimetières. > > Dans le cas présent, je ne me suis pas renseigné mais il est probable que > ce soit un cimetière municipal ordinaire et donc sans confession (à > vérifier et sources si la confession est appropriée) > > Cordialement, > > LeTopographeFou > > Message original > De: pe...@adrieng.fr > Envoyé: 27 juillet 2018 2:32 PM > À: talk-fr@openstreetmap.org > Répondre à: talk-fr@openstreetmap.org > Objet: [OSM-talk-fr] cimetière et religion > > Bonjour, > > J'ai eu la surprise de voir un cimetière tagué avec une religion (catho) : > > https://www.openstreetmap.org/way/70372780#map=18/48.00631/6.71545 > > Or en France les cimetières sont des espaces laïques, par la loi de 1905 > (article 28) : > > « Il est interdit, à l'avenir, d'élever ou d'apposer aucun signe ou > emblème religieux sur les monuments publics ou en quelque emplacement > public que ce soit, à l'exception des édifices servant au culte, des > terrains de sépulture dans les cimetières, des monuments funéraires, > ainsi que des musées ou expositions. » > > > https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=LEGITEXT06070169=20180727 > > À mon sens, seule les tombes peuvent donc être marquées d'une religion, > mais en aucun cas le cimetière complet ! C'est d'ailleurs la position de > la Fédération de la libre pensée, confirmé par le Conseil d'État : > > > https://www.fnlp.fr/news/413/17/Croix-sur-les-parties-communes-des-cimetieres.html > > > Si personne n'y voit d'inconvénient, je compte donc corriger ce > cimetière, et indiquer clairement cette réflexion sur la page wiki > concernant le tag cimetière. Un test OSMOSE là-dessus comblerait à coup > sûr les défenseurs de la laïcité, mais c'est au delà de mes compétences… > > > Bonne journée > > Adrien > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [osm-alsace] name:gsw pour les noms régionals?
Bonjour Christine, Oui, le code "gsw" est utilisé pour l'alsacien, du moins pour sa forme alémanique. Il n'existe pas à ma connaissance de code ISO pour le francique (fränkisch). Voir http://www.loc.gov/standards/iso639-2/php/langcodes-keyword.php?SearchTerm=gsw=ALL=Go En tout cas, c'est ce que j'utilise pour les noms de rues en alsacien. Le sam. 7 juil. 2018 à 12:07, Christine Karch a écrit : > Bonjour, > > je veux faire un peu le "mapping" à Strasbourg et environs, aussi chez > nous à Kehl/Hanauerland, ou le dialecte est pareil. On voit sur les > panneaux de rue les noms régionals. J'ai déjà trouvé des examples comme > "name:gsw=Knowligass" pour Rue de L'Ail. etc. dans la base de donnés > d'OpenStreetMap. > > Je n'ai pas trouvé des examples à Kehl. Mais c'est sûr, qu'on > voudrais/devrais prendre le même tag. > > Ma question, c'est: on prend le tag "name:gsw" pour les noms régionals > sur ces panneaux de rues? Je demande parce que ne veux pas rater. > > Christine > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Démo Carnet de rando sur la crête des Vosges
Bravo pour le carnet. Toujours aussi bien le rendu R25. Pour répondre à vos interrogations sur les carrés rouges : le Vieil Armand est un champ de bataille de 14-18. Voir http://fr.wikipedia.org/wiki/Hartmannswillerkopf. Les sites taggués en tourism=attraction sont des ouvrages construits durant la guerre (lieux de vie des soldats, abris, postes d'observation, etc.). Je vais contacter le contributeur qui les a ajoutés. On devrait peut-être pouvoir trouver des tags plus appropriés dans historic=*. Le 21 avril 2015 21:59, JB jb...@mailoo.org a écrit : Le 21/04/2015 21:25, Yves Pratter a écrit : Bien cette idée de carnet, j’espère qu’elle va faire des petits dans d’autres régions :) Si tu as des envies, il suffit de faire ou de demander ! Seul bémol, la multitude de carrés rouges vers le *Vieil Armand* (carte 2). Si je lis bien la légende, il s’agit de Lieux ou éléments touristiques ou remarquables. Un peu déroutant. Tagguer pour le rendu… ben des fois, ça fait pas ce qu'on voulait. Je ne sais pas trop ce qui représenté là-bas, mais en tout cas, c'est bourré de tourism=attraction + name=*. Mais je sais pas trop ce que c'est, si c'est des statues/sculptures ou autres, mais je pense que le tag utilisé est pas forcément le meilleur (sur R25, les artwork sont rendus de manière moins violente). PS : en fait, la crête des Vosges avec OSM, ça existe déjà, j'ai découvert ça cet après-midi. Un premier tant attendu guide de cette crête est sorti, mais comme celui de la FFRP/CV tardait trop, il s'est fait doubler par un éditeur allemand qui a traduit son topo en français (d'après ce que j'ai compris). Le bouquin : https://www.rother.de/rother-titres%20francais-vosges%20-%20grande%20travers%E9e-4949.htm , un exemple de carte visible ici : https://www.rother.de/pdf/3763349499_tour.pdf , j'avais pas d'appareil photo sous la main, mais sur la dernière page, il est précisé que les 36 (?) cartes détaillées sont à partir de données CC-BY-SA OpenStreetMap (c'est pas impossible que la version allemande date d'avant le changement de licence), cartographie je me souviens plus quelle entreprise allemande… ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [osm-alsace] Re: Guebviller: nouveau plan de circulation...
Le 24 février 2015 21:11, DH dhel...@free.fr a écrit : Le 24/02/2015 19:11, Christian Quest a écrit : Pour info: http://france3-regions.francetvinfo.fr/alsace/2015/ 02/16/guebwiller-change-de-sens-tous-les-six-ans-656557.html Quelqu'un pour faire la mise à jour ? Ca semble changer le 4/3... Pour info, nous avons reçu un message sur le formulaire de contact venant des services de la ville pour signaler les changements et les répercuter dans OSM. Ca fait plaisir de voir qu'on pense naturellement à nous ! Je relaie sur la liste locale Alsace Denis Merci Denis, Habitant à quelques kilomètres et connaissant très bien Guebwiller, je veux bien m'en occuper, à moins évidemment qu'un non-abonné aux listes s'en charge d'ici là. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ajout de POI pas très bien géocodés par une agence de com
Je déterre un peu le sujet, mais il faut croire qu'ils n'ont toujours pas compris. Je viens de voir passer de nouveaux changesets, avec création de doublons géocodés à la hache. Par exemple ici une pizzeria au milieu d'une salle de cinéma, alors qu'un POI bien placé existe déjà en bordure du bâtiment. http://www.openstreetmap.org/changeset/26615194 Dans le même genre, on trouve des pizzerias en plein milieu de routes, comme ici une départementale: http://www.openstreetmap.org/changeset/26615762#map=18/44.90608/-0.48649 ou là: http://www.openstreetmap.org/changeset/26615247#map=18/49.43628/2.11475 Comme il y a un nœud par changeset, il va y avoir un peu de travail ... Christian, ils avaient répondu à ta prise de contact ? Le 22 septembre 2014 09:35, Romain MEHUT romain.me...@gmail.com a écrit : Le 20 septembre 2014 20:58, Christian Quest cqu...@openstreetmap.fr a écrit : Si c'est vraiment n'importe quoi, je pense qu'il ne faut pas hésiter à supprimer. J'ai déjà supprimé des données de ce genre sans me poser plus de question vu que Christian avait déjà pris contact avec eux pour leur demander d'améliorer leurs contributions... Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose Missing object kind sur Piste de ski
Il n'y a pas que les pistes de ski qui sont touchées par cette nouvelle
analyse, on trouve également des erreurs sur :
- les cols (mountain_pass=yes + name=*)
- les panneaux d'entrée d'agglomération (traffic_sign=city_limite + name=*)
- les panneaux d'information (information=* + name=*)
- les éléments d'un terrain de golf (golf=* + name=*)
Ceci est juste le retour d'un rapide tour d'horizon autour de chez moi. Il
doit y avoir plein d'autres cas.
Bref, la liste des tag principaux est potentiellement bien plus longue
que celle supportée actuellement.
Le 18 octobre 2014 14:07, Yves Pratter yves.prat...@gmail.com a écrit :
Le 18 oct. 2014 à 13:44, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :
L'erreur devrait donc être : Objet nommé dont un tag indispensable
n'existe pas »
ou « tag manquant pour un objet nommé »
Osmose considère que seul les objets avec les attributs suivants peuvent
être nommés :
- aerialway
- aeroway
- amenity
- barrier
- boundary
- building
- craft
- emergency
- geological
- highway
- historic
- landuse
- leisure
- man_made
- military
- natural
- office
- place
- power
- public_transport
- railway
- route
- shop
- sport
- tourism
- waterway
Pour les pistes de ski, il y a l’attribut *piste:type* mais pas *type*.
Il faut donc rajouter piste:type à la liste… ou rajouter un mécanisme qui
recherche les attributs se terminant par *:type.
Le 18 oct. 2014 à 11:30, Yves Pratter yves.prat...@gmail.com a écrit :
J’essai de comprendre le code mais ce n’est pas très clair (en comparaison
à d’autres erreurs):
Donc si l’objet à l’attribut « name » et que son parent ne serait pas
nommé ?? (je ne pige pas la seconde condition)
if tags.get(name) and len(key_set self.name_parent) == 0: err.append((
21101, 1, {}))
En fait, l’erreur est produite si un objet OSM à un attribut *name* et
qu’il n’a aucun des attributs suivants : *type*, *aerialway*…
Donc, le message pourrait être *« tag manquant pour un objet nommé » *
—
Yves
*key_set *est la liste des attributs de l’objet.
*self.name_parent* est la liste des objets/attributs qui peuvent être
nommé
self.name_parent = set(('type', 'aerialway', 'aeroway', 'amenity',
'barrier', 'boundary', 'building', 'craft', 'emergency', 'geological',
'highway', 'historic', 'landuse', 'leisure', 'man_made', 'military',
'natural', 'office', 'place', 'power', 'public_transport', 'railway',
'route', 'shop', 'sport', 'tourism', 'waterway'))
len(key_set self.name_parent) == 0
indique l’appartenance cf. A⊆B cf. Utilisation avancée des listes en
Python
http://fr.openclassrooms.com/informatique/cours/utilisation-avancee-des-listes-en-python
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose Missing object kind sur Piste de ski
Après vérification du wiki, il faudrait en effet que information=* soit
accompagné de tourism=information.
En revanche mountain_pass=yes ne nécessite rien d'autre. Pour golf=* le
wiki ne dit pas qu'il doit être ajouté à sport=golf par exemple.
Et en ce qui concerne traffic_sign=city_limit, là non plus il n'est pas
précisé qu'il doit être ajouté à autre chose. En non, il ne doit pas être
nécessairement sur du highway, mais à l'emplacement physique du panneau,
qui est en général à côté de la voirie, comme indiqué dans le wiki. Taginfo
indique également qu'aucun des quelque 100 000 nœuds
traffic_sign=city_limit n'est actuellement accompagné de highway=*.
Donc en dehors de information=*, Osmose ne devrait pas lever d'erreurs sur
ces objets (en tout cas pas si on s'en tient aux usages actuels).
Le 18 octobre 2014 15:22, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :
L'ensemble de ces clé doivent normalement être membre des clés
précédemment cités (explicite ou implicite)
*traffic_sign *n'est pas cité dans la page principale mais *traffic_signal
*oui
ne doit t'on pas mettre :
*highway=traffic_sign *en plus?
même cas pour *information*:
*highway=information*
*tourism=information*
*etc...*
Je pense que rajouter n'est pas forcément juste. Sinon il faut considérer
qu'il y a des nouveau types principaux.
Si ce sont des type implicites il faut pouvoir vérifier leurs
correspondance avec l'une des clés principales.
Exemple pour les trafic_sign il faut forcément qu'ils soit sur du highway
parcontre un panneau d'information est quand à lui positionné sur des
parcelles privé et non sur la voirie.
A la base le modèle est en XML. N'y a t-il pas un schéma XSD ou JSON?
en json on peut analyser le contenu avec un correspondance à un schema
https://pypi.python.org/pypi/jsonschema
On pourra aussi proposer via ça des listes de balises connexes manquantes
Le 18 octobre 2014 14:32, Matthias Dietrich eiger@gmail.com a écrit
:
Il n'y a pas que les pistes de ski qui sont touchées par cette nouvelle
analyse, on trouve également des erreurs sur :
- les cols (mountain_pass=yes + name=*)
- les panneaux d'entrée d'agglomération (traffic_sign=city_limite +
name=*)
- les panneaux d'information (information=* + name=*)
- les éléments d'un terrain de golf (golf=* + name=*)
Ceci est juste le retour d'un rapide tour d'horizon autour de chez moi.
Il doit y avoir plein d'autres cas.
Bref, la liste des tag principaux est potentiellement bien plus longue
que celle supportée actuellement.
Le 18 octobre 2014 14:07, Yves Pratter yves.prat...@gmail.com a écrit :
Le 18 oct. 2014 à 13:44, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :
L'erreur devrait donc être : Objet nommé dont un tag indispensable
n'existe pas »
ou « tag manquant pour un objet nommé »
Osmose considère que seul les objets avec les attributs suivants peuvent
être nommés :
- aerialway
- aeroway
- amenity
- barrier
- boundary
- building
- craft
- emergency
- geological
- highway
- historic
- landuse
- leisure
- man_made
- military
- natural
- office
- place
- power
- public_transport
- railway
- route
- shop
- sport
- tourism
- waterway
Pour les pistes de ski, il y a l’attribut *piste:type* mais pas *type*.
Il faut donc rajouter piste:type à la liste… ou rajouter un mécanisme
qui recherche les attributs se terminant par *:type.
Le 18 oct. 2014 à 11:30, Yves Pratter yves.prat...@gmail.com a écrit :
J’essai de comprendre le code mais ce n’est pas très clair (en
comparaison à d’autres erreurs):
Donc si l’objet à l’attribut « name » et que son parent ne serait pas
nommé ?? (je ne pige pas la seconde condition)
if tags.get(name) and len(key_set self.name_parent) == 0: err.append
((21101, 1, {}))
En fait, l’erreur est produite si un objet OSM à un attribut *name* et
qu’il n’a aucun des attributs suivants : *type*, *aerialway*…
Donc, le message pourrait être *« tag manquant pour un objet nommé » *
—
Yves
*key_set *est la liste des attributs de l’objet.
*self.name_parent* est la liste des objets/attributs qui peuvent être
nommé
self.name_parent = set(('type', 'aerialway', 'aeroway', 'amenity',
'barrier', 'boundary', 'building', 'craft', 'emergency', 'geological',
'highway', 'historic', 'landuse', 'leisure', 'man_made', 'military',
'natural', 'office', 'place', 'power', 'public_transport', 'railway',
'route', 'shop', 'sport', 'tourism', 'waterway'))
len(key_set self.name_parent) == 0
indique l’appartenance cf. A⊆B cf. Utilisation avancée des listes en
Python
http://fr.openclassrooms.com/informatique/cours/utilisation-avancee-des-listes-en-python
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk
Re: [OSM-talk-fr] Osmose Missing object kind sur Piste de ski
Je reprends également point par point. Je ne comprends pas groupe comme étant le tag principal, mais simplement la catégorie en quelque sorte. D'ailleurs le lien ne pointe pas vers la clé highway, mais sur une page listant tout ce qui concerne la voirie. Soit nous ne parlons pas de la même chose, soit tu extrapoles ce que dit le wiki. Pour mountain_pass, le noeud doit certes se trouver sur un way highway=*, mais le noeud en lui-même ne doit pas porter un quelconque highway=*. C'est cette soi-disant erreur que rapporte Osmose. Pour traffic_sign, relis la partie qui explique comment le taguer sur un noeud. *As a **separate* *node* Create a separate node beside the road at the position of the actual sign. Et si tu regardes le tableau en dessous dans le wiki, pour traffic_sign=city_limit seul le cas d'un noeud est prévu. Cela n'aurait aucun sens sur un way, à moins de micro-tagguer les dimensions du panneau ... Regarde également dans le panneau de droite les useful combinations. La clé highway n'y est pas citée. Enfin, et j'arrêterai là, ces façons de tagguer les cols et les panneaux d'agglomération existent depuis longtemps, c'est ce que je voulais dire en citant les chiffres de taginfo. Taginfo reflète avant tout la pratique des contributeurs. Avec parfois des incohérences certes, mais jusqu'à aujourd'hui, on y apprend que personne n'a ajouté de tag highway=* à mountain_pass ou à traffic_sign=city_limit. Qu'on veuille les changer, pourquoi pas, mais cela doit passer par une discussion sur tagging ou autres. Ce n'est pas à Osmose d'imposer une nouvelle interprétation. Personnellement je me moque royalement de devoir ajouter du highway=* ou pas à ces noeuds s'il y'a un consensus pour le faire, parce que certains trouvent ça plus clair. Ce qui me dérange, c'est qu'Osmose rapporte comme erreur ce qui est la pratique majoritaire, documentée et établie depuis longtemps. Le 18 oct. 2014 22:44, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : @Matthias Dietrich je vais juste reprendre point par point *Après vérification du wiki, il faudrait en effet que information=* soit accompagné de tourism=information. * En effet c'est précisé ici http://wiki.openstreetmap.org/wiki/FR:Key:information PS: quand dans la boite à droite c'est écrit G*roupe : ** c'est que le groupe est le tag principal il me semble *En revanche mountain_pass=yes ne nécessite rien d'autre. Pour golf=* le wiki ne dit pas qu'il doit être ajouté à sport=golf par exemple. * Ça c'est pas vrai! Premièrement, Pour *mountain_pass *c'est considéré comme attribut d'un highway donc il manque aussi un tag! La doc anglaise dit http://wiki.openstreetmap.org/wiki/Map_Features: *Applies to the highest node on a highway = motorway/secondary/footway/... (could be any appropriate highway):* Donc highway=* est indispensable Et en ce qui concerne traffic_sign=city_limit, là non plus il n'est pas précisé qu'il doit être ajouté à autre chose. En non, il ne doit pas être nécessairement sur du highway Humm Il me semble que la page dit que c'est un membre du groupe highway. Donc highway est indispensable avec highway=traffic_sign! C'est un manque du wiki est j'espère que ce sera traité comme tel. mais à l'emplacement physique du panneau, qui est en général à côté de la voirie, comme indiqué dans le wiki. oui est non : *It is possible to use a node which is part of a way, or to create a separate node beside the road. Both methods are used in practice.* Taginfo indique également qu'aucun des quelque 100 000 nœuds traffic_sign=city_limit n'est actuellement accompagné de highway=*. Pour moi c'est une connerie du au fait que ce ne soit pas précisé dans le wiki! traffic_sign peut être correspondre à tout les élèments ou partie de voirie. dans un way dans tous les cas tu auras un highway. Donc dans les noeud isolé pour être cohérent il faut ajouter *Donc en dehors de information=*, Osmose ne devrait pas lever d'erreurs sur ces objets (en tout cas pas si on s'en tient aux usages actuels). * *Taginfo indique également qu'aucun des quelque 100 000 nœuds traffic_sign=city_limit n'est actuellement accompagné de highway=*.* Cela peut aussi être du à un manque dans le wiki... Taginfo ne remonte que la manière dont c'est utilisé et pas les incohérence sur l'utilisation. Si c'est pas claire tout le monde fera n'importe quoi et on le voit sur d'autre tags. Si j'en corrige 75000 highway=traffic_sign , considèrera-t-on que c'est ça qu'il faut faire? Bref Taginfo permet de savoir combien on a de saisie ou de comparer des mode de saisie mais pas de dire que c'est bien ou non. Au moins on sait que 10 noeud seront à revoir... traffic_sign est une restriction doit-on ajouter des tags restriction pour avoir une catégorie principale... ou complètement ignoré les restrictions du test... Voir: http://wiki.openstreetmap.org/wiki/Map_Features Le 18 octobre 2014 20:00, Matthias Dietrich eiger@gmail.com a écrit
Re: [OSM-talk-fr] Sport=climbing pour escalade sur falaises et arêtes
Bonjour, JOSM voudrait voir sport=* associé à un élément physique sur lequel ou dans lequel un sport est pratiqué. C'est ce que dit le wiki, où on trouve une liste d'objets associés: http://wiki.openstreetmap.org/wiki/Key:sport Les natural=cliff, natural=arete, natural=couloir ou natural=stone n'y figurent pas. Maintenant pour répondre à ta question, en ce qui me concerne je mets sport=climbing sur ce qui va bien, et je laisse JOSM râler. Matthias Le 30 août 2014 18:06, Pierre Knobel pierr...@gmail.com a écrit : Bonjour, J'ai du mal à comprendre sur quels objets on peut rajouter sport=climbong. JOSM me donne une erreur sport without physical feature quand je rajoute ce tag sur une falaise ou une arête. Exemples : https://www.openstreetmap.org/way/300954193 (école d'escalade sur falaise) https://www.openstreetmap.org/way/300954192 (arête avec passages d'escalade : http://www.camptocamp.org/routes/55445/fr/l-ecoutoux-l-arete-a-jojo) Comment est-ce que vous faites ? Pierre ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] combien d'adresses en Alsace ?
Le 11 janvier 2014 12:06, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Pour l'opendata et Mulhouse, quelqu'un a importé les arbres ? J'avais regardé les données, c'était impeccable. Il faut simplement s'accorder sûr une référence pour pouvoir tenir à jour les données. Pour les adresses, je vais jeter un œil, mais j'avai peu compos la dernière fois... Les arbres n'ont pas été importés à ce jour, mais tu as raison, sur l'échantillon que j'ai observé de plus près, ils sont très bien placés. Pour ce qui est de la référence, elle est fournie dans les données de la M2A. Chaque arbre porte un numéro. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] combien d'adresses en Alsace ?
Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Quelle est la règle actuelle ? REF:FR:M2A ? Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir ref:FR:M2A. Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de référence. Les stations Vélocité ont été importées depuis plus longtemps à partir des fichiers mis à disposition par JCDecaux, avec un simple ref=numéro de station. La plupart des autres objets n'ont pas de d'identifiant. Pour parler concrètement : est-ce que tu souhaites procéder à l'import des arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs disponibles (diamètre de la couronne, etc.). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
Le 29 décembre 2012 10:41, Christophe Merlet red...@redfoxcenter.org a écrit : Cela signifie t'il que du jour au lendemain, ce chemin deviendra une propriété intellectuelle et oeuvre de l'esprit de la FFRP et qu'OpenStreetMap devra l'effacer de sa base de données ? En tout cas, comme je l'ai déjà dit, hors de question en ce qui me concerne de cautionner ce genre d'interprétation, le Chemin Henri IV restera dans la base, même s'il devient un GR ! Bien que je sois plutôt partisan de la prudence en ce qui concerne les GR, dans ce cas précis, je ne vois pas ce que la FFRP viendrait réclamer. Le tracé existe depuis longtemps, ils ne pourront pas se prévaloir d'avoir créé l'itinéraire. Dans le même genre, on peut penser au GR 70, reprenant plus ou moins le chemin de R.L. Stevenson à travers les Cévennes. La FFRP n'a fait qu'apposer son label sur une idée existante. J'imagine difficilement un juge reconnaître la paternité de la FFRP sur cet itinéraire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Loire-atlantique et GR - Lettre ouverte à la FFRP ?
Le 29 décembre 2012 12:34, Philippe Verdy verd...@wanadoo.fr a écrit : Tout à fait d'accord. Ce genre d'appropriation exclusive des droits communs des autres est un abus qui ne doit pas être toléré. Même si la mention GR ne figure pas dans la base (si on admet alors que c'est juste un label propriétaire, que seule la FFRP peut décerner, il restera que ces chemins ne lui appartiennent pas, et qu'ils auront été construits/balisés et relevés sur le terrain par d'autres). Sinon demain je déclare que les autoroutes françaises m'appartiennent parce que je vais décider de les appeler toutes autostrades avec ma propre numérotation. En quoi cela devrait changer le droit de mentionner les autoroutes existantes ? Laissons à la FRPP sa nomenclature GR, utilisons une nomenclature générique internationale, et tant pis pour les numéros de GR, on n'a rien à effacer. Ton analogie n'est pas correcte : ce n'est pas un problème de nomenclature. Tu peux renommer les GR si tu veux, tu éviteras simplement l'emploi de la marque déposée GR. Le cœur du problème, c'est l'itinéraire en lui-même (le fait de suivre une liste précise de chemins ou de tronçons de chemins). L'itinéraire en lui-même peut être revendiqué comme œuvre de l'esprit. Après est-ce que chaque GR est une œuvre de l'esprit de la FFRP ? Seul la justice pourrait répondre. C'est bien là qu'est l'incertitude concernant cette histoire de GR. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Motorroad en France?
En effet, le cas 3 limité à 110 existe également. Exemple : La RD83, ex-N83, dans le Haut-Rhin et une partie du Bas-Rhin est une 2x2 voies limitée à 110 km/h mais non classée voie express. Il y a même un giratoire au niveau de Soultz/Bollwiller. On y retrouve de temps en temps des tracteurs, ce qui provoque d'ailleurs régulièrement des accidents dus à la différence de vitesse, mais ceci est un autre débat. Elle est aujourd'hui classée en trunk, et je trouve que ça correspond bien à son importance parmi les routes locales. Les autres primary ont nettement moins de trafic. Si on devait classer cette route en primary, je ne vois pas bien comment on pourrait signaler son importance. Le 18 oct. 2012 08:00, Eric Sibert courr...@eric.sibert.fr a écrit : Il existe aussi le cas numéro 3, mais limité à 110. Mais çà, c'est juste un différence du tag maxspeed. Tu as un exemple? Il faut que je regarde la 2x2 Albertville-Ugine qui a des trucs un peu spéciaux, en particulier vis-à-vis des cyclistes. Eric __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] Motorroad en France?
Le 18 octobre 2012 08:13, Pieren pier...@gmail.com a écrit : Oui, je suis aussi très curieux de voir un exemple. Parce que normalement, c'est pas possible avec la réglementation actuelle. Ca voudrait dire qu'on pourrait circuler en mobylette ou en vélo à côté de voitures qui roulent à 110. Attention les chaussettes... Comme je l'écrivait avant, la RD83 est un exemple. On y trouve parfois (rarement) des cyclistes, qui roulent alors sur la BAU. C'est évidemment dangereux, et 99,99% des cyclistes l'évitent, mais légalement, rien ne les en empêche. De même, on trouve des tracteurs, en particulier au moment des vendanges, tirant des remorques à 30 km/h à côté de voitures roulant à 110 km/h. Et oui, c'est dangereux, oui il y a des accidents (mortels) chaque année, mais apparament les pouvoirs publics n'ont jusqu'à présent pas jugés bon de classer cette route en voie express. Cela nécéssiterait peut-être certains aménagements supplémentaires, et donc des budgets, je ne sais pas. Toujours est-il qu'en attendant, c'est une 2x2 voies limitée à 110, sans panneau C107. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Motorroad en France?
Le 18 octobre 2012 13:07, Christian Rogel christian.ro...@club-internet.fr a écrit : Sauf Matthias, qui semble avoir compris l'intérêt de ce que j'affirme. En partie du moins ;-) , car je n'ai pas encore d'avis tranché sur la question. Mais faire du panneau C107 un préalable nécessaire à la classification en trunk me dérange en effet. C'est peut-être (voire même sans doute) lié au contre-exemple que j'ai cité et que j'emprunte tous les jours. C'est peut-être une exception unique, je ne sais pas. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 2 catégories d'autoroutes en France?
Le 8 octobre 2012 13:46, Pieren pier...@gmail.com a écrit : Je viens de comprendre qu'il y a une petite confusion, y compris sur le wiki. Les highway=trunk ont toujours le panneau bleu C107. Mais l'inverse n'est pas forcément vrai. Il y a des routes réservées à la circulation automobile (C107) qui sont de simples 1x2 voies, parfois sans bretelles (mais des bandes d'accélération/freinage), limitées à 90 et même des ronds-points. Celles-là sont tagguées en highway=* + motorroad=yes. Le wiki allemand l'explique aussi comme ça. Le wiki allemand indique pourtant qu'on peut avoir du highway=trunk sans panneau C107. Dans ce cas les Allemands précisent motorroad=no. Voir par exemple http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dtrunk#Beispiele_f.C3.BCr_die_Notwendigkeit_eines_flexiblen_Einordnens_von_Trunks en particulier le 3e exemple du paragraphe trunk und/oder motorroad?. Ce que j'en avais retenu, c'est que la classification trunk se fait sur la base de la ressemblance à une autoroute (chaussées séparées, pas d'intersections mais bretelles d'accès, etc.), et que la présence ou non du panneau C107 se traduit par motorroad=*. Maintenant, la pratique a pu dévier de ce que le wiki décrit. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Imports du cadastre et compte dédié
2012/9/25 Pieren pier...@gmail.com: J'ai posté sur le wiki ma proposition de réponse type en anglais et/ou en français: http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents#Demande_du_DWG_d.27utiliser_un_compte_sp.C3.A9cial_pour_le_transfert_dans_OSM Pieren Grant Slater n'a pas aimé apparament. Il a tout effacé. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation ouverte ?
Le 17 septembre 2012 13:01, Matthias Dietrich eiger@gmail.com a écrit : Le 17 septembre 2012 12:46, Francescu GAROBY windu...@gmail.com a écrit : Bonjour, En regardant sur Osmose les bugs qu'il y a dans mon coin, je vois que certaines relations (de moi, pour la plupart) sont dites relations ouvertes, c'est à dire qu'elles ne seraient pas closes. Ex : la 2341038 Sauf qu'en regardant la carte, et plus particulièrement les points marqués par Osmose, je ne vois pas où il y aurait rupture... Est-ce un bug ? Est-ce dû à des données périmées ? Entre les points 34028148 et 410883168, la relation n'est pas fermée. Autrement dit, la rue en highway=primary+bridge=yes n'a pas de connexion avec la limite administrative. En espérant avoir été clair dans mes explications ... Et il y a d'autres problèmes dans cette relation : - le way Boulevard Yves Guillou Briand (4576941) est présent 3 fois - le way Boulevard Yves Guillou Briand (4302560) est présent 4 fois - le way 161690460 est présent 2 fois Tu peux commencer par utiliser l'éditeur de relations de JOSM qui montre clairement que la relation ne boucle pas (cliquer sur A-Z pour réordonner les way au besoin). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Marcussacapuces91 bloqué par pnorman
Le 15 septembre 2012 16:22, Éric Gillet fear.hardc...@gmail.com a écrit : Voici pourquoi les imports (ou le nom que vous voulez...) du cadastre ne dérogent pas à la import guideline : Je vous invite à regarder autour des coordonnées suivantes : 43.29005742445736, 5.593570093648992 Aucun des deux contributeurs n'ont voulu faire de mal, en attendant les bâtiments sont dupliqués et ça engendre encore plus de travail de correction. (j'en ai mergés quelques-uns) Je suis conscient que vous procédez à des vérifications, mais dans de gros changesets ce genre de truc peut arriver car personne n'est parfait. Il faut donc distinguer les petites contributions, faites entièrement à la main, où le risque de conflit/duplication/erreur est plus faible, et les changesets d'import de plus de 2000 ways d'un coup. Et la seule manière efficace de distinguer ces deux types de contributions est de faire deux comptes séparés (c'est pas la lune). Et concrètement, en quoi le fait que le changeset soit attribué à A ou B change quoi que ce soit ? Il y a eu erreur, d'accord, et maintenant ? C'est plus facile à réparer si c'est attribué à quelqu'un en particulier ? Je ne vois pas en quoi ceci justifie le fait d'exiger un compte séparé. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OWL désactivé?
Le 3 septembre 2012 12:37, Eric Sibert courr...@eric.sibert.fr a écrit : Bonjour, J'utilisais les flux rss d'OWL (OpenStreetMap Watch List : http://matt.dev.openstreetmap.org/owl_viewer/) pour suivre les changements sur certaines zones. Je n'ai plus rien dans les flux rss depuis le 1er mai (changement de serveur OSM). Et ça ne semble pas avoir redémarré depuis, ni même après le passage du robot nettoyeur. Quelqu'un a des nouvelles? Pareil pour moi, dernier message le 4 mai. Et toujours le même message d'erreur : http://matt.dev.openstreetmap.org/owl_viewer/dailymap Depuis j'utilise les flux RSS de la vue Historique depuis www.openstreetmap.org. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OWL désactivé?
Le 3 septembre 2012 13:34, Ista Pouss ista...@gmail.com a écrit : (question dans la question) Oui mais le problème est que sur cette liste on a aussi les modifs de toutes les zones plus grande que la zone choisie ; et c'est souvent difficile pour un débutant (comme moi) de comprendre ce qui se passe. En effet, c'est l'inconvénient de cette méthode. Si je regarde l'historique, aucun des items de la liste ne correspondent vraiment à ma zone ! Il correspondent, à ce que je peux comprendre, à la France entière (dont je me fiche complet). Pire encore, si je regarde par ex. la modif Suppression tag inutile sur giratoire, à http://www.openstreetmap.org/browse/changeset/12952182 où je découvre que cette modif concernerait la France, le Bénélux et le sud de l'Angleterre (pour un giratoire !?? )... je n'ai aucune idée de ce dont il s'agit. Quel est ce giratoire ? Quel est ce tag inutile ? En l'occurrence ici, il faudrait tout mettre au pluriel. Il s'agit de plusieurs giratoires (d'où l'étendue) et de différents tags inutiles (essentiellement du oneway=yes et ref=*). Y a-t-il une méthode miracle pour tout comprendre, ou un meilleur fil de suivi des zones modifiées ? Comme d'autres l'ont relevé, il y a ITO world. Ceci dit, dans certains cas (mappeurs très actifs), je trouve la notion de session d'ITO un peu gênante. Souvent je préfère voir les changesets un par un. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Import des agences Macif
Bonjour, Je viens de voir passer ce truc : http://www.openstreetmap.org/browse/changeset/12829990 Tous les noms sont en majuscules, les adresses sont stockées dans des tags note=*, je ne sais pas si la précision générale des positions a été étudiée avant (j'ai trouvé au moins un point situé en plein milieu d'une rue), et peut-être la question la plus importante : qu'en est-il de la licence du fichier GPX mis à disposition par la Macif sur son site ? A priori je dirais que ça ne colle pas, si l'on se réfère aux mentions légales du site (https://www.macif.fr/web/site/offres/accueil/mentions_legales) : Tous les droits de reproduction sont réservés, pour tous les éléments du site qu'ils soient textes, images ou sons, y compris pour les documents téléchargeables. La reproduction de tout ou partie de ce site sur un support quel qu'il soit est formellement interdite sauf autorisation expresse de la Macif. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Erreur d'OSM concernant l'Île des Embiez ?
Le 20 août 2012 10:35, Christophe Merlet red...@redfoxcenter.org a écrit : Je soupconne donc un contributeur d'avoir recopié une erreur de google maps dans osm. Je ne suis pas local, alors ça vaut ce que ça vaut, mais ce n'est peut-être pas forcément une recopie de Google. Si l'on en croit [1], une partie de l'île s’appellerait Île de la Tour Fondue. Elle s'appelait bien Île des Embiez avant en tout cas ([2]). [1] http://mglebrusc.free.fr/textes/le%20milieu/archipel_Embiez.html [2] http://osm.mapki.com/history/way.php?id=30819494 Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Panneaux de fin de limitation de vitesse: Comment les tagguer?
Le 3 août 2012 18:25, Victor Grousset tux...@gmail.com a écrit : On peut aussi mapper les panneaux au bord de la route, ici on voit comment mapper le panneau de début de limitation de vitesse mais pas celui de fin. http://wiki.openstreetmap.org/wiki/FR:Road_signs_in_France À moins d'avoir raté un passage, la page du wiki à laquelle tu fais référence explique comment reporter *sur un way* la limite de vitesse, mais ne propose pas de tag pour le panneau lui-même, et en toute logique elle ne propose donc pas non plus de tag pour le panneau de fin de limitation. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] N10 : trunk ou primary ?
Le 4 juillet 2012 09:34, Marc SIBERT m...@sibert.fr a écrit : Bonjour, J'ai justement le problème ailleurs, il n'y a pas le fameux C107 ! Ce n'est donc pas une route pour automobile, donc ce n'est pas un truck, mais bien une primary à 110. Pouvez-vous m'aider à trancher et me donner vos avis Dans le wiki, on trouve également ceci : *Cas particulier : *quelques routes du réseau primaire sont à 2 x 2 voies à chaussées séparées sans avoir le statut de voie rapide/expresshttp://wiki.openstreetmap.org/wiki/FR:France_roads_tagging#Voies_rapides.2Fexpress. On renseignera cependant ces grands axes de circulation de la même façon que les voies rapides/express avec highwayhttp://wiki.openstreetmap.org/wiki/Key:highway =trunk http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk. Voir http://wiki.openstreetmap.org/wiki/FR:France_roads_tagging#Routes_nationales_et_interr.C3.A9gionales Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] N10 : trunk ou primary ?
Le 4 juillet 2012 10:47, Marc SIBERT m...@sibert.fr a écrit : Juste pour être sur, dans le cas ci-dessous http://osmose.openstreetmap.fr/map/?zoom=16lat=48.049516lon=-1.608649item=3010 les ronds-points doivent-ils donc passer en trunk ? Marc Bonne question ;-) La question m'intéresse, parce que vers chez moi, j'ai le même cas. Une 2x2 voies limitée à 110, avec ronds-points, qui n'est pas une voie rapide (ce qui cause d'ailleurs chaque année des accidents souvent graves impliquant des tracteurs, mais je dévie ...). Aujourd'hui, elle est tagguée en trunk, y compris des ronds-points comme ici : http://www.openstreetmap.org/?lat=47.87386lon=7.24833zoom=16layers=M ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] N10 : trunk ou primary ?
Le 4 juillet 2012 11:35, Jo winfi...@gmail.com a écrit : Peut-etre pas, mais le tracteurs et les bicyclettes ne sont pas admis sur les trunk_link non plus... ... uniquement si l'on considère que trunk et trunk_link sont strictement réservés aux voies ayant le statut de voie express. C'est justement là toute la question. À ce jour, le wiki n'est pas partout aussi strict, puisqu'il laisse la possibilité de classer en trunk des 2x2 voies sans panneau C107. J'ai regardé la définition de trunk chez nos voisins allemands. Chez eux, un trunk n'est pas nécessairement une voie express. La caractéristique principale retenue par les Allemands, c'est l'absence d'intersections. Le wiki indique qu'on peut alors ajouter explicitement motorroad=yes pour préciser le statut de voie express. Voir http://wiki.openstreetmap.org/wiki/Key:motorroad Sur cette page, il est indiqué que ce tag n'est pas nécessaire en France et que highway=trunk est suffisant. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] N10 : trunk ou primary ?
Le 4 juillet 2012 11:32, Ab_fab gamma@gmail.com a écrit : Passer le rond-point en trunk_link, serait-ce une hérésie ? Une hérésie je ne sais pas, mais ce serait en contradiction avec la règle selon laquelle on tagge un rond-point comme la route de plus haute classification qui s'y rattache. Et dans ce cas, pour être logique, ne devrait-on pas passer en primary_link les ronds-points situés sur des primary, en secondary_link ceux situés sur des secondary, etc ? Mais je n'ai peut-être pas compris le sens de ta question. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des GR dans OSM
Le 15 juin 2012 15:21, Yannick VOYEAUD yann...@voyeaud.org a écrit : Bonjour, ATTENTION Si osm.fr bouge même pour un écrit c'est fini il faut TOUT retirer car la responsabilité sera directe. Il faudra retirer les tags GR ET les chemins dans la mesure où la FFRP en revendique les droits (ce qui est totalement contestable). Le simple fait que vous intégriez une promenade qui emprunte en tout ou partie un GR il faudra supprimer la partie GR. Non, lA FFRP n'a jamais revendiqué de droit sur les chemins (objet physique). Elle a par le passé revendiqué des droits sur des itinéraires en tant que création (oeuvre de l'esprit). L'itinéraire, c'est la recette d'une randonnée, c'est cela que la FFRP a revendiqué, pas les ingrédients. Dans aucun cas il ne sera nécessaire de supprimer les chemins. En termes techniques OSM ce sont les relations route qui posent éventuellement problème. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des GR dans OSM
Le 13 juin 2012 23:43, Yannick VOYEAUD yann...@voyeaud.org a écrit : Il nous suffirait de faire exactement la même chose que ce webmaster! On tague GR... et on préciserait la limite des droits. Avec ce constat il devient possible de faire pression sur cette fédération car ils ne peuvent refuser à certains ce qu'ils accordent à d'autres du moment que les conditions de paternités sont remplies. Il serait même possible de contester sur cette base de la notion d'utilité publique dans la mesure où ils refusent la diffusion de données publiques! Je pense qu'il faut leur mettre la pression et ne pas hésiter à montrer un peu des dents. Est-on certain qu'ils ont donné leur accord à ce site ? À mon avis, la FFRP ferme les yeux sur les exploitations non commerciales (ce qui est le cas de ce site web) et n' attaque en justice que des gens qui font une exploitation commerciale (Éditions Franck Mercier ou autres ...), parce qu'ils subissent dans ce cas un réel préjudice (manque à gagner sur la vente de leurs topos). Il est par contre possible de contourner le problème en passant des accords avec chaque association locale vue que cette fédération est un regroupement d'associations. Ce détail change totalement la donne! En effet la fédération n'a peut-être pas le pouvoir de donner ou non cette autorisation (Il faut accéder aux statuts qui seuls sont opposables). Je vois le problème en généalogie où le fédération est aussi une association d'associations. Elle n'a pas de pouvoir d'imposer de règles aux adhérents des associations mais de proposer des règles que les associations locales peuvent promouvoir ou non. On peut même aller plus loin l'individu qui a balisé ou inventé le chemin physique (pas la dénomination) peut donner son autorisation indépendamment de l'association puisque l'adhérent n'est pas lié à une subordination de hiérarchie. À contrario une association locale peut nous refuser un accord donné par la fédération et c'est ce refus que nous devrions prendre en compte. Pour l'instant, on constate que c'est la FFRP qui est allée en justice, pas les associations affiliées. C'est donc elle qui détient ou revendique les droits sur les itinéraires. La revendication de propriété intellectuelle de la part de la FFRP n'est pas anecdotique, cela figure même en bonne place dans la page Historique de leur site : - 1998 : La cour de cassation reconnaît la propriété intellectuelle de la Fédération sur le tracé des sentiers de randonnée. (http://www.ffrandonnee.fr/_13/historique.aspx) Cette déclaration est d'ailleurs fausse (la Cour de Cassation n'a pas reconnu la propriété intellectuelle de la FFRP, elle a reconnu qu'un itinéraire peut être protégé au titre la propriété intellectuelle, si certaines conditions sont remplies) . Mais la FFRP adopte ici une formule qui l'arrange. Comme vous voyez il y a des portes qui existent. En conclusion je dirais qu'il ne faut surtout pas détruire ce qui a été fait, par contre l'aménager pourquoi pas! Tant que la FFRP n'aura pas donné son accord, il y aura un risque juridique pour les utilisateurs des données. On peut renommer les ref ou relations en Sentier Toto n°X, cela n'y changera rien. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des GR dans OSM
Le 14 juin 2012 12:50, Arnaud Vandecasteele arnaud@gmail.com a écrit : Néanmoins, je trouve cela dommage d'en arriver à de tels extrêmes uniquement pour une question de nom... Au risque de paraître lourd, je voudrais juste à nouveau insister sur le fait que ce n'est pas uniquement une question de nom. Le problème principal, ce sont les itinéraires. Supprimer le nom GR ou renommer ne suffit pas. Lorsqu'il existe des relations route qui reprennent l'itinéraire d'un GR, c'est toute la relation qui pose problème, quel que soit son nom, sa ref, etc. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des GR dans OSM
Le 14 juin 2012 13:08, PierreV belett...@hotmail.fr a écrit : nous pouvons supprimer uniquement les lignes qui comporte les noms déposés... mais garder les relations sous forme de chemin de randonnée comme c'est fait dans les pays voisins? Non. Si tu supprimes les tags qui comportent GR, PR ou toute autre marque déposée de la FFRP, tu n'auras réglé qu'une partie du problème. L'autre problème c'est que la FFRP peut revendiquer l'itinéraire comme sa création. À partir du moment où la base OSM comporte cette itinéraire, il existe un risque juridique. Donc conserver la relation n'est pas plus acceptable. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des GR dans OSM
Le 14 juin 2012 16:08, Yannick VOYEAUD yann...@voyeaud.org a écrit Re, Pieren La FFRP ne fait RIEN! Elle est une associations d'associations locales qui travaillent! Toute la nuance est là! C'est pour cela que la connaissance des statuts de la FFRP est importante car son champ d'action y est indiquée! La FFRP est l'entité juridique qui a attaqué Franck Mercier à l'époque. Une des premières choses qu'est censé faire un juge au civil, c'est de vérifier que le demandeur a intérêt et qualité à agir. Je ne trouve pas la décision du renvoi de l'époque, mais si l'on en croit cette page : http://www.voxpi.info/2008/12/12/la-protection-juridique-des-itinraires-de-randonne/ la FFRP a été reconnue comme investie des droits d'auteurs de l'oeuvre collective GR. On ne peut rationnellement supprimer une relation sans vider de sa substance le chemin lui-même! On peut très bien supprimer une relation route. Il restera des objets highway=path, highway=track ou n'importe quoi d'autre, avec des sac_scale=*, track_visibility=*. On n'aura perdu que l'itinéraire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des GR dans OSM
Le 14 juin 2012 17:26, Christian Rogel christian.ro...@club-internet.fr a écrit : Pieren joue toujours la prudence pour les situations juridiques incertaines, et il a raison dans le principe. Pourtant, si la dernière décision juridique en France est l'arrêté de renvoi en l'état de la Cour de Cassation de 1998, cité par Sylvain, http://droit-finances.commentcamarche.net/jurisprudence/cour-de-cassation-1/publies-1/1252131-cour-de-cassation-chambre-civile-1-du-30-juin-1998-96-15-151-publie-au-bulletin, il y a bien une certitude à en retirer, c'est qu'il est juridiquement non risqué de reproduire les itinéraires. La Cour de cassation a refusé de dire que la FFRP en avait la propriété intellectuelle, tout autant qu'elle a refusé de dire qu'elle ne l'avait pas. Les parties ont été remises dans l'état où elle se retrouvait avant ledit arrêt (tiens, tiens, Philippe), ce qui veut dire que les prétentions à la propriété intellectuelle de la FFRP ne sont pas pas réellement consacrées. Elles restent à l'état de prétentions. Question : les parties sont renvoyées vers la cour d'appel de Grenoble et celle-ci n'aurait donc pas été saisie par la FFRP. Intéressant. L'intimidation lui a semblé suffisante pour qu'elle évite de dépenser plus d'argent et d'énergie. C'était Hadopi avant la lettre. Pas tout à fait. Si l'on en croit ce lien que j'ai donné précédemment : Sur renvoi, la Cour d’appel de Grenoble a confirmé, en audience solennelle du 11 juin 2000, ... http://www.voxpi.info/2008/12/12/la-protection-juridique-des-itinraires-de-randonne/ Il y aurait donc eu renvoi. Mais je ne trouve aucune autre trace de cette décision. Maintenant si la FFRP a été déboutée, je suis prêt à revoir ma position. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des GR dans OSM
Le 14 juin 2012 17:58, Yannick VOYEAUD yann...@voyeaud.org a écrit : On peut imaginer le cas de figure suivant 1) indication d'une flèche de parcours 2) tu suis le parcours avec ton GPS 3) tu introduis ta trace dans OSM 4) tu donnes un nom à ta ballade y compris celui indiqué sur la flèche (sauf GR et compagnie cf site FFRP) 5) un commerçant revend cette trace sur un fond de carte OSM (j'insiste) Ils ne peuvent rien dire! Pourquoi? 1) la trace a été établie réellement par le promeneur 2) Il a vérifié la trace sur le fond de carte 3) le commerçant utilise le fond de carte OSM et non celui de l'IGN qui est leur base de travail À moins que je n'aie pas tout compris à ton exemple, peu importe si le promeneur enregistre lui-même le tracé, quel fond de carte il utilise, etc. Ce que la FFRP est susceptible de revendiquer c'est l'itinéraire, donc aller de A à B en passant par tel et tel chemin, en tournant ici à gauche, là à droite, en passant tel col puis tel village, en revenant par ici, Ceci est totalement indépendant du fond de carte utilisé. Pour te donner une idée de la façon dont les juges regarderaient la chose, voici la décision de la cour d'appel dans l'affaire IGN contre Didier Richard: http://www.legifrance.gouv.fr/affichJuriJudi.do?oldAction=rechJuriJudiidTexte=JURITEXT06938477fastReqId=330410198fastPos=9 Dans ce cas, pas de bol, Didier Richard n'a pas pu démontrer l'originalité de ses itinéraires et s'est fait débouter. Mais la seule question qui compte est à chaque fois pour aller de A à B, l'itinéraire choisi fait-il preuve d'une certaine originalité/création ou pas. Si le cheminement est imposé par le relief ou l'existence d'un unique chemin, le requérant se fera recaler. Sinon ... peut-être aura-t-il gain de cause. Tout le problème vient de l'incertitude. Je connais une personne qui a fait la Route de Compostelle ... Comme le disait Pieren, dans le cas particulier des itinéraires historiques, il sera difficile de revendiquer la paternité. Il y a donc peu de risques de ce côté là. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des GR dans OSM
Le 14 juin 2012 18:17, Yannick VOYEAUD yann...@voyeaud.org a écrit : Toutefois il est à noter que la FFRP ne peut plus se dire propriétaire des droits sur le tracé! En effet le tracé ne lui appartient QUE SI ET SEULEMENT SI l'association locale le lui transfère hors une adhésion ne vaut absolument pas abandon de propriété. Et quand bien même *seuls* les droits patrimoniaux seraient transférés, en effet le droit moral reste toujours au local. Rien que là la FFRP se retrouve en délicatesse avec ce qu'elle prétend défendre. Pas si le résumé de la page citée précédemment est valable : *En conclusion, l’œuvre collective constituée par le tracé des itinéraires sera, sauf preuve contraire, la propriété de la personne physique ou morale sous le nom de laquelle elle est divulguée.* Si c'est la FFRP qui divulgue les itinéraires, elle peut donc prétendre en avoir la pleine propriété. Elle aura d'ailleurs participé à la création de l'itinéraire par le biais de la commission Sentiers qui *accepte, amende ou rejette les propositions élaborées, localement par les adhérents en commission,*. Hors seul le créateur peut disposer de ses droits patrimoniaux (monétaires ou non). En l'espèce c'est toujours l'association locale qui décide. La FFRP n'est que représentante des intérêts de l'association locale. En cas de procédure il conviendrait que la FFRP démontre que 1) l'association locale a subi un préjudice direct 2) que le droit moral à été bafoué, hors il s'avère que la FFRP le bafoue elle même en s'attribuant la création des chemins! Elle devrait citer l'association locale! Je crois que nous avons là un joli cas d'école où le serpent se mord la queue et n'importe quel juriste un peu pointilleux sur le droit d'auteur fait tomber n'importe quelle attaque. Il y a déjà eu procédure (contre les Éditions Franck Mercier). Les juges ont accepté la FFRP en première instance, appel, cassation et apparemment renvoi, soit 3 ou 4 procès. C'est donc qu'elle avait intérêt et qualité à agir. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression des GR dans OSM
Le 13 juin 2012 14:57, Christian Quest cqu...@openstreetmap.fr a écrit : Ce qui est protégé c'est GR et PR, qui sont des marques déposées à l'INPI (ainsi que d'autres mais qui n'ont pas de raison de se retrouver dans OSM). Ce sont ces termes qu'il ne faut pas faire figurer. Un tag ref:FFRP=xx avec XX = numéro du GR/PR éventuellement couplé à un type:FFRP= pour distinguer GR de PR et voilà la marque déposée qui disparait sauf à la reconstituer VOLONTAIREMENT. Ce n'est pas cela le plus problématique dans l'affaire des GR. Le problème le plus important vient du fait qu'un itinéraire de randonnée peut être revendiqué comme oeuvre de l'esprit, et ceci indépendamment de sa dénomination commerciale ( GR, PR, ou n'importe quoi d'autre). La Cour de Cassation a posé les conditions générales (originalité, etc.). Il y a déjà eu des affaires devant les tribunaux (FFRP, IGN, Éditions Didier Richard, ...). Je rappelle la décision : http://www.legifrance.gouv.fr/affichJuriJudi.do?oldAction=rechJuriJudiidTexte=JURITEXT07041272fastReqId=109256579fastPos=1 Les Éditions Franck Mercier ont été attaquées, non pas pour utilisation de la marque déposée GR, mais pour avoir reproduit le tracé de circuits de randonnée. Si je recopie l'itinéraire du GR XYZ et que je diffuse cette itinéraire sous une appellation autre quelconque, je peux être attaqué par la FFRP. Si la FFRP abandonne toute revendication de paternité sur les itinéraires, ou si elle revendique en être l'auteur tout en autorisant la réutilisation sous une license X, il faudrait en avoir une trace écrite. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Erreur Osmose 1070 (highway vs. building)
Le 5 juin 2012 15:13, Pieren pier...@gmail.com a écrit : 2012/6/1 Matthias Dietrich eiger@gmail.com: Je n’appellerais pas forcément cela une solution, à supposer qu'Osmose n'ait rien à redire avec une telle modélisation. Il faut voir s'il n'y a vraiment pas un petit recouvrement (parfois, c'est minime et il faut aller dans le gros zoom pour trouver l'erreur). Si ça n'est pas le cas, c'est un bug dans Osmose et il n'y a aucune raison de changer les données OSM pour ça. Il n'y a aucun recouvrement. Je n'ai pas touché aux données, mais marqué les erreurs en faux positifs sur Osmose. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Erreur Osmose 1070 (highway vs. building)
Le 1 juin 2012 01:04, Philippe Verdy verd...@wanadoo.fr a écrit : La solution consiste à découper ce way fermé en tronçon, le tout dans une relation, pour que les parties partagées par le bâtiment ne posent pas de problème. Dans ce cas on reportera area=yes sur la relation définissant la place, et on l'enlève des ways membres à ne pas oublier sinon la relation dessinera une rue circulaire et ne remplira pas toute la place. On peut alors aussi découper les ways fermés des bâtiments eux aussi en tronçon pour qu'ils se partage les tronçons non fermés qui limitent à la fois le bâtiment et la place. Là encore on reporte les attributs du bâtiment des ways vers la relation. Je n’appellerais pas forcément cela une solution, à supposer qu'Osmose n'ait rien à redire avec une telle modélisation. On peut bien sûr utiliser des relations à la place de simples ways, mais en fin de compte, du point de vue géométrique, on se retrouve avec le même résultat : 2 polygones qui se touchent par un segment. Dans les 2 cas, la surface de recouvrement est nulle, il n'y a donc pas de chevauchement. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osmose - Repères géodésique hors commune ??
Le 30 mai 2012 12:55, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, Non, non, j'ai corrigé le problème. Il s'agit d'un problème sur les communes composées de plusieurs polygones. Ça se remarque particulièrement en Corse à cause des île rattachées aux communes. Frédéric. Le 30/05/2012 11:38, Christian Quest a écrit : Ne serait-ce pas lié au ref:INSEE qui contient une lettre (2A/2B pour la Corse) ? Le 30 mai 2012 06:36, Nicolas Croiset (Campus Grenoble 90,8) nicolas.croi...@brume.org a écrit : Bonjour, ce jour est apparu une nouvelle erreur sur les points géodésique Repère géodésique hors de sa commune Celui-ci semble pourtant bien dans celle-ci, cf par exemple : http://osmose.openstreetmap.**fr/map/?zoom=16lat=42.42518** lon=8.77391item=6070http://osmose.openstreetmap.fr/map/?zoom=16lat=42.42518lon=8.77391item=6070 Je ne sais pas quel est le retour d'expérience actuel sur cette nouvelle analyse, alors dans le doute je vais encore signaler des cas particuliers ;-) Il arrive que des sites géodésiques rattachés à une commune aient tout ou partie de leurs points en dehors de cette commune. Évidemment, cela va être difficile à traiter par Osmose, mais au cas où, je préfère le signaler. Exemples : - http://geodesie.ign.fr/fiches/pdf/68066A.pdf : site rattaché à Colmar, mais situé totalement sur la commune de Wintzenheim - http://geodesie.ign.fr/fiches/pdf/6837203.pdf : site de Willer sur Thur, les points a et b sont bien sur le territoire de la commune, le point c ne l'est pas J'ai marqué les erreurs Osmose correspondantes en faux positifs. Je n'ai aucune idée du nombre de ces exceptions à l'échelle de ma France. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Erreur Osmose 1070 (highway vs. building)
Bonsoir, Je viens de voir apparaître toute une série de points sur Osmose, marquant des erreurs 1070, pour des cas qui ne sont pas de réels chevauchements entre voirie et bâtiment. Il semble que ce soit la modélisation par surface qui pose problème. Un exemple ici : http://osmose.openstreetmap.fr/map/?zoom=18lat=47.92847lon=7.18454layers=BFF00Titem=1070 Dans le cas d'une place, modélisée par highway=* + area=yes, si la limite de la place est collée aux bâtiments et réutilise les nœuds des bâtiments, Osmose détecte une erreur, alors qu'il n'y a pas chevauchement, mais simplement une limite commune. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose - Tag source illegal ou incomplet IGN
Le 27 mai 2012 11:31, Philippe Verdy verd...@wanadoo.fr a écrit : A mon avis les embranchements à sens unique qui joignent les rues arrivant sur un rond-point et le cercle du rond-point ne sont pas des *_link. Les voies de liaison (*_link) sont des voies annexes qui permettent de relier entre elles des routes différentes, et qu'on doit emprunter pour passer de l'une à l'autre, mais qu'on n'est pas obligé de prendre si on reste sur chacune d'elle. Bref ces petits embranchements où une même route se divise selon les sens de circulation séparés sont à mettre dans le même type de route que la partie principale à double-sens des routes qui y sont reliés : il n'y a pas de chemin alternatif. ... Désolé d'avoir fait dévier la discussion IGN. [HS] Il me semble que tu n'as pas compris le problème. Il ne s'agit pas des embranchements à sens unique. Les *_link sont en règle générale des bretelles d'accès. L'exemple typique qui m'avait fait réagir en décembre et à nouveau hier est le suivant : une bretelle d'accès à une autoroute ou à une voie rapide (donc *_link) débouche sur un rond point, sur lequel sont connectées des voies secondary. Si le rond-point est classé en secondary, Osmose détecte une erreur, car il souhaiterait voir le rond-point classé en *_link. Or je trouve que classer un rond-point en bretelle d'accès n'a pas beaucoup de sens. La règle générale est on classe le rond point selon le niveau le plus élevé des routes qui y sont connectées. Je pense qu'il faudrait faire une exception pour les *_link, et c'est ce que Frédéric avait fait en décembre. [/HS] ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose - Tag source illegal ou incomplet IGN
Le 26 mai 2012 21:09, Matthias Dietrich eiger@gmail.com a écrit : Le 25 mai 2012 08:45, Maetma 91 maetm...@gmail.com a écrit : Bonjour, Une nuée de points Tag source illegal ou incomplet IGN sont récemment apparus sur Osmose. La plupart sont les point géodésiques. ironie Faut-il les supprimer?/ironie Le test peut-il être filter pour les ignorer ? Merci. Comme il n'y a pas eu de réaction, je me permets de relancer le sujet. J'ai également vu réapparaître des erreurs à propos de la classification de certains rond-points (lorsqu'un highway en *_link est connecté à un rond-point, Osmose s'attend maintenant à ce que le rond-point soit classé en *_link, ce qui n'a pas beaucoup de sens). J'avais déjà fait la remarque en décembre dernier, et Frédéric avait alors modifié l'analyseur (voir [1]). J'imagine qu'il y a eu de nouveaux changements dans l'analyseur. Matthias [1] http://lists.openstreetmap.org/pipermail/talk-fr/2011-December/038874.html Apparemment, les analyseurs ont été corrigés. Lors de la dernière analyse sur l'Alsace il y a 3 heures, les points ont disparu. Merci à Jocelyn et Frédéric. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose - Tag source illegal ou incomplet IGN
Le 25 mai 2012 08:45, Maetma 91 maetm...@gmail.com a écrit : Bonjour, Une nuée de points Tag source illegal ou incomplet IGN sont récemment apparus sur Osmose. La plupart sont les point géodésiques. ironie Faut-il les supprimer?/ironie Le test peut-il être filter pour les ignorer ? Merci. Comme il n'y a pas eu de réaction, je me permets de relancer le sujet. J'ai également vu réapparaître des erreurs à propos de la classification de certains rond-points (lorsqu'un highway en *_link est connecté à un rond-point, Osmose s'attend maintenant à ce que le rond-point soit classé en *_link, ce qui n'a pas beaucoup de sens). J'avais déjà fait la remarque en décembre dernier, et Frédéric avait alors modifié l'analyseur (voir [1]). J'imagine qu'il y a eu de nouveaux changements dans l'analyseur. Matthias [1] http://lists.openstreetmap.org/pipermail/talk-fr/2011-December/038874.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Routage automobile ultra-rapide sur données OpenStreetMap
Le 17 mars 2012 00:39, Jean-Marc Liotier j...@liotier.org a écrit : Vu dans le flux Twitter d'@openstreetmap... http://map.project-osrm.org Je ne me souviens pas avoir vu un jour un service de routage aussi rapide. D'après les résultats que j'ai obtenu, il est réglé pour générer des routes pour automobiles... Et c'est tout ce que j'en sais vu que le Karlsruher Institut für Technologie (dont la page d'accueil est liée depuis le cartouche de la solution de routage proposée) ne semble pas en avoir parlé autant que je sache. L'annonce initiale date de 2010 sur la ML dev : http://lists.openstreetmap.org/pipermail/dev/2010-July/019834.html. À l'époque, le site web actuel n'existait pas encore. Depuis il y a eu d'autres annonces sur dev, concernant la disponibilité de nouvelles versions du moteur. Sinon le KIT l'évoque dans sa page consacrée au projet de recherche sur le routage rapide : http://algo2.iti.kit.edu/routeplanning.php Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Google maps condamné en France pour abus de position dominante
Le 2 février 2012 12:49, Christian Quest cqu...@openstreetmap.fr a écrit : A compléter par la lecture de cet article plus fouillé de Numérama: http://www.numerama.com/magazine/21483-google-condamne-en-france-une-tres-bonne-decision.html Y est analysé le jugement, et il y a plein de choses intéressantes dedans, surtout sur le côté abus de position dominante plus que l'aspect dumping de Google Maps gratuit alors qu'il a un coût pour Google. Un extrait du jugement: le comportement des sociétés GOOGLE aboutit à l'éviction de tout concurrent (exemple MAPORAMA) mais en outre s'inscrit à l'évidence dans le cadre d'une stratégie générale d'élimination Merci pour le lien. On trouve d'ailleurs dans les commentaires de l'article un lien vers le jugement intégral (sur Google Docs ...), pour ceux que ça intéresserait : https://docs.google.com/viewer?a=vpid=explorerchrome=truesrcid=0B0Umg35sWCPhYTk4YjkyMWEtNjMzOC00MGUyLThhMTUtNGIzYjg4MmRmOWM1hl=en_US ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] role=label
Le 31 janvier 2012 10:24, Hélène PETIT h...@free.fr a écrit : mais on a aussi un admin-centre ; c'est un place=* qui est affiché aussi ; tout le monde se demande pourquoi le nom des communes est écrit deux fois à certains zooms, et une fois à d'autre, et la réponse est : le moteur de rendu fait ce qu'il veut, comme il veut, et il écrit une fois le nom de la relation, et l'autre fois le nom du point place=* Pas complètement quand même, et heureusement ;-) Le moteur de rendu fait ce qu'on lui dit de faire. Il se trouve que la feuille de style utilisée sur openstreetmap.org demande l'affichage des deux. Ce n'est pas une obligation. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] role=label
Le 31 janvier 2012 12:09, Hélène PETIT h...@free.fr a écrit : Le 31/01/2012 11:12, Matthias Dietrich a écrit : Pas complètement quand même, et heureusement ;-) Le moteur de rendu fait ce qu'on lui dit de faire. Remplacer la responsabilité du moteur-de-rendu par la responsabilité de on est assez savoureux, et je te remercie de l'avoir fait. Il se trouve que la feuille de style utilisée sur openstreetmap.org demande l'affichage des deux. La feuille de style fait ce qu'on lui dit de faire, non ? Ce n'est pas une obligation. Pour cette feuille de style-là, en suivant ta logique, j'aurai tendance à dire que si ... Nous vivons une époque moderne, et j'ai un lourd passé de développeur, bien placée donc pour savoir que les programmes ne naissent pas dans les choux. Inutile de le prendre sur ce ton. Ta réponse laissait supposer qu'il n'y avait aucun contrôle sur le moteur de rendu (le moteur de rendu fait ce qu'il veut). Le on, c'est justement pour signaler que chacun est libre de configurer Mapnik pour lui faire afficher ce qu'il souhaite. Et concernant la feuille de style utilisée sur openstreetmap.org, il n'est pas interdit de demander des modifications. Je ne remets pas en cause tes connaissances, pour la bonne et simple raison que je n'en ai aucune idée. Les abonnés à cette liste n'ont pas en tête les CV de tous les participants. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] role=label
Le 31 janvier 2012 13:06, Hélène PETIT h...@free.fr a écrit : Inutile de le prendre sur ce ton. Il te suffit de prendre en compte que absolument tout le monde sur cette liste sait que les logiciels sont écrit par des gens. Et que donc les tournures de phrases qui ont l'air de personnaliser ces logiciels ne peuvent pas relever d'autre chose que du sens figuré humoristique. Quand même. Pour clore ce hors-sujet, ce n'était pas là la question. J'ai compris dans ta tournure de phrase que Mapnik n'était pas configurable ou que sa configuration était figée, non modifiable. Il n'était pas question de qui développe un logiciel, mais des possibilités de configuration de celui-ci et du fait qu'à partir du même moteur de rendu on peut obtenir des résultats différents. Les sous-entendus passent très mal par email et je n'ai pas compris ce que tu as voulu dire. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Des stats détaillées pour OSM
Le 28 janvier 2012 14:39, Christian Quest cqu...@openstreetmap.fr a écrit : C'est en chantier, mais voici un début d'ébauche de commencement de fondation: http://openstreetmap.fr/outils/etat-du-decoupage-administratif Merci pour le lien. J'en profite pour signaler une erreur dans la catégorie Quartiers (10) : on trouve Heitersheim (Kernstadt), commune allemande (située en face de Fessenheim). Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] conversion geofla des X_CENTROID de RGF93 en WGS84
Salut, Je suis également preneur. Merci, Matthias Le 27 janvier 2012 10:51, Cyrille Giquello cyrill...@gmail.com a écrit : Salut Vincent, Je le veut bien ton plugin et promis je n'en abuserais pas. Si tu veux bien, j'aimerai les sources, pour apprendre par l'exemple. Merci Cyrille. Le 26 janvier 2012 19:46, Vincent Privat vincent.pri...@gmail.com a écrit : Bonsoir, J'arrive un peu après la bataille, mais pour info, j'ai un plugin JOSM en développement qui fait tout ce boulot (rien d'autre à faire que d'ouvrir le shapefile depuis JOSM pour avoir un calque de données qui va bien). Je suis un peu réticent à distribuer le jar publiquement tant qu'on a pas ajouté la notion de calque privé dans JOSM [1], par crainte de voir de gros uploads de données brutes dans la base OSM, mais je peux distribuer par mail à ceux que ça intéresse :) Le plugin lit les formats CSV, KML/KMZ, Excel, ODS, shapefile ESRI et MapInfo, et pèse un peu plus de 2 Mo. [1] http://josm.openstreetmap.de/ticket/4922 Vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ 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] Cartographie d'un village viticole
Le 26 janvier 2012 21:12, DH dhel...@free.fr a écrit : Cartographier les parcelles viticoles ©est MAL si tu entends tracer tous les détails des parcelles cadastrales qui ont une vocation (ou constatées d'usage) viticole et c'est pour cela que, j'espère, le wiki restera muet sur le sujet ; cartographier les climats est un plus pour la base, surtout quand ils correspondent à des délimitations de grand cru, de premier cru, etc... Pour moi, les lieux-dit sont un calque de toponymie, parfois associé à du bâti (constaté : le toponyme sert à nommer la rue desservant le lotissement, autrefois champs, prairies, bois,...), parfois associé à rien du tout (c'est du champ, de la vigne, un bois, basta), parfois, c'est aussi le nom d'un ancien village disparu. Bref une richesse trop souvent ignorée. Dans tous les cas, je tague en place=locality, sauf exception dûment constatée par mon expertise). Pour le vignoble alsacien j'essaie également de taguer les lieux-dit en place=locality. Je préférerais taguer les grand crus séparément en landuse=vineyard, mais sans la liste précise des parcelles classées, c'est mission impossible. Par exemple toutes les parcelles du lieu-dit cadastral Zinnkoepfle ne sont pas classées dans le Grand Cru Zinnkoepfle, qui en revanche s'étend sur d'autres lieux-dits. Pour avoir essayé de relever les limites précises de certaines appellations à partir des listes de parcelles, il faut en plus tenir compte des fusions et divisions de parcelles intervenues depuis plus de 20 ans (lorsque la demande de classement a été déposée). À cela il faut ajouter un brin d'imagination lorsque les parcelles ne sont classées que pour partie. Autant dire que c'est un énorme travail. En attendant, les lieux-dits permettent déjà de localiser bon nombre d'appellations. Matthias, qui attend également la libération des délimitations AOC... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie d'un village viticole
Le 26 janvier 2012 22:19, simon msr...@gmail.com a écrit : En fait dans les AOC il y as trois type de délimitation : -L'aire géographique, zone ou est récolté, vinifié, élaboré, élevé le vins (que l'on retrouve dans les textes de lois et c'est la zone la plus couramment représenté) -l'aire parcellaire, ce sont les parcelle sélectionne par l'INAO dans l'aire géographique d'où proviennent les raisins de l'appellation. Ces parcelles sont déposé au cadastre et consultable à la mairie de la commune. Oui mais le seul souci, c'est que pour les appellations de type 1er Cru ou Grand Cru, si on n'a pas l'aire parcellaire, on n'a pas grand chose. C'est valable également pour certaines micro-appellations. -L'aire de proximité immédiate : zone ou peuvent être vinifié et élaboré les vins. (cette zone est définie par dérogation). Pour la libération des données j'avais appellé l'INAO. Ils sont en train de géoréférencé toute les aires d'appelation et les parcelles mais le travail n'est pas encore fini et ils ne semblais vraiment motivé a partagé ces données. De ce que j'avais compris, ils ne font pas forcément le travail eux-même, mais passent parfois des partenariats avec certaines collectivités. Il me semble que le Conseil Général de Côte d'Or a effectué le géoréférencement des aires d'appellation du département pour le compte de l'INAO, avec en retour un droit de disposer des données. Et je n'ai pas non plus l'impression que la libération de leurs données soit une de leurs priorités. Après si dans OSM on arrive a créer une équipe pre a lire les textes de lois on peut commencé a refaire ce qu'ils sont en train de faire. Oui, ou une équipe qui voudra bien visiter toutes les mairies des communes situées dans les aires d'appellation, pour relever la définition parcellaire. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] GR(R) NC1 autorisé par la FFRP
Bravo pour la démarche. Cependant, une question me vient : quels étaient les termes exacts de la demande ? L'autorisation accordée porte sur la dénomination GR. Or le plus gros problème juridique n'a jamais été la dénomination ou l'utilisation d'une marque déposée (sinon on aurait pu saisir les circuits sous une dénomination alternative). Non, le problème portait sur le fait que la FFRP revendique les itinéraires des GR comme œuvres de l'esprit. Ou du moins : elle a déjà fait valoir ces revendications en justice. Est-ce que la FFRP abandonne ces revendications ? Ou est-ce qu'elle accorderait une autorisation qui ne serait valable que pour OSM ? L'interlocuteur est-il bien conscient des conséquences de la licence CC-by-SA, qui permet par exemple à n'importe qui d'éditer un topo-guide reprenant le tracé complet en concurrence avec la FFRP ? Même si je salue cette réaction de la FFRP, je reste un peu sur ma faim. Je pense qu'il faudrait un peu plus de précisions de la part de la FFRP. La marque déposée est une chose. Les itinéraires en sont une autre. Matthias Le 13 janvier 2012 23:57, Hendrik Oesterlin hendrikmail2...@yahoo.de a écrit : Bonjour, Je viens d'avoir l'autorisation de la FFRP de faire figurer le GR® NC1 dans OSM: http://www.openstreetmap.org/browse/relation/1796889 Ce n'est pas encore tout à fait complet, mais cela ne devrait pas tarder. Il suffit d'ajouter les chemins manquants à la relation, chemins qui existent déjà dans OSM. Il faut aussi améliorer les tags de la relation. A noter qu'en partie GR® NC1 est entré dans les meurs pour designer le chemin lui-même, puisqu'il n'y a pas d'autre nom plus ancien pour désigner ces petits sentiers en pleine montagne. C'est pour cela que la relation GR® NC1 contient quelques chemins GR® NC1. Voici le texte de Ludovic FRIT sur la page Nouvelle-Calédonie: http://wiki.openstreetmap.org/wiki/FR:WikiProject_New_Caledonia Bonjour, Vous pouvez reproduire la dénomination GR® concernant le GR® NC1 en Nouvelle-Calédonie. Par contre, s’agissant effectivement d’une marque déposée par la Fédération Française de la Randonnée Pédestre, merci de faire suivre le terme « GR » du symbole « ® » en exposant, soit : « GR® NC1 ». Bien cordialement, Ludovic FRIT Chargé de promotion et développement 64, rue du dessous des berges 75013 Paris : 01 44 89 93 12 : lf...@ffrandonnee.fr A voir si cette autorisation est aussi valable pour les autres GR et PR en Nouvelle-Calédonie, et plus généralement comment la FFRP va traiter les GR + PR en France métropolitaine. Je vais poser la question à Ludovic FRIT. -- Cordialement Hendrik Oesterlin Nouvelle-Calédonie ___ 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] GR(R) NC1 autorisé par la FFRP
Le 14 janvier 2012 14:33, Hendrik Oesterlin hendrikmail2...@yahoo.de a écrit : Donc, je n'ai pas mis l'accent sur la license OdbL, ni comment je renseigne ce nom dans OSM (sur certains highway ou bien sur une relation ou sur les deux). Mais je pense qu'il n'est pas necessaire de mettre l'accent là dessus, puisque OpenStreetMap désigne de façon univoque la chose et le moyens susceptibles d'être utilisés. Merci pour les précisions. Je reste cependant sceptique. Es-tu certain que ton interlocuteur connaît le projet OpenStreetMap ? Qu'il en connaît les licences (CC-by-SA et Odbl) ? Qu'il connaît les possibilités données par ces licences ? En particulier les possibilités d'exploitation commerciale ? A partir du moment où le nom est dans OSM, les consommateurs de données OSM n'ont plus besoin de demander d'autorisation quelconque à la FFRP. La FFRP ne peut donc plus exiger de contrôler l'usage qui en sera fait. Si c'est une décision prise en pleine connaissance de cause, alors j'applaudis ! Mais pour l'instant, permet-moi de douter. Ce serait de la part de la FFRP un revirement surprenant, étant donné la façon dont ils ont défendu leur propriété intellectuelle par le passé. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import du bâti raté à Bandol
Le 9 janvier 2012 13:31, Matthias Dietrich eiger@gmail.com a écrit : Le 9 janvier 2012 13:00, Nolwenn donolw...@gmail.com a écrit : En regardant la carte du côté de Bandol, j'étais étonné de ne pas voir le bâti (http://www.openstreetmap.org/?lat=43.13568lon=5.754zoom=15layers=M). En téléchargant la zone avec JOSM j'ai vu qu'il y avait une multitude de nœuds isolés et qui semblait définir les angles des bâtiments. Le contributeur auteur de l'import ne semble pas trop au point sur la technique d'import. Je pense qu'il va falloir enlever tous les points isolés qui n'ont pas de tag. Avec un peu de chance, si les points du bâti n'ont pas été bougés depuis leur création, on pourrait faire une annulation du changeset. Bon, il y a un peu de boulot pour reprendre le bâti à Bandol. J'ai trouvé 3 changesets qui ne contiennent que nes nœuds , aucun way : http://www.openstreetmap.org/browse/changeset/10113405 (50 000 nœuds !) http://www.openstreetmap.org/browse/changeset/10113839 (2 000 nœuds ) http://www.openstreetmap.org/browse/changeset/10117709 (18 000 nœuds ) Vu la quantité de nœuds déjà en base, il faudrait peut-être voir s'il n'est pas possible de les réutiliser. Une idée qui ne débouchera peut-être sur rien : si par chance les coordonnées des nœuds sont les même dans la base et dans le fichier .osm, on pourrait ouvrir le fichier osm dans JOSM, charger la zone, lancer le validator JOSM qui devrait détecter des nœuds superposés et laisser le validator corriger les doublons. Ainsi il ne resterait que les ways à envoyer dans la base. Bien évidemment, si les coordonnées sont légèrement différentes (effets d'arrondis), ça ne marchera pas. Dans l'immédiat je n'ai pas le temps de m'en occuper, avis aux amateurs. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import du bâti raté à Bandol
Le 9 janvier 2012 13:00, Nolwenn donolw...@gmail.com a écrit : En regardant la carte du côté de Bandol, j'étais étonné de ne pas voir le bâti (http://www.openstreetmap.org/?lat=43.13568lon=5.754zoom=15layers=M). En téléchargant la zone avec JOSM j'ai vu qu'il y avait une multitude de nœuds isolés et qui semblait définir les angles des bâtiments. Le contributeur auteur de l'import ne semble pas trop au point sur la technique d'import. Je pense qu'il va falloir enlever tous les points isolés qui n'ont pas de tag. Avec un peu de chance, si les points du bâti n'ont pas été bougés depuis leur création, on pourrait faire une annulation du changeset. Sinon, je m'étonne de voir autant de highway=living_street dans Bandol. Cela mériterait une vérification. Je viens de regarder l'une des rues avec Google Streetview, qui n'est peut-être pas à jour, mais je n'ai pas vu de panneau zone de rencontre qui permettrait de classer la rue en living_street. Bref, à vérifier sur place. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Import du bâti raté à Bandol
Le 9 janvier 2012 14:43, Pieren pier...@gmail.com a écrit : 2012/1/9 Matthias Dietrich eiger@gmail.com: je n'ai pas vu de panneau zone de rencontre qui permettrait de classer la rue en living_street. Le tag highway=living_street existait Avant que les zones de rencontre ne soient officialisées en France. Il a été créé pour d'autres pays européens qui connaissaient déjà ce concept. Il y a donc eu une période où certains contributeurs en France ont utilisé ce tag pour désigner des rues semi-piétonnes ou au statut pas très clair à défaut de trouver mieux (il faut dire que certaines rues prêtaient à confusion avec une vitesse très limitée (30km/h) et l'absence de trottoirs). Comme maintenant ce statut légal existe aussi en France, il faut réserver l'usage de ce tag pour les zones clairement identifiées comme telles et corriger les autres. Merci pour l'historique. Dans le cas de Bandol, les living_street ont été ajoutées en décembre. Je vais contacter le contributeur. Apparament, il en a ajouté d'autres vers Lyon (là également j'ai des doutes). Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] DG-100 : Comment ça marche ?
Le 6 janvier 2012 14:29, clansco false...@clansco.org a écrit : c'est déjà une drôle d'idée de créer un `/dev/ttyUSB0` Sous GNU/Linux de gpsbabel te méfiera, gpsman utilisera : http://gpsman.sourceforge.net/ [HS] Ce n'est pas une drôle d'idée de créer /dev/ttyUSB0, c'est probablement le comportement le plus courant. La plupart des circuits adaptateurs USB-série sont enregistrés sous les device ttyUSBx, même si on peut jouer avec les règles udev ou autres pour le modifier. [/HS] ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] problème avec suivit limites administratives communes.csv.txt (Mulsans 41156)
Salut, Il y a qlqs jours j'ai ajouté la limite de la commune Mulsans 41156 (http://osm.org/go/0AX7m_D). Aujourd'hui elle est toujours marquée problématique dans le fichier http://suivi.openstreetmap.fr/communes/communes.csv.txt Quelques jours ? L'historique dit que c'était hier : http://www.openstreetmap.org/browse/relation/1948672/history Si tu regardes la première ligne du fichier http://suivi.openstreetmap.fr/communes/communes.csv.txt, tu y trouves: Etat statistiques des communes calculé le Tue, 03 Jan 12 10:11:00 +0100 sur une copie de la base public osm datant du : 2011-12-31 16:00:00 La base étant du 31/12/2011, tes ajouts du 2 janvier n'y sont pas encore. Il faudra patienter encore un peu. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Osmose : analyse roundabout
Salut, Ne sachant pas qui gère les analyseurs Osmose, je tente ma chance ici. Je viens de voir apparaître de nouvelles erreurs sur Osmose, concernant le tag highway=* d'un rond-point. La règle générale est que le rond-point doit être taggué avec le niveau de route le plus élevé qui lui est connecté. Soit. Je tombe cependant sur pas mal d'erreurs de ce genre : http://osmose.openstreetmap.fr/map/?zoom=16lat=48.01435lon=7.37976layers=B0FF00Titem=0,1010,1020,1030,1040,1050,1060,1070,1080,1090,1100,1110,1120,2010,2020,2030,2040,2050,2060,3010,3020,3030,3031,3032,3040,3050,3060,3070,3080,4010,4020,4030,4040,4050,4060,4070,4080,5010,5020,5030,5040,5050,6010,6020,6030,6040,6050,6060,7010,7020,7030,7040 Si je suis aveuglément Osmose, je vais me retrouver avec un rond-point en motorway_link (ou en trunk_link plus loin). Si je regarde un peu ailleurs comment ce genre de cas est taggué, j'ai plutôt l'impression que jusqu'à présent, on excluait les *_link pour déterminer le niveau d'un rond-point. La règle a-t-elle changé ? Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Osmose : analyse roundabout
Le 17 décembre 2011 19:00, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Si je suis aveuglément Osmose, Rien ni personne n'est à suivre aveuglément; la preuve, tu trouves l'analyse pas normale ;) En effet ;-) La règle a-t-elle changé ? Oui l'analyseur à été réécrit. Je viens de le modifier, une fois les modif prisent en compte, elles seront appliqué sous 2 jours. Merci. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenData EtatLab et l'IGN
Le 7 décembre 2011 09:01, Damouns damo...@gmail.com a écrit : Je suis d'accord : pas d'import des contours communaux GeoFla dans OSM. Surtout quand on voit leur qualité. Les GeoFla France entière sont maintenant disponibles pour toute personne qui le souhaite puisque leur licence est libre désormais ; on pourrait les utiliser pour du contrôle qualité mais de grâce, pas d'inhibition du travail de création à partir du cadastre, on a trop à y perdre. +1 Comme cela a déjà été dit, l'import des limites GeoFla serait de toute façon un travail pour rien, dans la mesure où ces limites auraient vocation à être remplacées par celles du cadastre. Cet import ne serait pas non plus aussi facile que ça, car il faudrait tricoter avec les limites existantes et plus précises. Ceci implique du travail manuel et fastidieux de recollement de morceaux de ways GeoFla sur des ways cadastre, tout en sachant que les ways GeoFla peuvent disparaître une semaine plus tard, avec l'arrivée de nouvelles communes dans le cadastre. Personnellement, ça ne me motive pas trop de passer des heures à recoller des morceaux s'ils sont voués à disparaître la semaine suivante. Si un tel import devait tout de même se faire, il faudrait alors modifier l'analyse des communes de Sly, et peut-être certaines analyses Osmose de sorte qu'elle ne tiennent pas compte des communes aux contours GeoFla. Tout ça suppose bien évidemment que ces communes GeoFla aient un tag source correctement renseigné. Je ne vois pas vraiment la valeur ajoutée de cet import. Comme dit, on peut très bien garder les contours GeoFla à côté et les combiner aux données OSM selon les besoins. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Futur site web OSM-FR...
Le 2 décembre 2011 01:23, Christian Rogel christian.ro...@club-internet.fr a écrit : Je ne crois pas que OSM-FR sera incontournable pour les francophones non-français. Il faudra, à chaque fois, examiner si le tutorial est international ou franco-français. Dans le premier cas, sa place est évidemment sur le site international d'OSM. Avec doublonnage sur openstreetmap.fr, sans doute. Pour ce qui ne concerne spécifiquement que la France (cadastre, limites administratives, routes réglementées…), on peut discuter de leur présence sur le wiki international et donc mettre un simple renvoi vers le site franco-français... J'irais même plus loin : attention également aux non francophones qui voudront contribuer sur la France. Si je regarde ce qui se passe chez moi (Alsace), il y a de nombreux contributeurs allemands qui sont habitués à chercher sur le wiki ou sur le forum openstreetmap.org. Si on transfère tout sur openstreetmap.fr, ils ne sauront plus trouver l'information. L'usage international, c'est de placer ce genre d'informations sur le wiki openstreetmap.org. Ainsi, tout le monde y a accès. Puisque certains ont cité en exemple la nouvelle page allemande www.openstreetmap.de, je précise que nos voisins renvoient vers le wiki pour tout les détails techniques. De même pour ce qui est du forum : le forum sur openstreetmap.org ne nécessite pas d'inscription particulière, on y accède avec ses identifiants de contributeur. Si des non-français cherchent à entrer en contact avec la communauté française, ils iront d'abord voir le forum officiel ou à la limite talk-fr, mais ils n'auront probablement pas envie de s'inscrire à un forum supplémentaire juste pour poser une question. Si nous nous coupons des moyens de communication standard d'OpenStreetMap, il ne faudra pas râler lorsque des non-français se mettront à nouveau à supprimer des points géodésiques superposés ou autres spécificités franco-françaises dont on ne trouvera plus aucune trace dans le wiki. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Etat communes sur beta.letuffe.org
Salut, Je suis peut-être passé à côté d'une annonce, mais est-il normal que l'état des communes http://beta.letuffe.org/cron/etat-communes/communes.csv.txt indique n'importe quoi ? Il n'y aurait aucune commune dans la base ... Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Etat communes sur beta.letuffe.org
Le 1 décembre 2011 18:38, sly (sylvain letuffe) li...@letuffe.org a écrit : -- ma vie à moi, mais vous vous en foutez, mais y'a un bonus à la fin pour ceux qui lirons ;-) -- Merci pour le bonus ! Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Présentation
Le 8 octobre 2011 14:13, MathDaBomb mathdab...@gmail.com a écrit : pour me faire la main sur OSM, j'ai mappé (d'après le cadastre pour l'instant) le village de mes parents (Pussay, 91, http://www.openstreetmap.org/?lat=48.34888lon=1.9922zoom=16layers=M) avec JOSM. je voulais avoir vos retours afin de perfectionner ce mappage. merci d'avance Bonjour, Il y a un gros travail de nettoyage sur les bâtiments à effectuer (beaucoup de chevauchements). Voir Osmose : http://osmose.openstreetmap.fr/map/cgi-bin/index.py?zoom=15lat=48.3473lon=2.00293layers=B0FF00Titem=0,1010,1020,1030,1040,1050,1060,1070,1080,2010,2020,2030,2040,2050,3010,3020,3030,3031,3040,3050,3060,3070,3080,4010,4020,4030,4040,4050,4060,5010,5020,5030,5040,5050,6010,6020,6030,6040,6050,6060,7010,7020,7030 Concernant les chemins ruraux, il ne faut pas mettre le numéro dans le tag name mais dans le tag ref. Par exemple: name=Chemin Rural n°24 dit du Parc deviendrait: name= Chemin du Parc ref=C 24 Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Export des contours administratifs français - nettoyage source CA - plus que 155
Le 30 septembre 2011 10:43, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Pieren En fait, je pense que la plupart des limites communales d'OSM (pas toutes) qui ne sont que des plans images sans croisillons sur le cadastre en ligne (et donc sans aucun repère de géoréférencement) sont issues d'une base IGN. C'est simplement défendu, non ??? Il serait intéressant que tu pointes quelques exemples afin qu'on les compare, par exemple avec ce qui se voit sur Geoportail. Pour avoir rentré un bon paquet de communes dans ce cas, ça a toujours été à partir du cadastre, et rien d'autre. Et je ne crois pas être le seul (Damouns, Hélène Petit, etc.). vincent Lorsque j'ai achevé les limites communales du Haut-Rhin, je suis tombé sur quelques communes ayant des plans image sans croisillons. Dans ces cas, j'ai référencé du mieux que je pouvais en m'appuyant sur les limites existantes des communes voisines (qui étaient issues soit du cadastre vectoriel, soit de plans image avec croisillons). Il en résulte bien évidemment une certaine marge d'incertitude, mais en tout cas je n'ai jamais utilisé de données IGN. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] problème de rendu lanuse=vineyard
Le 22 septembre 2011 11:23, Guillaume Allegre allegre.guilla...@free.fr a écrit : Salut, J'aurais besoin d'aide pour comprendre un problème : Autour de Codolet (Gard) j'ai commencé à découper un multipolygone géant landuse=vineyard, en respectant les limites naturelles (en l'occurence la Cèze, une rivière). Le problème est ici : http://www.openstreetmap.org/?lat=44.12475lon=4.70195zoom=15layers=M sur le morceau extrait (et redessiné), on a perdu le rendu mapnik mais celuis d'Osmarender est OK. Le landuse lui-même me semble correct : http://www.openstreetmap.org/browse/way/130651813 Alors, est-ce un bug de mapnik ou un problème de mon polygone ? Si vous avez une idée... Salut, Le polygone a l'air de ne pas être fermé. Le premier nœud est le 1438318706, mais on ne le retrouve pas en fin de liste. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Service payant pour figurer dans OSM
Le 15 septembre 2011 14:12, Pieren pier...@gmail.com a écrit : - un service de monitoring (ou surveillance) pour 30€ par an et par point (mais avec tarifs dégressifs pour en surveiller d'avantage, par exemple 70€ pour 1000 points) qui signale jusqu'à trois modifications durant cette période (modification des tags ou ajouts) avec la possibilité de faire annuler ces modifications. Il y a quand même quelque chose qui me gêne dans ce service de monitoring. Je cite : Sollten wir Änderungen an Ihrem Eintrag feststellen, die von Ihnen nicht gewünscht sind, wird Ihr Eintrag nach Absprache mit Ihnen selbstverständlich wieder angepasst. Soit : Si nous devions constater des modifications non souhaitées sur vos données, nous pourrions bien évidemment les annuler après accord de votre part. En lisant ceci, la pizzeria du coin est tentée de croire qu'elle est propriétaire de son nœud dans OSM et qu'elle peut imposer ses tags, en refuser d'autres, et plus généralement rejeter toute modification faite par un contributeur quelconque. Cela ne me semble pas vraiment conforme à l'esprit d'OSM. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Service payant pour figurer dans OSM
Le 15 septembre 2011 18:12, Pieren pier...@gmail.com a écrit : Ca reste acceptable comme approche car ça n'est pas automatisé. S'il y a un conflit d'édition, la boite n'a pas intérêt à ce que ça perdure et devra chercher une solution ou un compromis entre les intervenants ou demander de l'aide auprès des admins d'OSM pour bloquer ceux qui abuseraient. Cela n'accorde donc pas plus de droits sur un node que n'importe qui. Des modifications rejetées, ça existe depuis toujours dans OSM. Je serais d'accord avec toi si c'était un revert systématique et automatique... Je trouve la proposition d'Ab_fab assez bonne. Cela permettrait de lever l'ambiguïté. Je sais bien comment cela se passe en cas de conflit d'édition, mais la pizzeria du coin, elle ne le sait pas. Sinon, c'est qu'elle connaît OSM, est dans ce cas elle peut placer son nœud elle-même. La formulation actuelle laisse croire qu'elle seule peut décider d'accepter ou de refuser les modifications effectuées sur son nœud, ce qui n'est pas vrai. Cartogis devrait donc préciser que certaines modifications sont utiles, techniquement nécessaires, voulues par la communauté ou que sais-je encore et que dans ces cas, le client n'a pas forcément le dernier mot. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] admin_level = 9
Le 13 septembre 2011 18:22, Aurélien FILEZ kinj...@gmail.com a écrit : Mais est-ce que le cas est spécifié, par exemple pour les adresses aux USA ? Vu que c'est indépendant des boundary administrative (en France du moins), est-ce qu'il y a un concept de je sais pas, boundary postal ou quelque chose ? Lorsque la surface administrative et la surface postale ne se recouvrent pas, nos voisins Allemands utilisent une relation boundary=postal_code. http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010#English_description ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] osmose class 3040
Le 23 août 2011 00:08, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Il s'agit d'un nouveau plugin proposé par Fred, encore en développement. Il s'agit de détecter grossièrement les tags non-autorisés dans la base de donnée d'OSM. Le cas du lit=24/7 est un faux positif, qui ne devrait plus être détecté par le plugin maintenant. Tu n'as donc pas besoin de modifier quoi que ce soit. Bonjour, J'en profite pour signaler qu'osmose m'a remonté des erreurs pour type=associatedStreet sur une relation, alors que ce type de relation est en usage dans le schéma d'adresses dit Karlsruhe. http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Associating_a_node_with_a_street http://wiki.openstreetmap.org/wiki/FR:Tag:type%3DassociatedStreet http://wiki.openstreetmap.org/wiki/Proposed_features/Fr:Num%C3%A9rotation_des_rues#Cas_:_relations_.28facile_pour_les_ordinateurs.2C_difficile_pour_les_humains.29 Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Critiques Commune de Jeansagnière
Le 19 août 2011 18:09, Black Myst black.m...@free.fr a écrit : Pour moi tu réponds à la question... Si personne d'autre que des feuilles de cadastre n'a connaissance de ce nom, alors il ne sert à rien dans OSM. Si personne n'a connaissance du nom, pourquoi pas en effet, mais attention ... Le nom d'une rue/d'un chemin n'a d’intérêt que si on peut trouver un panneau qui nous indique sa direction. Je connais peu de communes qui installent des panneaux sur les chemins ruraux / forestiers, pour autant les locaux peuvent très bien connaître le nom et celui-ci peut très bien figurer sur des cartes locales, plans édités par les offices de tourisme, etc. Personnellement, je serais plutôt pour les supprimer. Voila le résultat d'un mapping extrême près de Verdun: http://www.openstreetmap.org/?lat=49.12738lon=5.42813zoom=15layers=M Moi, je trouve ça juste illisible. Cela pourrait certainement être corrigé en changeant la configuration du rendu, mais pour le moment, c'est juste moche. C'est en effet une question de rendu, mais sans connaître les usages locaux, il est impossible de savoir si ces noms sont utilisés ou pas. Et s'ils sont utilisés, même sans panneaux, il n'y a pas de raison de les supprimer. Il ne faudrait pas non plus en arriver à supprimer pour le rendu. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chemins de grande randonnée, FFRP, et alternatives
Le 13 août 2011 10:58, Guilhem Bonnefille guilhem.bonnefi...@gmail.com a écrit : En complétant le wiki, je viens de réaliser que les GR sont décris dans Wikipedia : http://fr.wikipedia.org/wiki/Sentier_de_grande_randonn%C3%A9e http://fr.wikipedia.org/wiki/GR_3 Qu'est-ce qui nous différencie de WikiPedia au point que ces informations soient légitimes sur WikiPedia et DataNonGrata sur OSM ? De ce que je peux lire sur la page wikipedia du GR3, seules les grandes villes étapes sont indiquées. Le tracé précis ne l'est pas. LA différence dans OSM, c'est que nous aurions le tracé précis, de chaque chemin, chaque sentier, permettant de reconstituer exactement le tracé du GR3 tel qu'il a été défini par la FFRP. A partir de la page wikipedia, il est impossible de reconstituer le tracé exact, donc un procès aurait sans doute peu de chances d'aboutir. Tout au plus se poserait la question de l'usage d'une marque déposée sans autorisation préalable. Et encore, si on regarde le dessin du balisage en bas de la page du GR3, on remarque qu'il ne s'agit pas exactement du balisage officiel, mais une réinterprétation, qui n'est probablement pas un hasard. Maintenant je n'ai pas regardé s'il existait des pages wikipedia à propos d'autres GR et si leurs tracés y sont plus précis. Même si c'était le cas, ce n'est pas parce que Wikipedia prend un risque juridique que nous devons également le faire. De ce que j'ai pu lire jusqu'à présent, il me semble que la FFRP s'est surtout attaquée à ceux qui exploitaient commercialement (vente de topo-guides, cartes) des itinéraires dont ils s'estimaient être les auteurs. La FFRP peut très bien décider de fermer les yeux sur des reproductions non-commerciales (par exemple site web personnel avec le récit et tracé d'une randonnée) et d'attaquer les éditeurs de topo-guides qui reprendraient les tracés des itinéraires dont ils estiment détenir les droits. En fin de compte il n'appartient qu'à eux de porter une affaire en justice ou non. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chemins de grande randonnée, FFRP, et, alternatives
Le 11 août 2011 16:56, tigre-bleu tigre-b...@n7mm.org a écrit : Je comprends la théorie. Mais en pratique autant sur des longs itinéraires il est relativement faisable de trouver des itinéraires différents, autant en montagne sur des itinéraires relativement courts il n'y a pas 36 solutions pour aller d'un point A à un point B. Du coup ça voudrait dire le premier qui a dit c'est à moi a gagné, les autres peuvent aller se coucher Les autres n'auraient aucune chance de jamais pouvoir référencer ce chemin un jour même s'il est évident qu'il a un intérêt intrinsèquement. Je serais assez curieux de voir les jurisprudences sur ces histoires d'itinéraire = propriété intellectuelle pour voir jusqu'à quel niveau ça s'applique. Quelqu'un de bien renseigné aurait un lien? Le problème c'est qu'il n'y a rien d'automatique. Lorsque la cour de cassation a estimé que les itinéraires de randonnées pouvaient être considérées comme des œuvres de l'esprit, elle a précisé qu'il était cependant nécessaire que ces itinéraires devaient être des créations originales traduisant la personnalité de l'auteur. Voir à ce sujet l'arrêt de 1998 : http://www.legifrance.gouv.fr/affichJuriJudi.do?oldAction=rechJuriJudiidTexte=JURITEXT07041272fastReqId=109256579fastPos=1 Il existe cependant des cas où les plaignant ont été déboutés. Par exemple l'affaire IGN / Didier Richard, où les juges ont estimé que les itinéraires ne faisaient pas preuve d'originalité. En particulier, sur les exemples cités par Dider Richard, le juge a souvent estimé qu'il n'y avait pas d'alternative au cheminement et que donc l'itinéraire ne résultait pas d'une création. Voir http://droit-finances.commentcamarche.net/jurisprudence/cour-d-appel-2/1055486-cour-d-appel-de-grenoble-du-31-octobre-2001-01-01470 Donc tu as probablement raison pour les itinéraires courts, où les variantes n'existent pas toujours. Maintenant si on prend l'autre extrême, pour relier les Pays-Bas à Nice, il existe une multitude d'itinéraires possibles, donc un juge pourrait conclure à l'originalité du GR5 et donc à sa protection. De même pour le GR70, qui reprend la traversée des Cévennes de R.L. Stevenson, il devrait être assez difficile de plaider l'originalité, mais sait-on jamais. Sans décision de justice, il est quasiment impossible de savoir si un itinéraire est protégé ou pas. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Chemins de grande randonnée, FFRP...
Le 11 août 2011 18:55, Pierre Quenee pierre.que...@sfr.fr a écrit : A noter sur le site de LaConcurrence Propriété Intellectuelle des Randonnées L’IGN n'acquiert aucun droit de propriété sur les Randonnées. En publiant sa Randonnée avec le Service RANDO+, l’Abonné accorde le droit, sans contrepartie financière, pour le monde entier, pendant toute la durée de l'hébergement de sa Randonnée sur le Site Cartes Numériques, et dans le strict cadre des fonctionnalités du Service RANDO+ : à l’IGN de reproduire et de représenter sa Randonnée, sur tout format et sur tout support, et, en tant que de besoin, en adapter le format à cet effet ; aux Utilisateurs (ou aux seuls autres Abonnés lorsque l’Abonné leur réserve l’accès à sa Randonnée), à titre gratuit et à des fins exclusivement personnelles et non commerciales, de visualiser et d’imprimer sa Randonnée ainsi que d’exporter son tracé GPS sur un assistant personnel de navigation (GPS). L’Abonné est informé que, compte tenu des caractéristiques intrinsèques de l'internet, les données transmises, notamment sa Randonnée, ne sont pas protégées contre les risques de détournement et/ou de piratage, ce dont l’IGN ne saurait être tenus responsable. Il appartient à l’Abonné, le cas échéant, de prendre toutes les mesures appropriées de façon à protéger ses données. ... Ce paragraphe permet justement d'éviter qu'un utilisateur accuse l'IGN d'avoir plagié son itinéraire. et Responsabilité de l’Abonné En publiant sa Randonnée sur le Service RANDO+, l’Abonné est tenu au respect des dispositions légales et réglementaires en vigueur. Il lui appartient de s’assurer que l’hébergement et la diffusion de sa Randonnée via le Service RANDO+ ne constituent pas une violation des droits de propriété intellectuelle de tiers, une atteinte aux personnes et au respect de la vie privée, une atteinte à l'ordre public et aux bonnes mœurs. En publiant sa Randonnée sur le Service RANDO+, l’Abonné garantit l’IGN : qu’il détient tous les droits et autorisations nécessaires de la part des ayants droit concernés et qu’il s’est acquitté de tous les droits et paiements dus. qu’il a pris un soin tout particulier à vérifier l’exactitude et l’actualité des informations de sa Randonnée le jour de sa publication. A défaut, la Randonnée sera retirée sans formalité préalable. En outre, l’Abonné encourt, à titre personnel, les sanctions pénales spécifiques au contenu litigieux ainsi qu’une éventuelle condamnation au paiement de dommages et intérêts. Ici l'IGN se protège des utilisateurs qui voudraient publier un itinéraire dont les droits sont détenus pas un tiers (au hasard la FFRP ...) Si nous voulons citer Sentiers de Grande Randonnée® et autres il ne faut surtout pas oublier le signe ® - Nous n'avons pas le droit de faire notre petit sentier GR ® dans notre coin ni d'utiliser : horizontal blanc horizontal rouge ® . Ca tombe bien, ce n'est pas notre intention. En revanche, est ce que chaque itinéraire est bien réellement déposé sous une forme précise et opposable et chez quel organisme (la SACEM ?). La règle de base, en droit français, c'est qu'il n'y a aucune obligation de déposer ses créations quelque part pour avoir droit à une protection légale. Code de la Propriété Intellectuelle, art. L111-1: L'auteur d'une oeuvre de l'esprit jouit sur cette oeuvre, du seul fait de sa création, d'un droit de propriété incorporelle exclusif et opposable à tous. L'important c'est du seul fait de sa création. Dans la pratique, s'il y a litige, cela se jouera devant le juge, chacun devant prouver l'antériorité de sa création, le dépôt d'une œuvre pouvant alors aider à apporter cette preuve. L'obligation de dépôt légal pour certaines œuvres est plutôt une exception à cette règle. Et je doute qu'il existe un dépôt des itinéraires à ce jour. Qu'en est il exactement de la jurisprudence qui nous concerne ? Y a t'il déjà eu des cas concrets et jugés ? As tu des références de jugement concernant le droit des itinéraires ? Il y en a peu, mais ce qu'il faut retenir, c'est qu'il n'y a pas de critères précis. Tout se joue au cas par cas. Voir par exemple dans mon mail précédent. Au final et pratiquement : Nous avons probablement la faculté dans la description d'une way(chemin rural - sentier - tronçon de départemental) d'indiquer par un tag que ce chemin présente des balisages blanc et rouge, jaune bleu et/ou vert sur toute sa longueur. En revanche, nous n'avons probablement pas le droit d'assembler par le biais d'une relation l'ensemble de ces way pour en faire un itinéraire, tant que GR ® ne nous l' autorise pas .. et surtout pas le droit de faire apparaître dans une cartographie sélective ces éléments référencés GR ®. Curieusement le cas des pistes de skis descente ou fond ne semble émouvoir personne Probablement parce que personne n'a intenté de procès pour l'instant. De tout façon, les stations de ski ne gagnent
Re: [OSM-talk-fr] cartographie de grande zone commerciale
Le 7 août 2011 13:35, Hendrik Oesterlin hendrikmail2...@yahoo.de a écrit : Le 07/08/2011 à 21:13:36 +1100 panierAvide panierav...@laposte.net a écrit Objet: [OSM-talk-fr] cartographie de grande zone commerciale : À en croire cette page du wiki [1], si pour un bâtiment il n'y a qu'une seule boutique, le mieux est de mettre les tags shop, name,... sur le chemin du building directement. Dans le cas de plusieurs boutiques dans un bâtiment, indiquer sur un noeud spécial/zone délimitant la boutique dans le bâtiment les tags shop, name... (à la manière de ce qui est fait pour Literieland et Mondial Tissus). [1] http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element Je ne suis pas tellement d'accord avec cette pratique, car souvent, la facade d'un bâtiment abritant un magasin par laquelle on accède est celle qui est le plus éloigné d'une route, puisqu'il y a la parking devant. Du coup, le logiciel de navigation (et à forciori nos amis malvoyants) va sur le mauvais coté. Cela m'agace même si des contributeurs suppriment les POI que j'ai positionné pour les intégrer au polygone du building. Si l'on mettrait un node à l'endroit de la porte d'entrée, cette problématique serait résolue, et on garde le même schéma de taggage pour des bâtiments uni-usage que multi-usage. On peut parfaitement tagger l'objet building , et indiquer l'entrée pour faciliter le travail des routeurs avec un nœud building=entrance. Voir http://wiki.openstreetmap.org/wiki/Building Il y a donc plus de homogénéité. Je sais que Mapnik affiche ne name pour tout polygone en building=yes, et c'est en effet tentant de tagger pour le rendu. Ce n'est pas tagger pour le rendu que de tagger l'ensemble de l'objet s'il a un usage unique. C'est décrire cet objet. La façon la plus subtile que j'ai trouvé pour tagger pour le rendu est de mettre un addr:housename ou simplement name sur le building et de mettre le magasin sur un node dans la façade. D'ailleurs, où est l'endroit le plus adapté pour suggerer d'ajouter d'autres POI au rendu Mapnik? Un shop=books serait pas mal par exemple Sur le serveur trac d'OSM: http://trac.openstreetmap.org/ Regarde déjà s'il y a une requête dans ce sens en cours, sinon tu peux ouvrir un nouveau ticket pour le composant mapnik. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proprietaire d'un vieux changeset pour passage à l'ODbL
Bonjour, Tu peux trouver un état récent sur l'acceptation de la nouvelle licence sur : http://www.odbl.de En particulier, pour la france: http://www.odbl.de/france.html ou même au niveau mondial: http://www.odbl.de/world.html Matthias Le 15 juillet 2011 23:13, Hendrik Oesterlin hendrikmail2...@yahoo.de a écrit : On m'a suggéré de poser ces questions plutôt sur talk-fr@ que sur dev-fr@ C'est donc chose faite... -=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Message original***Original Message***Ursprüngliche Nachricht - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From: hendrikmail2...@yahoo.de Hendrik Oesterlin To: dev...@openstreetmap.org dev...@openstreetmap.org Cc: Send: 15/07/2011 20:54:00 (Rec: ) Subject: [OSM-dev-fr] Proprietaire d'un vieux changeset pour passage à l'ODbL Attach.: none -=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bonjour vous tous, Je suis en train de regarder en quelle mesure le fameux changement de licence affectera les la Nouvelle-Calédonie, et je suis tombé sur ce changeset, dont l'auteur n'est pas affiché: http://www.openstreetmap.org/browse/changeset/15678 Comment savoir s'il va accepter le changement de licence? D'ailleurs, la carte http://osm.informatik.uni-leipzig.de/map/?zoom=13lat=-22.24363lon=166.46258layers=B00T n'affiche semble-t-il uniquement le statut des ways, pas celui des nodes... Mais si l'on coupe un way en deux, une moitié devient nouvelle, mais les nodes restent tous les vieux. Un way sans ses nodes, c'est un peu bizarre. Comment peut-on savoir si un utilisateur particulier à accepte le changement? Dans d'autres mots, le site http://hdyc.neis-one.org/ est-il à jour? Et puis, est'il déjà de bon ton d'envoyer un MP à ceux qui ne sont pas encore passé à la ODbL ? Car celui qui est toujours actif a obligatoirement accepté, et celui qui ne participe plus activement n'est peut être même pas au courant de toute cette affaire autour de la licence. Merci pour vos commentaires! -- Hendrik ___ 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] Début d'interface de génération à la demande des fichiers du cadastre
Le 14 juillet 2011 22:45, Pierre pina...@pinaraf.info a écrit : Le soucis est que les gens ne respectent déjà pas les messages comme n'importez pas sans ajouter les routes. Je ne m'attends pas à ce que les gens utilisent le changeset... En ce qui me concerne je supprime maintenant le tag note:qadastre avant import. Je ne vois pas vraiment ce qu'il apporte. Si tu veux absolument l'avoir sur le changeset, il faudrait peut-être rajouter un message sur le serveur. Dans le fond, la question est à quoi sert-il ?. Et pour ce qui est du respect du message n'importez pas sans ajouter les routes, c'est une question de point de vue. Je trouve d'ailleurs le message sur le serveur un peu trop appuyé... Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Début d'interface de génération à la demande des fichiers du cadastre
Quels abus ? Le 14 juillet 2011 23:16, Philippe Pary phili...@cleo-carto.com a écrit : Le jeudi 14 juillet 2011 à 22:54 +0200, Matthias Dietrich a écrit : Et pour ce qui est du respect du message n'importez pas sans ajouter les routes, c'est une question de point de vue. Je trouve d'ailleurs le message sur le serveur un peu trop appuyé... Et pourtant ça n'empêche pas des abus d'être commis régulièrement. Philippe ___ 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] Début d'interface de génération à la demande des fichiers du cadastre
Le 14 juillet 2011 23:25, Philippe Pary phili...@cleo-carto.com a écrit : Pas une semaine sans qu'on détecte des doublons, de l'import sans les rues, de l'import sans validator, de l'import sans même regardé (avec des chemins de fer sur les églises) etc. Il suffit de lire cette liste pour s'en rendre compte :-) Pour les doublons, l'absence de validator et l'import en aveugle, d'accord. Pour l'import sans les rues, c'est ce que j'écrivais avant, je ne suis pas d'accord. OSM n'est pas une base de donnée exclusivement routière. On peut s'intéresser au polygones landuse, au bâti, aux cours d'eau et n'avoir aucun intérêt pour la voirie. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] addr:* sur les radars
Bonjour, Le 27 juin 2011 07:18, Marc Sibert m...@sibert.fr a écrit : Je crois que je vais insister un peu, mais en quoi ça vous dérange ? Le tag addr: est correctement utilisé dans ce cas. C'est un tag communément admis pour tous les POI ou batiments, bien que tous ces éléments soient déjà localisable par le contour de la commune. Jusque là ça n'a dérangé personne. Je te demande donc de *ne pas* supprimer ces tags, un comportement qui me parait bien étrange en fait : supprimer des informations correctes ! L'adresse d'un bâtiment ne se laisse pas toujours retrouver de façon évidente à partir de critères géographiques. Autant addr:country se laisse assez facilement retrouver, autant addr:housenumber doit bien être entré quelque part. Pour la ville et la rue, ça n'est pas toujours évident non plus. Donc l'information n'est pas totalement redondante. En revanche sur un radar j'avoue ne pas bien voir l'intérêt d'avoir un code postal. Le problème, c'est que si certains veulent faire l'économie de requêtes spatiales là où elles sont possibles, on va voir refleurir le bon vieux is_in, et pourquoi pas le coller sur les chemins ou les routes. Ben oui, si je veux différencier les Rue du Général de Gaulle de tous les villages de France et que je n'ai pas envie de faire de requête spatiale, je peux coller des addr: ou des is_in partout. L'information sera correcte, elle n'en sera pas moins inutile. Alors que des informations redondantes persistent sur de vieux objets, c'est presque normal, mais introduire volontairement de la redondance c'est plutôt bizarre. note : à ce rythme on s'oriente vers un conflit d'édition. Il va falloir régler ce point ici avant de toucher quoi que ce soit dans la base. Certes, mais dans ce cas, il serait bon que michel60 se manifeste ici lui aussi et qu'il explique son schéma de tags. Il a peut-être une bonne raison de procéder ainsi après tout, je ne veux pas l'exclure. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tag:area - utilisation pour aire de service et péage ?
Le 27 mai 2011 10:37, Vincent de Chateau-Thierry v...@laposte.net a écrit : highway=services (avec 's') pour les voies de circulation dans l'aire de service [1], hors voies de parking où on peut combiner highway=service et service=parking_aisle, voire amenity=parking sur un node ou un way fermé. [1] : http://wiki.openstreetmap.org/wiki/Tag:highway=services Bonjour, La page du wiki référencée indique que highway=services (avec S) est à utiliser sur un node ou un way fermé (surface). Toujours d'après cette page, le tag sert à marquer une aire de service dans son ensemble. Donc il faudrait tagger l'emprise de l'aire sous forme de way fermé avec highway=services et les voies de circulation à l'intérieur de l'aire avec highway=service. Sauf si le wiki ne reflète pas l'usage actuel de highway=services ... Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mapnik - Problème de rendu sur les relations multypolygones ?
Le 18 mai 2011 09:32, Erik Amzallag amzallag.e...@gmail.com a écrit : Tu peux donner un lien vers la zone ? et/ou un lien vers la relation ou le way qui présente toujours le problème ? Alors une relation qui ne contenait pas le tag created_by et correctement rendue : http://www.openstreetmap.org/browse/relation/27265 Une relation corrigée (tag created_by supprimé) correctement rendue : http://www.openstreetmap.org/browse/relation/13556 Une relation contenant toujours le tag created_by, non rendue : http://www.openstreetmap.org/browse/relation/13613 Toujours sur la liste dev, voici peut-être un début d'explication: http://lists.openstreetmap.org/pipermail/dev/2011-May/022636.html Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mapnik - Problème de rendu sur les relations multypolygones ?
Le 14 mai 2011 12:26, Erik Amzallag amzallag.e...@gmail.com a écrit : Bonjour, Il y a quelques jours, je constatais la disparition de certaines iles sur un fleuve. Les données étaient bien là, mais le rendu Mapnik sur OSM ne les affichaient plus. Après avoir comparé avec d'autres iles toujours rendues, la seule différence que j'ai constatée etait la présence du tag created_by sur la relation multipolygone pour les iles non rendues. Sans grande conviction, je l'ai supprimé sur quelques unes, et miracle, les iles sont revenues (mais pas celles pour lesquelles j'avais laissé le tag). Si d'autres personnes peuvent confirmer ce comportement, et éventuellement reporter un bug à qui de droit. Erik Bonjour, Quelqu'un a signalé un phénomène similaire il y a quelques jours sur la liste dev : http://gis.638310.n2.nabble.com/courtyards-td6343387.html La relation donnée en exemple par Martin Koppenhoefer porte également le tag created_by... Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Statistiques des km de voiries par communes dans osm comparé au cadastre
Le 8 mars 2011 18:10, sly (sylvain letuffe) sylv...@letuffe.org a écrit : On mardi 8 mars 2011, Bruno Cortial wrote: Et les road aussi, non ? Cela me semble justifié, malgré leur typologie incertaine. Je dirais bof, ou plutôt qu'il serait bien d'avoir les deux (avec et sans les highway=road) mais comme je ne vais pas multiplier de trop les cartes, je préfère considérer que les road sont dans la catégorie à retravailler Tout d'abord merci pour cet outil fantastique ! Deux remarques : - Pourquoi ne pas inclure les highway=path ? - Sur certaines communes, on se retrouve avec des résultats surprenants, comme ici par exemple (Hoerdt, Bas-Rhin): http://beta.letuffe.org/?zoom=13lat=48.69258lon=7.77737layers=BFFFTF taux: 52/0 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Statistiques des km de voiries par communes dans osm comparé au cadastre
Le 8 mars 2011 19:42, Etienne Trimaille etienne.trimai...@gmail.com a écrit : - Pourquoi ne pas inclure les highway=path ? Parce que les highway=path ne sont généralement pas présents sur le cadastre. Cela faussera le pourcentage. Travaillant pas mal en campagne, je rentre pas mal de highway=track, et la, avec la mise à jour, pas mal de communes sont passés en bleu ! Je pense que c'est mieux comme çà. Pour les path, d'accord, je veux bien, encore que ce soit très variable (sur certaines communes, les paths figurent au cadastre). Pour le bleu, je reste dubitatif. Il est vrai qu'il y a plus de bleu depuis la mise à jour, mais je me demande quel crédit y accorder. La commune de Hoerdt (Bas-Rhin) est passée à 64/0. Il y a donc un problème quelque part. Pour Remiremont (Vosges) on est à a 74/0. Dans ces cas, forcément, c'est bleu. Sur ma commune (Rouffach, Haut-Rhin) on est à 274/2. Or il y a bien plus que 2 km de voirie sur le cadastre. J'imagine donc que le problème se trouve plus du côté de l'outil d'extraction de la voirie. Du coup, je me pose sérieusement la question de la validité et de la variabilité des résultats selon les communes. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] South Pole affiché à l'équateur
D'après le rapport de bug, l'équipe Mapnik estime que c'est un problème de données (le bug est fermé, marqué invalide) et renvoie à la liste osm-dev. Le 3 février 2011 11:46, Damouns damo...@gmail.com a écrit : Je viens de voir que South Pole est affiché à l'équateur avec des lignes dont je ne connais pas l'origine: A mon avis il y a un bug de Mapnik qui fait que les données présentes exactement au pôle sud apparaîssent au point 0,0 dans le golfe de Guinée. Du coup ce qu'on voit c'est le découpage de l'Antarctique en zones comme la Terre Adélie. Les triangles sont inversés. Il y a un rapport de bug ici : http://trac.mapnik.org/ticket/690 Damouns ___ 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] Osmose: Repère géodésique sans bâti
Pour l'église de Vincent, je ne sais pas, mais en tout cas une erreur sur une autre église dans mon coin a disparu. Merci pour la mise à jour, Matthias Le 13 janvier 2011 14:56, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : 2011/1/12 Matthias Dietrich eiger@gmail.com: Les erreurs repère géodésique sans bâti, c'est à dire la source n°1, n'ont pas été mises à jour depuis plusieurs mois. 1 geodesie-france il y a 125j, 4h, 12m all Ce ne sont pas les seules d'ailleurs, voir http://osmose.openstreetmap.fr/cgi-bin/last-update.py J'imagine que ton clocher a été importé depuis moins de 125 jours 4 heures et 12 minutes ;-) Les repères geodésiques devraient être à jour sur osmose maintenant. Est-ce que tu pourras vérifier si ton église est correctement détecté ? Merci, Jocelyn ___ 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] imports massifs à Quimper et ailleur s : réponse de Johan (franceosm)
Je viens de lui répondre et je lui ai signalé l'existence des points géodésiques. Matthias Le 12 janvier 2011 08:03, julien balas jul...@krilin.org a écrit : For the imports I've done in the northern part of France (dep. 8/55 I will run http://matt.dev.openstreetmap.org/dupe_nodes/ to remove the duplicate nodes. Removing double houses (and copying the information in it) is already on my cleanup list (as I've done in Verdun). [..] Je vais lui expliquer comment nettoyer les fichiers avant import. Est ce que tu peut lui expliquer qu'il y a des dupes_nodes qu'il ne faut surtout pas toucher ? Les points geodesique Vu qu'il a l'air de degainer d'abord et de parler ensuite -- JB ___ 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] Osmose: Repère géodésique s ans bâti
Les erreurs repère géodésique sans bâti, c'est à dire la source n°1, n'ont pas été mises à jour depuis plusieurs mois. 1 geodesie-france il y a 125j, 4h, 12mall Ce ne sont pas les seules d'ailleurs, voir http://osmose.openstreetmap.fr/cgi-bin/last-update.py J'imagine que ton clocher a été importé depuis moins de 125 jours 4 heures et 12 minutes ;-) Matthias Le 12 janvier 2011 18:14, Vincent Privat vincent.pri...@gmail.com a écrit : Bonjour, Je suis en train de jeter un coup d'oeil aux erreurs d'osmose sur ma région, et la plupart sont des repère géodésiques sans bâti. D'ailleurs il y a une faute à bâti ;) Si quelqu'un pouvait détailler l'erreur sur le wiki: http://wiki.openstreetmap.org/wiki/FR:Osmose#Description_des_erreurs je lui en serait reconnaissant :) En attendant, comment corrige-t-on cette erreur dans les cas suivants: - Repère sur un calvaire - Je modifie le node pour ajouter le tag habituel (historic=wayside_cross) ou je crée un nouveau node aux mêmes coordonnées ? - Clochers d'église - là je m'insurge, le bâti de mon église est là ^^ Il faut une relation quelconque entre le bâti et les repères ? Merci pour vos lumières :) 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] Pluie de ronds-verts sur Quimper
D'après les commentaires des changesets ( created_by = JOSM/1.5 (3751 nl) ) on peut raisonnablement se demander si le français est sa langue maternelle. Peut-être qu'un mail en anglais aurait plus d'effet ... sauf si quelqu'un maîtrise le néerlandais / flamand. Matthias Le 10 janvier 2011 23:42, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonsoir, Le 10/01/2011 00:55, Fabrice Phung a écrit : Vincent de Chateau-Thierry a écrit : Bonsoir, Bonsoir Le compte qui importe les bâtiments sur Quimper en est à une bonne dizaine d'imports de buildings depuis hier. Il semble enchaîner les villes sans trop creuser, à voir par exemple ici : http://www.openstreetmap.org/?minlon=4.3077442minlat=49.5502079maxlon=4.3200014maxlat=49.5607015box=yes Il construit à Crach (56), Trinite (56), Plouhamel (56), Locmariaquer (56), Locoal-Mendon (56), Etel (56), Concarneau (29), Quimper (29) ... et Inaumont (08) ? Les chevauchements n'ont pas été traités sur Crach, j'ai vu aussi des coupures artificielles de bâtiments / parcelles. Je n'ai pas vérifié ailleurs. Il n'y a plus qu'à attendre la fin sur Quimper pour voir si c'est acceptable ou pas. Je n'ai pas eu de réponse de franceosm suite à mon message d'hier. Ce soir, il/elle a procédé à un import en parallèle sur Auray et Verdun, à chaque fois des dizaines de milliers de nodes... Face à tant de frénésie, si d'autres que moi veulent tenter leur chance pour le convaincre de modérer ses ardeurs, qu'ils n'hésitent pas :-) . 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] imports massifs à Quimper et ailleur s : réponse de Johan (franceosm)
J'ai également reçu une réponse de Johan. Je lui avais signalé que les fichiers issus du script d'extraction du cadastre et disponibles sur cleo-carto.org n'étaient pas destinés à être importés directement, mais nécessitent un nettoyage préalable. Je lui ai donné un exemple chiffré d'erreurs sur l'un de ces imports. Voici la réponse : good point. Reason for my uploading is that, at the moment, routing quality of France is less than in surrounding countries (see www.geofabrik.de). And importing houses, together with Bing, helps aligning roads I was planning to repair (such as the D5, a little bit to the right of Vrigne-aux-Bois. But indeed, the Cadastre script is less perfect than I assumed it to be. Also WikiProject France/Cadastre/Import semi-automatique des bâtiments doesn't give me all the tips to repair the Validator problems. So yes, please provide me with the tips to improve the quality of the cadastre script before importing it. For the imports I've done in the northern part of France (dep. 8/55 I will run http://matt.dev.openstreetmap.org/dupe_nodes/ to remove the duplicate nodes. Removing double houses (and copying the information in it) is already on my cleanup list (as I've done in Verdun). After using your tips for uploading the houses I will again commence on the northern parts of France (dep. 8/55 where almost no French mappers seem to be active. For my Brittany imports I can do the following: 1. repair the imports 2. revert my changeset (not my preference, it look quite nice to have the building in :-) ) Please advise me on tips and to do option 1 or 2 for Brittany Kind regards, Johan Je vais lui expliquer comment nettoyer les fichiers avant import. Pour le cas de la Bretagne et l'éventuelle mise à disposition de données plus précises, je préfèrerais que les Bretons coordonnent les réparations ou la suppression des imports. Matthias Le 12 janvier 2011 01:07, Christian Rogel christian.ro...@club-internet.fr a écrit : Je viens de recevoir la reponse de Johan qui, sous le pseudo de franceosm, a importé massivement dans plusieurs villes, la plus grande semblant la mienne. Dans mon message (en anglais), j'indiquais que beaucoup d'éléments étaient défectueux et qu'habituellment, l'importeur le met au point hors-ligne dans un calque avant l'envoi. J'ai précisé que, si les autorités locales acceptaient de transférer leurs données, il serait à discuter (we will have to discuss) d'effacer tout ou partie de l'import défectueux. Voici sa réponse : Ok, sorry for the Quimper import then. It's on my schedule to remove double buildings after my imports. Do you want me to revert my Quimper changeset? Kind regards, Johan (Désolé, j'avais l'intention de retirer les bâtiments en double. Souhaitez-vous que j'annule l'import entier?) Pensez-vous que le retrait complet soit nécessaire? A moins de lui demander de retirer les éléments défectueux et de parier sur un import différentiel plus tard? Je vois quand même beaucoup de doublons ou triplets et quelques absences. Ce qui me semble bizarre, c'est que certains grands bâtiments sont nettement plus petits que sur l'image aérienne. Christian ___ 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] Admin et beta.letuffe
Beta.letuffe n'y était sans doute pour rien : les relations étaient ouvertes entre Belval et Audun-le-Tiche. Je viens de corriger. On peut vérifier les relation grâce à http://analyser.openstreetmap.fr/cgi-bin/index.py , entrer l'ID de relation (51854) et attendre (longtemps). Sinon l'éditeur de relations de JOSM indique également les trous. Matthias Le 8 janvier 2011 16:34, Pierre-Alain Dorange pdora...@mac.com a écrit : Suite a un message me rappellant l'existence de la carte beta.letuffe permettant de visualiser les frontières administratives je m'aperçois qu'il y a un trou dans les limites départementale et régionale et ce dans la même zone. Le trou autour de Metz : http://beta.letuffe.org/?zoom=9lat=49.07874lon=6.65471layers=BFFF FFTTFF Il manque le département de la Moselle, qui pourtant semble avoir une définition conforme : http://www.openstreetmap.org/browse/relation/51854 Du coup (mais je sais si y'a un lien) c'est aussi la région Lorraine qui n'apparait pas sur la carte beta.letuffe http://www.openstreetmap.org/browse/relation/8645 Un bug ? ou un manque dans les relations ou leur construction ? -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ 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] Fwd: [josm-dev] Microsoft gains access to aerial imagery
Le 23 novembre 2010 20:49, Hendrik Oesterlin hendrikmail2...@yahoo.de a écrit : Le 24/11/2010 à 06:29:09 +1100 Emilie Laffray emilie.laff...@gmail.com a écrit Objet: [OSM-talk-fr] Fwd: [josm-dev] Microsoft gains access to aerial imagery : As of about an hour ago JOSM's slippymap plugin supports Bing aerial maps. I haven't publicized it yet because the official (technical) announcement hasn't come out yet specifying what the URL requests should look like or if we have to include attribution. That being said, the slippymap plugin at r24352 includes support. Sur le serveur il n'y a que Plugin-Version: 23575 Plugin-Date: 2010-10-12T19:11:33.003214Z La version 24352 est disponible ici : http://trac.openstreetmap.org/browser/applications/editors/josm/dist Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Route Nationale.
D'après le lien donné par Eric, la RN83 existerait toujours entre Poligny et Besançon. C'est également ce que montre la carte IGN dans ton lien (entre l'extrémité de l'A391 à l'ouest de Poligny et Besançon, l'IGN indique RN83, au sud c'est D1083, et au nord c'est D683). Maintenant, il semble que les cartes IGN, en tout cas telles que visibles sur Geoportail, ne soient pas toutes actualisées de la même façon. Suivant l'échelle choisie, on voit : - l'ancien nom : RN83 - l'ancien et le nouveau l'un au dessus de l'autre : D683 RN83 - le nouveau : D683 On va dire qu'on est en phase de transition ... Le 22 octobre 2010 12:46, Pierre BOIZOT pie...@boizot.name a écrit : Bonjour, Pour la carte je parle bien de carte en ligne Poligny . Quand a mon copilote, il avait un liste de route à prendre, construite à partir de OSM par OpenRouteservice pas une carte :-) le tag old_ref est-il un tag officiel ou une particularité française? Merci à Plus. Pierre CH-1009 PULLY Le 22 octobre 2010 11:01, Christophe Merlet red...@redfoxcenter.org a écrit : Le vendredi 22 octobre 2010 à 00:34 +0200, Pierre BOIZOT a écrit : Bonjour, Retour d'expérience J'ai utilisé OpenStreetRoute , pour aller dans la campagne Jurassienne. Et je n'ai eu aucun probleme jusqu'a ce que je ne trouve plus la référence des routes données dans mon plan de parcours. D905 : jamais trouvé D1083 : jamais trouvé. Ben oui les panneaux sont encore tous à N5 et N83. J'imagine qu'il vont pas être changé dans l’immédiat. IGN a gardé les anciennes numérotations. Y a t il eu des discussions sur le sujet dans la liste ? Mon amie , m'a fait remarqué pour un étranger cette situation était incompréhensible. Le tag Name peut-il etre utilisé pour marqué l'ancien nom ? Mon avis est que l'on doit mettre dans la balise ref la dénomination *actuelle* de la route même si tout les panneau n'ont pas été mis à jour. Et dans la balise old_ref les anciennes références. Sinon la situation est ingérable, on trouve toujours sur le terrain des vieux panneaux ou des vielles bornes kilométriques ayant plus de 50 ans affichant des informations obsolètes. De plus un étranger n'est pas plus con qu'un français moyen, il suivra plus facilement une direction vers une ville qu'une obscure référence, et à l'heure de GPS, qui regarde encore une carte papier en conduisant ? L'IGN a gardé les anciennes numérotations ? Sans doute sur ces cartes de 1973... Et dans 20ans, les cartes de 1973 auront toujours l'ancienne référence... C'est toute la magie et le charme des cartes gravés en taille-douce ! Librement, -- Christophe Merlet (RedFox) ___ 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] Rivières type=waterway, argument contre l'ajout des rivières tributaires comme me mbre
Très intéressant. Je me permet juste une petite remarque : on trouve en bas de page, dans la catégorie Rivières qui ne sont pas affluents d'une autre rivière , un certain nombre de rivières qui n'ont aucun lien avec des cours d'eau français : - des rivières situées en Allemagne, voire en Autriche, et qui finissent dans le Danube (aucune chance de passer par la France), exemple : http://www.openstreetmap.org/browse/relation/387859 - plus étonnant, on trouve ceci : http://www.openstreetmap.org/browse/relation/419240 Matthias Le 14 octobre 2010 08:43, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Le 14 octobre 2010, sylvain letuffe a écrit : Voilà un autre outil déjà existant pour visualiser les relations waterway et les affluents par Jocelyn : http://jocelyn.alwaysdata.net/osm/suivi-affluents.html Whaaa ! Carrément top cool. J'ai dû zaper ça si ça avait été présenté. Y'a des explications quelques part ? le premier tableau est calculé par les membres tributaires ou par une méthode similaire à la mienne ? Oui, ça utilise les tributary. Et il me semble que ça n'a jamais été présenté (en tout cas, pas par moi). Le code se trouve là: http://github.com/jocelynj/osm/tree/master/rivieres/ En gros, init.sql créé une vue avec des requêtes SQL récursives pour donner toute les suites de rivières. C'est rapide à calculer en plus. maj.sh créé la table temporaire de toutes les intersections de waterway. La requête est un peu bourrine, parce que j'utilise le schéma osmosis :) Elle vérifie aussi que l'intersection n'est pas constitué par deux extrémités de way (pour éviter le cas de deux rivières se jettant dans une troisième). et suivi-affluents.php dessine le tout. Jocelyn ___ 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] Long way sur une rivière
Le 30/08/2010 16:53, Jocelyn Jaubert a écrit : En fait, l'avancée est calculée à partir de deux nombres qui peuvent complètement différer: - la distance totale de la relation dans OSM (y compris à l'étranger) - la longueur dans le référentiel Sandre, qui ne compte la longueur qu'en France. C'est pour cela que des rivières comme le Rhin (qu'on a perdu d'ailleurs) ou la Meuse ont des avancées largement supérieure à 100%. Et il est difficile de savoir si une valeur 100% est normale ou non, tant qu'on utilisera des valeurs incohérentes entre elles. Par curiosité, quel est le lien utilisé pour les données du Sandre ? Pour le Rhin, il avait perdu son waterway=river, il ne lui restait plus que type=waterway j'imagine que c'est ce qui posait problème. Je viens de le remettre. Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
