Re: [OSM-talk-fr] Héritage et relation

[Gilles Bassière]

Le mercredi 23 mai 2012 à 23:16 -0500, Balaitous a écrit :
> Bonjour,
> 
> Pour mon premier message, je voudrais poser une question que je me pose
> depuis un moment.

Bonjour, et bienvenu sur la liste donc !

> Est-ce que les tags d'une relation sont héréditaires ?
> En d'autre terme lorsque je mets un tag dans une relation celui-ci
> est-il transmis aux enfants de la relation (lorsque ceux-ci ne
> redéfinissent pas le tag en question) ?

Non, il n'y a pas de notion d'héritage dans une relation OSM.

Il faudrait plutôt voir les relations OSM comme une "agrégation" :
l'objet décrit par une relation OSM est complexe et il peut être décrit
en arrangeant ensemble plusieurs autres objets (qui peuvent continuer à
avoir leur existence propre).

> Plus généralement, depuis quelques temps que je m'intéresse à OSM, je
> trouve un manque de séparation des aspects géométriques (point,
> ligne, ...) et sémantiques. Cela risque de poser d'importants problèmes
> de cohérence pour le nommage des routes, de plus en plus fragmentées.
> 
> Je ne sais pas où en sont les discutions, mais il me semble qu'il
> faudrait aller vers un système de tag par regroupements récursifs des
> éléments, et héritage des tags. (Il me semble avoir vu qq chose dans ce
> sens pour la prochaine API)

Je n'ai pas non plus le courage de suivre et de participer à ces
discussions :)

Effectivement, si on veut être très rigoureux (notamment si on aime bien
le principe de normalisation relationnelle), on peut considérer que
"Tout est relation". Par exemple, les multiples tronçons d'une route
sont des ways non-taggés qu'on inclut dans une relations portant le
name= et le highway=.

C'est une position cohérente d'un point de vue intellectuel, je l'ai
déjà lu ou entendu. Mais ça rend l'édition bien plus compliqué. C'est
pourquoi, en pratique, on continue à répéter les tags sur les multiples
tronçons d'une même rue. Le pragmatisme et la dé-normalisation sont dans
l'air du temps !

> En gros, généraliser les relations, faire du multipolygon un élément
> géométrique à part entière.

Le multipolygon n'est pas un élément géométrique à part entière ? Ça
dépend comment tu lis et utilises la base, non ?

> Pour les routes cela permettrait de clarifier les aspects :
> * de voirie
> * d'entité géographiques
> * d'entité administrative (no de voirie, axe européen, ...)
> * d'entité logique (axe de transport en commun, ...)
> 
> Il y a déjà des choses, et c'est d'ailleurs le point de départ de ma
> question, c'est en voulant regrouper des routes que je me suis dis que
> c'était totalement inutile s'il n'y avait pas héritage du nom de la
> référence, ...

Ça marche même sans héritage. En fait, si tu utilises une relation pour
faire ça, l'objet représentant la rue est ta relation. Les ways membres
ne sont pas "une rue" mais de simples tronçons isolés, ils sont donc
différents par nature et il n'y a pas de raison qu'ils héritent
systématiquement des mêmes tags.

Cela dit, encore une fois, cette pratique complique l'édition et risque
de dérouter plus d'un contributeur. Il faut garder à l'esprit qu'OSM
doit rester accessible au plus grand nombre.

Cordialement
-- 
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/



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

[OSM-talk-fr] Osmose - faux positif soundex

[Nicolas Croiset]

Bonjour,

osmose met régulièrement en défait certains noms de rues, malgré la 
déclaration en "faux positif", l'erreur reviens régulièrement. Existe 
t'il un tag pour que osmose ignore définitivement l'analyse du way en 
question ?


Merci !

--
++
| E-mail : nicolas.croi...@brume.org |
| Annuaire des radios AM/FM/DMB : http://www.annuradio.fr/   |
++

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

Re: [OSM-talk-fr] Osmose - faux positif soundex

[Maetma 91]

J'ai remarqué cela aussi, par exemple une Rue Blanchet qui revient
régulièrement avec Rue Blanche comme suggestion.

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

Re: [OSM-talk-fr] Osmose - faux positif soundex

[Frédéric Rodrigo]

Bonjour,

Pour bien comprendre. Vous parlez de la même rue qui revient de temps
en temps ou juste du même nom de rue, ce qui est normal ?

Vous pouvez donner un lien ?

Frédéric.

2012/5/24 Maetma 91 :
> J'ai remarqué cela aussi, par exemple une Rue Blanchet qui revient
> régulièrement avec Rue Blanche comme suggestion.

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

Re: [OSM-talk-fr] Osmose - faux positif soundex

[Nicolas Croiset]

Le 24-05-2012 9:58, Frédéric Rodrigo a écrit :

Bonjour,

Pour bien comprendre. Vous parlez de la même rue qui revient de temps
en temps ou juste du même nom de rue, ce qui est normal ?

Vous pouvez donner un lien ?

Frédéric.


Bonjour,

voici deux exemples :
http://osmose.openstreetmap.fr/map/?zoom=16&lat=45.799076&lon=4.757899&item=5050
http://osmose.openstreetmap.fr/map/?zoom=16&lat=45.741816&lon=4.918472&item=5050

cette erreur réapparait régulièrement alors que je la déclare à chaque 
fois en faux positif.


A+

--
++
| E-mail : nicolas.croi...@brume.org |
| Annuaire des radios AM/FM/DMB : http://www.annuradio.fr/   |
++

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

Re: [OSM-talk-fr] Héritage et relation

[Nicolas Dumoulin]

Bonjour,

Le jeudi 24 mai 2012 09:36:53 Gilles Bassière a écrit :
> Effectivement, si on veut être très rigoureux (notamment si on aime bien
> le principe de normalisation relationnelle), on peut considérer que
> "Tout est relation". Par exemple, les multiples tronçons d'une route
> sont des ways non-taggés qu'on inclut dans une relations portant le
> name= et le highway=.
> 
> C'est une position cohérente d'un point de vue intellectuel, je l'ai
> déjà lu ou entendu. Mais ça rend l'édition bien plus compliqué. C'est
> pourquoi, en pratique, on continue à répéter les tags sur les multiples
> tronçons d'une même rue. Le pragmatisme et la dé-normalisation sont dans
> l'air du temps !

Oui, nous sommes certains à y rêver :-) Que c'est moche d'avoir tous ces tags 
répétés. Comme c'est parfois hasardeux de modifier les attributs d'une voie 
sans en oublier un morceau … (bon ok, on s'en sort au pire en faisant une 
recherche).
Mais effectivement, tant que nous n'avons pas des éditeurs qui permettent de 
gérer cela simplement, on ne peut pas y passer.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Héritage et relation

[Vincent Pottier]

Le 24/05/2012 10:10, Nicolas Dumoulin a écrit :

Bonjour,

Le jeudi 24 mai 2012 09:36:53 Gilles Bassière a écrit :

Effectivement, si on veut être très rigoureux (notamment si on aime bien
le principe de normalisation relationnelle), on peut considérer que
"Tout est relation". Par exemple, les multiples tronçons d'une route
sont des ways non-taggés qu'on inclut dans une relations portant le
name= et le highway=.

C'est une position cohérente d'un point de vue intellectuel, je l'ai
déjà lu ou entendu. Mais ça rend l'édition bien plus compliqué. C'est
pourquoi, en pratique, on continue à répéter les tags sur les multiples
tronçons d'une même rue. Le pragmatisme et la dé-normalisation sont dans
l'air du temps !

Oui, nous sommes certains à y rêver :-) Que c'est moche d'avoir tous ces tags
répétés. Comme c'est parfois hasardeux de modifier les attributs d'une voie
sans en oublier un morceau … (bon ok, on s'en sort au pire en faisant une
recherche).
Mais effectivement, tant que nous n'avons pas des éditeurs qui permettent de
gérer cela simplement, on ne peut pas y passer.


Ça n'est pas qu'une question d'éditeurs, mais de modèle de donnée.
OpenStreetMap n'est pas tout à fait une base de données à objets, ou 
plus exactement, c'est une base de donnée à objets [1], mais on ne sait 
pas exactement ce que sont ces objets.


L'exemple de la route est typique.
Si le formalisme d'OSM était rigide, toutes les routes seraient 
contruites sur le même modèle :
- soient des ways simples comportant tout l'information : sémantique et 
géométrie (c'est le modèle de départ d'OSM)
- soient des relations portant la sémantique et des ways pour la 
géométrie et on aurait une couche ORM pour récupérer les données et les 
présenter comme objets.


Pour des raisons historiques et pratiques, les deux modèles sont 
mélangés dans la base de donnée.
- Pour l'avenue Machin, tronçonnées pour les sens interdits, les pistes 
cyclables, les relations de bus, les adresses postales, les Y à l'abord 
d'un rond-point...Le modèle relation+ways s'impose.
- Mais pour le "chemin des choux" qui mène dans la garrigue, le seul way 
suffit avec le nom, le ref et la géométrie.


Quand on veut obtenir un objet "Rue Machin", on risque donc de récupérer 
une collection : la relation globale et les tronçons.

Plus les "associatedStreet" et autres exotismes...

Le flou sur la représentation de l'objet "Rue Machin" est une 
difficulté, pour l'édition, le traitement... mais aussi une souplesse 
pour la créativité.


Les éditeurs essaient de tenir compte de ce flou, laissant à l'humain de 
déterminer s'il doit traiter une relation ou un way simple.


Ce que savent bien faire les machines, c'est de repérer que tel way, 
c'est du "highway=tertiary" et d'en tenir compte pour du routage.
Par contre de déterminer ce qu'est l'Avenue des Champs-Élysées [3], avec 
ses chaussées séparées, son rond-point au milieu, ses trottoirs, ses 
adresses, ses passages pour piétons, ses jardins et bassins, ses arrêts 
du bus et stations de métro, son serial-killer tunnel [4]... du 
surfacique, du linéaire, des interruptions, des associations... Pas 
simple...


Pourtant, les logiciels de routage s'en débrouillent, mapnik aussi.

Les représentations ne sont pas encore assez avancées pour qu'un modèle 
d'objets et interfaces (ou duck-typing) : linéaire pour le routage, 
surfacique pour la cartographie, associations pour les POIs... émerge et 
qu'une couche ORM se construise pour les éditeurs. On y vient avec les 
APIs, notamment XAPI [5].


Ça viendra... patience


[1] http://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es_orient%C3%A9e_objet
[2] http://fr.wikipedia.org/wiki/Mapping_objet-relationnel
[3] http://osm.org/go/0BPIIMGO4-
[4] http://www.2m40.com
[5] http://taginfo.openstreetmap.org/tags/name=Avenue des Champs-Élysées
http://overpass-api.de/api/xapi_meta?*[name%3DAvenue+des+Champs-%C3%89lys%C3%A9es]
--
FrViPofm

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

Re: [OSM-talk-fr] Semaine Internationale de l'OpenData à Nantes #odwnantes

[Christian Rogel]

Hier, j'ai participé à une table ronde sur l'OD et à un atelier participatif.
C'était très bien, les intervenants étaient de bonne qualité.

J'ai cité OpenStreetMap, mais le public, très divers (fonctionnaire, 
journalistes,
entrepreneurs, "touristes"), n'en avait, évidemment, pas entendu parler.

Ce qui apparaît aussi, c'est que  les personnes présentes n'avaient pas beaucoup
d'idées sur le caractère des données détenues par une collectivité, en dehors
de qualificatifs comme social, scolaire, numérique…

Une des obsessions est que cela serve à des petits groupes de gens "du
territoire" ou, à la rigueur à Mme Michu, mais pas au citoyen lambda
éclairé.
L'idée qu'elles soient exploitables depuis Hong-Kong semble donc saugrenue.
On ne voit même que les collectivités publiques ont des données géo et on 
imagine
donc même pas de débouché possible.

Remèdes : organiser des petites confs, barcamp et autres sur l'OD pour diffuser 
la 
culture de l'OD dans la population et les relais d'opinion.
Ce sera ensuite plus facile de faire comprendre qu'OSM est un lieu d'utilisation
possible, comme visualisation ou comme réceptacle.

Une idée simple comme le fait que les citoyens doivent se voir restituer les 
données
récoltées en leur nom et avec leur argent est très loin d'être comprise.

Ce qui m'amuse, c'est que l'on dise que dans les collectivités qui ont ouvert 
leurs 
données, le taux d'utilisation est très faible.

Il est pourtant facile de voir :
1 que c'est très récent
2 que le juge de paix d'une politique locale, ce sont les élections. C'est donc 
en 2013,
à mesure que la campagne pour les municipales (et les cantonales) approchera que
l'on verra des gens s'emparer des données. Il faudra essayer alors de montrer 
les
potentialités d'OSM pour les matérialiser.


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

Re: [OSM-talk-fr] Semaine Internationale de l'OpenData à Nantes #odwnantes

[Cyrille Giquello]

Bonjour. Merci Christian pour ce retour. J'ajouterai qu'il faut aussi
évangélisé auprès des collectivités et qu'elles commencent déjà à
établir le catalogue des données qu'elles détiennent. Ne pas attendre
pour diffuser la bonne parole aux agents que l'on rencontre ici ou là.

Le 24/05/12, Christian Rogel a écrit :
> Hier, j'ai participé à une table ronde sur l'OD et à un atelier
> participatif.
> C'était très bien, les intervenants étaient de bonne qualité.
>
> J'ai cité OpenStreetMap, mais le public, très divers (fonctionnaire,
> journalistes,
> entrepreneurs, "touristes"), n'en avait, évidemment, pas entendu parler.
>
> Ce qui apparaît aussi, c'est que  les personnes présentes n'avaient pas
> beaucoup
> d'idées sur le caractère des données détenues par une collectivité, en
> dehors
> de qualificatifs comme social, scolaire, numérique…
>
> Une des obsessions est que cela serve à des petits groupes de gens "du
> territoire" ou, à la rigueur à Mme Michu, mais pas au citoyen lambda
> éclairé.
> L'idée qu'elles soient exploitables depuis Hong-Kong semble donc saugrenue.
> On ne voit même que les collectivités publiques ont des données géo et on
> imagine
> donc même pas de débouché possible.
>
> Remèdes : organiser des petites confs, barcamp et autres sur l'OD pour
> diffuser la
> culture de l'OD dans la population et les relais d'opinion.
> Ce sera ensuite plus facile de faire comprendre qu'OSM est un lieu
> d'utilisation
> possible, comme visualisation ou comme réceptacle.
>
> Une idée simple comme le fait que les citoyens doivent se voir restituer les
> données
> récoltées en leur nom et avec leur argent est très loin d'être comprise.
>
> Ce qui m'amuse, c'est que l'on dise que dans les collectivités qui ont
> ouvert leurs
> données, le taux d'utilisation est très faible.
>
> Il est pourtant facile de voir :
> 1 que c'est très récent
> 2 que le juge de paix d'une politique locale, ce sont les élections. C'est
> donc en 2013,
> à mesure que la campagne pour les municipales (et les cantonales) approchera
> que
> l'on verra des gens s'emparer des données. Il faudra essayer alors de
> montrer les
> potentialités d'OSM pour les matérialiser.
>
>
> Christian R.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>

-- 
Envoyé avec mon mobile

Cyrille.

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

Re: [OSM-talk-fr] Semaine Internationale de l'OpenData à Nantes #odwnantes

[isnogoud]

Selon Christian Rogel :

> Hier, j'ai participé à une table ronde sur l'OD et à un atelier participatif.
> C'était très bien, les intervenants étaient de bonne qualité.
>
> J'ai cité OpenStreetMap, mais le public, très divers (fonctionnaire,
> journalistes, entrepreneurs, "touristes"), n'en avait, évidemment, pas
> entendu parler.
> Ce qui m'amuse, c'est que l'on dise que dans les collectivités qui ont ouvert
> leurs données, le taux d'utilisation est très faible.
>
> Il est pourtant facile de voir :
> 1 que c'est très récent
> 2 que le juge de paix d'une politique locale, ce sont les élections. C'est
> donc en 2013,
> à mesure que la campagne pour les municipales (et les cantonales) approchera
> que l'on verra des gens s'emparer des données. Il faudra essayer alors de
> montrer les potentialités d'OSM pour les matérialiser.
>

A titre d'exemple, n'hésite pas à montrer l'import des adresses sur la carte OSM
pour Nantes : c'est tout frais issu de l'opendata de Nantes Métropole.

http://www.openstreetmap.org/?lat=47.213574&lon=-1.558525&zoom=18&layers=M

L'intégration des données se poursuit actuellement pour les 24 communes de
Nantes Métropole.

http://wiki.openstreetmap.org/wiki/Nantes/Adresses_postales_Nantes_M%C3%A9tropole

Librement

Christophe

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

Re: [OSM-talk-fr] Semaine Internationale de l'OpenData à Nantes #odwnantes

[Bruno Cortial]

Bonjour,
Je ne suis l'événement que via les tweet (merci à Cyrille et aux autres),
et ce que j'écris n'est peut-être pas représentatif.

Il semble que l'aspect réciprocité n'est pas trop évoqué : le fait que les
données libérées puissent être étoffées, améliorées par les
utilisateurs/citoyens/entreprises semble être mis de coté. C'est pourtant
un point clé je pense dans le choix de la licence...

Sinon s'il y un pot quelque part ce soir ou demain, j'ai soif de savoir :-)

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

Re: [OSM-talk-fr] Osmose - faux positif soundex

[Maetma 91]

La même rue qui revient de temps en temps. Je l'ai redéclarée faux
positif il y a quelques jours donc je n'ai pas de lien mais elle est
ici : http://www.openstreetmap.org/?lat=48.311335&lon=1.997581&zoom=18&layers=M

Au passage il y a aussi des monument historiques de Longvilliers
(Pas-de-Calais) qui ré-apparaissent régulièrement à Longvilliers
(Yvelines) et en double de surcroît.

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

Re: [OSM-talk-fr] Héritage et relation

[Marc SIBERT]

Le 24 mai 2012 06:16, Balaitous  a écrit :

> Bonjour,
>
> Pour mon premier message, je voudrais poser une question que je me pose
> depuis un moment.
> Est-ce que les tags d'une relation sont héréditaires ?
> En d'autre terme lorsque je mets un tag dans une relation celui-ci
> est-il transmis aux enfants de la relation (lorsque ceux-ci ne
> redéfinissent pas le tag en question) ?
>
> Plus généralement, depuis quelques temps que je m'intéresse à OSM, je
> trouve un manque de séparation des aspects géométriques (point,
> ligne, ...) et sémantiques. Cela risque de poser d'importants problèmes
> de cohérence pour le nommage des routes, de plus en plus fragmentées.
>
> Je ne sais pas où en sont les discutions, mais il me semble qu'il
> faudrait aller vers un système de tag par regroupements récursifs des
> éléments, et héritage des tags. (Il me semble avoir vu qq chose dans ce
> sens pour la prochaine API)
>
> En gros, généraliser les relations, faire du multipolygon un élément
> géométrique à part entière.
>
> Pour les routes cela permettrait de clarifier les aspects :
> * de voirie
> * d'entité géographiques
> * d'entité administrative (no de voirie, axe européen, ...)
> * d'entité logique (axe de transport en commun, ...)
>
> Il y a déjà des choses, et c'est d'ailleurs le point de départ de ma
> question, c'est en voulant regrouper des routes que je me suis dis que
> c'était totalement inutile s'il n'y avait pas héritage du nom de la
> référence, ...
>
>
> Bonjour,



http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories

Par extension, je ne comprends pas que l'on regroupe dans une relation des
voies qui possèdent le même nom, le tag name est fait pour ça !



A+

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

Re: [OSM-talk-fr] Héritage et relation

[Nicolas Dumoulin]

Le jeudi 24 mai 2012 14:47:47 Marc SIBERT a écrit :
> Par extension, je ne comprends pas que l'on regroupe dans une relation des
> voies qui possèdent le même nom, le tag name est fait pour ça !

Ça n'a effectivement pas de sens. Si on regroupe dans une relation les chemins 
(ways) qui représente une même voie, l'étiquette « name » se doit d'être sur 
la relation et non sur les chemins.

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Héritage et relation

[Gilles Bassière]

Le jeudi 24 mai 2012 à 14:47 +0200, Marc SIBERT a écrit :
> Le 24 mai 2012 06:16, Balaitous  a écrit :
> Bonjour,
> 
> Pour mon premier message, je voudrais poser une question que
> je me pose
> depuis un moment.
> Est-ce que les tags d'une relation sont héréditaires ?
> En d'autre terme lorsque je mets un tag dans une relation
> celui-ci
> est-il transmis aux enfants de la relation (lorsque ceux-ci ne
> redéfinissent pas le tag en question) ?
> 
> Plus généralement, depuis quelques temps que je m'intéresse à
> OSM, je
> trouve un manque de séparation des aspects géométriques
> (point,
> ligne, ...) et sémantiques. Cela risque de poser d'importants
> problèmes
> de cohérence pour le nommage des routes, de plus en plus
> fragmentées.
> 
> Je ne sais pas où en sont les discutions, mais il me semble
> qu'il
> faudrait aller vers un système de tag par regroupements
> récursifs des
> éléments, et héritage des tags. (Il me semble avoir vu qq
> chose dans ce
> sens pour la prochaine API)
> 
> En gros, généraliser les relations, faire du multipolygon un
> élément
> géométrique à part entière.
> 
> Pour les routes cela permettrait de clarifier les aspects :
> * de voirie
> * d'entité géographiques
> * d'entité administrative (no de voirie, axe européen, ...)
> * d'entité logique (axe de transport en commun, ...)
> 
> Il y a déjà des choses, et c'est d'ailleurs le point de départ
> de ma
> question, c'est en voulant regrouper des routes que je me suis
> dis que
> c'était totalement inutile s'il n'y avait pas héritage du nom
> de la
> référence, ...
> 
> 
> Bonjour,
> 
> 
> 
> http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories
> 
> Par extension, je ne comprends pas que l'on regroupe dans une relation
> des voies qui possèdent le même nom, le tag name est fait pour ça !
> 
>  
> 
> 
> A+
> 
> -- 
> Marc Sibert


Bah, on est pas vendredi !

En plus ton non-argument tient même pas la route. Tu l'appuies sur une
page dans laquelle il est dit explicitement :
"On les utilise aussi pour grouper des tronçons d'une route, par
exemple : ces 15 chemins forment mis bout à bout une route du nom de
"truc"."

Un bon trolleur doit soigner ses trolls, sinon c'est pas drôle.

Cordialement
-- 
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/



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

Re: [OSM-talk-fr] Héritage et relation

[Balaitous]

Merci pour vos réponse.

Donc si je comprend bien en dehors du myltipolygon, pas d'héritage des
tags. (Je ne sais pas si c'est officiel pour le multipolygon, mais quand
je l'utilise je ne tag pas les ways correspondantes, et ça a l'air de
marcher).

En fait, le point de départ de ma réflexion, c'est qu'après avoir
contribué un peu à l'édition, j'aimerais bien avoir une carte papier!
Et je compte dans les mois qui viennent essayer de faire une telle
carte, échelle visé 1:25000 et 1:10.

Le système existant est très orienté navigation routière.
Effectivement les besoins ne sont pas les mêmes en rase campagne, où la
règle un trait = une route fonctionne assez bien, et tant qu'une route
n'est pas trop segmenté, la gestion manuelle de la cohérence fonctionne
assez bien. En ville ou sur les grands axes routiers par contre la
segmentation est beaucoup plus forte, et question simplicité d'édition,
le système actuel n'est pas satisfaisant, rajouter une modifier une ref
ou un nom sur une route partagée en 10 ou 2 segments à de quoi
décourager plus d'un utilisateur!
Le principe d'un projet tel qu'OSM est de fonctionner par petites
évolutions avec compatibilité ascendante. Le principe d'héritage des
tags me parait entrer dans cette catégorie.
Au niveau de l'édition cela peut se gérer assez facilement si un peu
comme ce qui est fait pour les relations, lors de la sélection d'un
élément JOSM affiche les groupes dont il fait partie, et si JOSM propose
lors du découpage d'un segment de regrouper les tags existant en créant
un nouveau groupe.
L’existence de la relation type=route montre qu'il y a un besoin, mais
son utilité est bien faible sans l'héritage des tags.

ps: Je n'ai pas le niveau en anglais pour pouvoir participer aux
discutions en anglais

re ps: Quel est le tag pour ajouter un commentaire ? Je veux dire par la
un court texte explicatif destiné aux contributeurs futurs. J'utilise
comment=* car je n'ai rien trouvé dans la doc.




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

[OSM-talk-fr] Re : Héritage et relation

[THEVENON Julien]

 De : Balaitous 

 re ps: Quel est le tag pour ajouter un commentaire ? Je veux dire par la
 un court texte explicatif destiné aux contributeurs futurs. J'utilise
 comment=* car je n'ai rien trouvé dans la doc.

note=* est pas mal utilise il me semble

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

Re: [OSM-talk-fr] Héritage et relation

[Balaitous]

> Bonjour,
> 
> 
> 
> http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories
> 
> Par extension, je ne comprends pas que l'on regroupe dans une relation
> des voies qui possèdent le même nom, le tag name est fait pour ça !
> 
>  
> 
Ça n'était pas vraiment le sens de mon mail, et bien que je ne sois pas
particulièrement partisan de regrouper toutes les banques d'un même
opérateur dans une grande catégorie, des questions comme ça doivent se
poser.
Est-ce que OSM doit seulement rester un jouet avancé de décalcomanie
pour adultes ?
Ça restera certainement l'utilisation pour la majorité des contributeurs
(et c'est aussi utile), mais si 5% des contributeurs pouvaient
contribuer à donner plus sens ça serait bien également. C'est dans le
sens que la valeur ajouté réside.




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

Re: [OSM-talk-fr] Héritage et relation

[Vincent Pottier]

Le 24/05/2012 16:36, Balaitous a écrit :

L’existence de la relation type=route montre qu'il y a un besoin, mais
son utilité est bien faible sans l'héritage des tags.
Attention : la relation type=route [1] est un piège pour les 
francophones. Elle ne désigne pas une route, mais un itinéraire : de 
bus, de voiture, de randonnée...

L'équivalent d'une route serait une relation type=street.

[1] http://taginfo.openstreetmap.org/tags/type=route
http://wiki.openstreetmap.org/wiki/FR:Relation:route

[2] http://taginfo.openstreetmap.org/tags/type=street
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street
--
FrViPofm

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

Re: [OSM-talk-fr] Héritage et relation

[Yannick VOYEAUD]

Le 24/05/2012 17:07, Vincent Pottier a écrit :
> Attention : la relation type=route [1] est un piège pour les
> francophones. Elle ne désigne pas une route, mais un itinéraire : de
> bus, de voiture, de randonnée...

Bonsoir,

On appelle cela un 'faux-ami' (fosami).
Et c'est ce que tous les profs de langues cherchent en premiers dans les
traductions de leurs élèves! Cela montre que le sens de la phrase n'a
pas été compris!

Amitiés

-- 
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org

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

Re: [OSM-talk-fr] Héritage et relation

[Gilles Bassière]

Le jeudi 24 mai 2012 à 09:36 -0500, Balaitous a écrit :
> Merci pour vos réponse.
> 
> Donc si je comprend bien en dehors du myltipolygon, pas d'héritage des
> tags. (Je ne sais pas si c'est officiel pour le multipolygon, mais quand
> je l'utilise je ne tag pas les ways correspondantes, et ça a l'air de
> marcher).

Je pense que c'est l'éditeur ou le rendu qui t'induit en erreur. Si tu
prend un bâtiment avec un cour intérieure par exemple, il y aura deux
chemins membres d'une relation de type multipolygon. Le seul objet OSM
qui représente le bâtiment est la relation. Les deux chemin *ne sont
pas* des bâtiments. Ils peuvent éventuellement porter des tags propres
pour représenter un *autre* objet. 

> En fait, le point de départ de ma réflexion, c'est qu'après avoir
> contribué un peu à l'édition, j'aimerais bien avoir une carte papier!
> Et je compte dans les mois qui viennent essayer de faire une telle
> carte, échelle visé 1:25000 et 1:10.

L'exploitation envisagée de la base de données ne doit en aucun cas
commander la manière dont on l'édite. Autrement dit : on ne taggue pas
pour le rendu (ou pour quoi que ce soit d'autre).

Si par exemple tu veux faire une carte du bâti, tu pourras avoir 2
tables après import de la base : une table du bâti polygone (way) et une
table du bâti multipolygone (relation). C'est *après l'import* que tu
devras faire un post-traitement pour mettre ça au propre dans une seule
table. Pareil pour fusionner les tronçons de routes qui n'aurait pas été
groupé dans une relation (ST_LineMerge est ton ami).

> Le système existant est très orienté navigation routière.

Dans OSM, il y a aussi de l'occupation des sols, des chemins de
randonnées, des POI, des balises de navigation maritime, des ...

Les outils de modélisation OSM sont simples et souples et c'est pour ça
que la base est aussi riche :)

> Effectivement les besoins ne sont pas les mêmes en rase campagne, où la
> règle un trait = une route fonctionne assez bien, et tant qu'une route
> n'est pas trop segmenté, la gestion manuelle de la cohérence fonctionne
> assez bien. En ville ou sur les grands axes routiers par contre la
> segmentation est beaucoup plus forte, et question simplicité d'édition,
> le système actuel n'est pas satisfaisant, rajouter une modifier une ref
> ou un nom sur une route partagée en 10 ou 2 segments à de quoi
> décourager plus d'un utilisateur!

Rien ne t'empêche de créer une relation pour cette voie et ainsi
factoriser les tags. Je ne l'ai jamais vu mais ça n'est ni impossible ni
interdit.

> Le principe d'un projet tel qu'OSM est de fonctionner par petites
> évolutions avec compatibilité ascendante. Le principe d'héritage des
> tags me parait entrer dans cette catégorie.
> Au niveau de l'édition cela peut se gérer assez facilement si un peu
> comme ce qui est fait pour les relations, lors de la sélection d'un
> élément JOSM affiche les groupes dont il fait partie, et si JOSM propose
> lors du découpage d'un segment de regrouper les tags existant en créant
> un nouveau groupe.
> L’existence de la relation type=route montre qu'il y a un besoin, mais
> son utilité est bien faible sans l'héritage des tags.

En fait, je pense qu'on ne se comprends pas bien. J'entends "héritage"
au sens de la modélisation objet qui implique l'existence de classes.
Dit simplement l'héritage correspond à une relation "est-un" entre deux
concepts : la classe Écureuil hérite de Mammifère qui hérite de Animal
car un écureuil *est un* mammifère et un mammifère *est un* animal.

Dans ce que tu décris, je ne vois pas de relation "est un" ni de
classes. Je vois seulement de la factorisation de tags. C'est bien de ça
que tu veux parler ? Si oui, alors les relations te permettent déjà de
faire ça. Les possibilité d'amélioration se situent alors :
- D'une part au niveau des éditeurs, comme tu le suggères, qui
pourraient proposer de créer une relation quand plusieurs objets OSM
sont manifestement des parties d'un même objet physique. Libre à toi de
proposer un patch implémentant ceci.
- D'autre part au niveau des contributeurs qu'il faudra convaincre ou
rassurer. En effet, beaucoup sont réticents à utiliser les relations
(les nouveaux et les occasionnels en particulier). J'espère que tu ne
manque ni de courage ni de pédagogie pour cette tâche :p

Si j'interprète mal ce que tu appelles héritage, peux-tu donner des cas
d'utilisation pour clarifier ?

Désolé pour la longueur de la réponse et merci d'avoir lu jusqu'ici !

Cordialement
-- 
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/



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

Re: [OSM-talk-fr] Héritage et relation

[Balaitous]

Le jeudi 24 mai 2012 à 18:59 +0200, Gilles Bassière a écrit :
> Le jeudi 24 mai 2012 à 09:36 -0500, Balaitous a écrit :
> > Merci pour vos réponse.
> > 
> > Donc si je comprend bien en dehors du myltipolygon, pas d'héritage des
> > tags. (Je ne sais pas si c'est officiel pour le multipolygon, mais quand
> > je l'utilise je ne tag pas les ways correspondantes, et ça a l'air de
> > marcher).
> 
> Je pense que c'est l'éditeur ou le rendu qui t'induit en erreur. Si tu
> prend un bâtiment avec un cour intérieure par exemple, il y aura deux
> chemins membres d'une relation de type multipolygon. Le seul objet OSM
> qui représente le bâtiment est la relation. Les deux chemin *ne sont
> pas* des bâtiments. Ils peuvent éventuellement porter des tags propres
> pour représenter un *autre* objet. 
> 
> > En fait, le point de départ de ma réflexion, c'est qu'après avoir
> > contribué un peu à l'édition, j'aimerais bien avoir une carte papier!
> > Et je compte dans les mois qui viennent essayer de faire une telle
> > carte, échelle visé 1:25000 et 1:10.
> 
> L'exploitation envisagée de la base de données ne doit en aucun cas
> commander la manière dont on l'édite. Autrement dit : on ne taggue pas
> pour le rendu (ou pour quoi que ce soit d'autre).

Entièrement d'accord. Le point de départ est effectivement l'élaboration
d'une carte, mais les questions sont plus générales. La question que je
me suis posé est quand deux way highway=* sont parallèles (pas évident à
détecter, mais c'est possible algorithmiquement) s'agit-il des deux
chaussées d'une même route ou non ?
Cette information n'est pas spécifique à un rendu particulier, c'est une
question d'échelle de représentation (et pas uniquement graphique) de
l'information.
Les relations existent, mais il y a un gros travail de standardisation à
faire. Sur le wiki, je voie que des propositions de 2008 restent
aujourd'hui des propositions! et le nombre de relation officiellement
reconnues ne dépasse pas 6! Assez limité pour décrire de l'information
de grande échelle.
Pour les routes street ? associatedstreet ? collected way ?



> 
> Si par exemple tu veux faire une carte du bâti, tu pourras avoir 2
> tables après import de la base : une table du bâti polygone (way) et une
> table du bâti multipolygone (relation). C'est *après l'import* que tu
> devras faire un post-traitement pour mettre ça au propre dans une seule
> table. Pareil pour fusionner les tronçons de routes qui n'aurait pas été
> groupé dans une relation (ST_LineMerge est ton ami).
> 
> > Le système existant est très orienté navigation routière.
> 
> Dans OSM, il y a aussi de l'occupation des sols, des chemins de
> randonnées, des POI, des balises de navigation maritime, des ...

Il n’empêche que la représentation des routes est très orienté voie de
circulation.

> 
> Les outils de modélisation OSM sont simples et souples et c'est pour ça
> que la base est aussi riche :)
> 
> > Effectivement les besoins ne sont pas les mêmes en rase campagne, où la
> > règle un trait = une route fonctionne assez bien, et tant qu'une route
> > n'est pas trop segmenté, la gestion manuelle de la cohérence fonctionne
> > assez bien. En ville ou sur les grands axes routiers par contre la
> > segmentation est beaucoup plus forte, et question simplicité d'édition,
> > le système actuel n'est pas satisfaisant, rajouter une modifier une ref
> > ou un nom sur une route partagée en 10 ou 2 segments à de quoi
> > décourager plus d'un utilisateur!
> 
> Rien ne t'empêche de créer une relation pour cette voie et ainsi
> factoriser les tags. Je ne l'ai jamais vu mais ça n'est ni impossible ni
> interdit.

Le problème est que la factorisation des tags n'est pas reconnue
(exception du multipolygon), il me semble que la plupart des moteurs de
rendu fonctionnent au niveau trait.

> 
> > Le principe d'un projet tel qu'OSM est de fonctionner par petites
> > évolutions avec compatibilité ascendante. Le principe d'héritage des
> > tags me parait entrer dans cette catégorie.
> > Au niveau de l'édition cela peut se gérer assez facilement si un peu
> > comme ce qui est fait pour les relations, lors de la sélection d'un
> > élément JOSM affiche les groupes dont il fait partie, et si JOSM propose
> > lors du découpage d'un segment de regrouper les tags existant en créant
> > un nouveau groupe.
> > L’existence de la relation type=route montre qu'il y a un besoin, mais
> > son utilité est bien faible sans l'héritage des tags.
> 
> En fait, je pense qu'on ne se comprends pas bien. J'entends "héritage"
> au sens de la modélisation objet qui implique l'existence de classes.
> Dit simplement l'héritage correspond à une relation "est-un" entre deux
> concepts : la classe Écureuil hérite de Mammifère qui hérite de Animal
> car un écureuil *est un* mammifère et un mammifère *est un* animal.

Effectivement c'est bien de cette notion de factorisation des tags dont
je veux parler. Et je constate que c'est une question que d'autres se
posent puisque j'ai découvert une 

[OSM-talk-fr] Licence des fichiers img pour GPS Garmin

[l...@worldonline.fr]

Bonjour

Depuis la semaine dernière, je mets à disposition sur ce site
http://www.freetorrent.fr/index.php deux torrents de fichiers de la
carte Openstreetmap pour GPS Garmin.
J'ai choisi la licence CC BY-NC-SA 2.0 pour ces deux fichiers.

Aurais-je du conserver obligatoirement la licence CC BY-SA 2.0
d'Openstreetmap en sachant que les fichiers générés ne sont pas à
proprement parlé le fichier des données d'Openstreetmap ?

Merci


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

Re: [OSM-talk-fr] Licence des fichiers img pour GPS Garmin

[Philippe Verdy]

OpenStreetMap est désormais en OdDBL, mais n'est plus en CC-BY-SA 2.0.
Cette licence a été supprimée et n'est plus valide pour les données
(il en reste qui sont encore sous CC-BY-SA, mais elles vont être
progressivement toutes supprimées, là où ces données proviennent
d'utilisateurs qui ont refusé ou n'ont pas approuvé explicitement la
nouvelle licence... tant pis s'ils sont morts et ne pouvaient donc pas
approuver la licence !)

Maintenant il n'est pas clair si cette licence OdDBL qui concerne la
base de données s'applique aux œuvres dérivées telles que les
extractions reformatées dans des cartes rendues ou dans des bases de
données dérivées.

Comme ton fichier Garmin est davantage une base de données qu'une
carte (que Garmin générera lui-même à partir des données de ton
fichier), il me semble que c'est la licence OdDBL qui s'applique. Pour
l'instant ce n'est pas encore méchant car on est encore en période de
transition, et il reste encore du contenu CC BY-SA non supprimé.

Mais à mon avis tu devrais changer de licence pour être conforme, car
depuis quelques semaines déjà on a des contributeurs qui travaillent
en ayant uniquement approuvé la nouvelle licence sans avoir jamais
indiqué approuver CC-BY-SA (cela s'applique même aux "anciens" qui
maintenant font toutes leurs modifs et ajouts sous la nouvelle
licence).

Le 24 mai 2012 20:54, l...@worldonline.fr  a écrit :
> Bonjour
>
> Depuis la semaine dernière, je mets à disposition sur ce site
> http://www.freetorrent.fr/index.php deux torrents de fichiers de la
> carte Openstreetmap pour GPS Garmin.
> J'ai choisi la licence CC BY-NC-SA 2.0 pour ces deux fichiers.
>
> Aurais-je du conserver obligatoirement la licence CC BY-SA 2.0
> d'Openstreetmap en sachant que les fichiers générés ne sont pas à
> proprement parlé le fichier des données d'Openstreetmap ?
>
> Merci
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk-fr] Re : Licence des fichiers img pour GPS Garmin

[THEVENON Julien]

> De : Philippe Verdy 

> OpenStreetMap est désormais en OdDBL, mais n'est plus en CC-BY-SA 2.0.
> Cette licence a été supprimée et n'est plus valide pour les données
> (il en reste qui sont encore sous CC-BY-SA, mais elles vont être
> progressivement toutes supprimées, là où ces données proviennent
> d'utilisateurs qui ont refusé ou n'ont pas approuvé explicitement la
> nouvelle licence... tant pis s'ils sont morts et ne pouvaient donc pas
> approuver la licence !)

Non le changement de licence n est pas encore effectif. ( tant qu il reste des 
donnees CC-by-SA la base reste en CC-by-SA)

Et le site est tres clair a ce sujet

Copyright and License
OpenStreetMap is open data, licensed under the Creative Commons 
Attribution-ShareAlike 2.0 licence (CC BY-SA). 
You are free to copy, distribute, transmit and adapt our maps and data, as long 
as you credit OpenStreetMap and its contributors. If you alter or build upon 
our maps or data, you may distribute the result only under the same licence. 
The full legal code explains your rights and responsibilities. 


Source : http://www.openstreetmap.org/copyright


> Maintenant il n'est pas clair si cette licence OdDBL qui concerne la
> base de données s'applique aux œuvres dérivées telles que les
> extractions reformatées dans des cartes rendues ou dans des bases de
> données dérivées.

Avec ODBL c est justement cense etre plus clair : toute donnee mise dans la 
meme base de donnee que la donnee OSM doit etre redistribuee en ODBL
La carte au format garmin est un travail derive, il doit dont juste crediter 
les contributeurs OSM


Vu que le projet est toujours en CC-by-SA etant donne qu il reste des donnees 
CC-by-SA il faut redistribuer en CC-by-SA ( cf le text en ci dessus )

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

Re: [OSM-talk-fr] Semaine Internationale de l'OpenData à Nantes #odwnantes

[Christian Rogel]

Le 24 mai 2012 à 14:25, Bruno Cortial a écrit :
> Il semble que l'aspect réciprocité n'est pas trop évoqué : le fait que les 
> données libérées puissent être étoffées, améliorées par les 
> utilisateurs/citoyens/entreprises semble être mis de coté. C'est pourtant un 
> point clé je pense dans le choix de la licence...

C'est malheureusement exact. Le schéma que les gens ont dans la tête est le 
libre-service
du prêt à manger, car Mme Michu ne sait pas traiter les données brutes, d'où le 
souci parfois
formulé de "préparer" les données, ce qui est source d'inquiétude, car cela 
peut coûter cher.
Il faut bien comprendre, vous, les geeks, que vous aurez toujours du mal à vous 
déguiser en
électeurs moyens. ;-) .

Il est plus compréhensible de parler de la population qui s'intéresse à la vie 
locale (en
période d'élections, surtout) et de dire qu'elle trouvera des médiateurs pour 
remettre les données
dans une forme digeste, mais parler d'applications spécifiques remet de 
l'inquiétude, car
qui sont ces mystérieux bienfaiteurs?
Convertir les données (pas seulement géo) en carte est mieux perçu, mais, 
peut-être, en citant presqu'autant Google Maps qu'OSM.
La valorisation via OSM ne doit être présentée qu'une fois que les étapes de la 
compréhension
basique sont franchies.

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

Re: [OSM-talk-fr] Licence des fichiers img pour GPS Garmin

[Vincent Pottier]

Le 24/05/2012 20:54, l...@worldonline.fr a écrit :

Bonjour

Depuis la semaine dernière, je mets à disposition sur ce site
http://www.freetorrent.fr/index.php deux torrents de fichiers de la
carte Openstreetmap pour GPS Garmin.

Intéressant !
On peut avoir une petite description de ces fichiers, par exemple sur le 
wiki [1] :

fréquence de rafraîchissement, capture...
avant de charger 1 Gigot avec une connexion internet capricieuse et 
passablement ensablée ?


[1] 
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Download#Single_European_Countries

--
FrViPofm

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

Re: [OSM-talk-fr] Licence des fichiers img pour GPS Garmin

[l...@worldonline.fr]

Le jeudi 24 mai 2012 à 22:03 +0200, Vincent Pottier a écrit :
> On peut avoir une petite description de ces fichiers, par exemple sur
> le 
> wiki [1] :
> fréquence de rafraîchissement, capture...
> avant de charger 1 Gigot avec une connexion internet capricieuse et 
> passablement ensablée ? 

Le site des fichiers originaux est déjà mentionné : www.numeriquement.fr
Les fichiers torrents sont uploadés selon la même fréquence


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

Re: [OSM-talk-fr] Licence des fichiers img pour GPS Garmin

[Hendrik Oesterlin]

Le 25/05/2012 à 05:54:54 +1100 "l...@worldonline.fr" l...@worldonline.fr a écrit
Objet: "[OSM-talk-fr] Licence des fichiers img pour GPS Garmin" :


> Bonjour

> Depuis la semaine dernière, je mets à disposition sur ce site
> http://www.freetorrent.fr/index.php deux torrents de fichiers de la
> carte Openstreetmap pour GPS Garmin.
> J'ai choisi la licence CC BY-NC-SA 2.0 pour ces deux fichiers.

Tu ne peut pas interdire de commercialiser les img issues de données
cc-by-sa. D'ailleurs, pourquoi interdire le commerce? 

> Aurais-je du conserver obligatoirement la licence CC BY-SA 2.0
> d'Openstreetmap en sachant que les fichiers générés ne sont pas à
> proprement parlé le fichier des données d'Openstreetmap ?

Oui, tu doit rester en cc-by-sa.

D'ailleurs, le fichier img n'est pas autre chose qu'une sélection des
données OSM. Sauf si tu avait crée un TYP pour modifier l'apparence
de la carte rendu par le GPS. Tu pourrait dire que tu as ajouté une
petite touche de ton esprit artistique.

-- 
Cordialement
Hendrik Oesterlin - Nouvelle-Calédonie


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

Re: [OSM-talk-fr] Re : Licence des fichiers img pour GPS Garmin

[Hendrik Oesterlin]

Le 25/05/2012 à 06:22:28 +1100 "THEVENON Julien" julien_theve...@yahoo.fr a 
écrit
Objet: "[OSM-talk-fr] Re :  Licence des fichiers img pour GPS Garmin" :

> Avec ODBL c est justement cense etre plus clair : toute donnee mise
> dans la meme base de donnee que la donnee OSM doit etre redistribuee en ODBL
> La carte au format garmin est un travail derive, il doit dont juste crediter 
> les contributeurs OSM

Si je comprends bien, d'ici quelque temps on pourrait effectivement
créer un extrait de la base OSM au format Garmin img et le
redistribuer sous http://creativecommons.org/licenses/by-nc-nd/3.0/
voir interdire complètement la redistribution?

> Vu que le projet est toujours en CC-by-SA etant donne qu il reste
> des donnees CC-by-SA il faut redistribuer en CC-by-SA ( cf le text en ci 
> dessus )

Dans une région du monde où plus rien d'est pas en OdBL on pourrait de
bonne foi utiliser les données en OdBL?

-- 
Cordialement
Hendrik Oesterlin - Nouvelle-Calédonie


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

Re: [OSM-talk-fr] Re : Licence des fichiers img pour GPS Garmin

[Philippe Verdy]

Je croyais que le changement de licence était déjà effectif. JE retire
donc ce que je dis pour l'instant, mais ce sera valide quand il n'y
aura plus de données CC-BY-SA, car il n'y aura plus qu'une seule
licence pour tout le monde et pour tout le contenu.

Dans ce cas la base de données dérivée que tu créeras pour Garmin
restera de toute façon une oeuvre dérivée de la base OSM, et donc
soumise à sa licence ODBL. OK pour l'instant CC-BY-SA, mais ça ne va
plus durer.

J'espère qu'on sera tous averti du changement effectif de licence pour
la base de données, même si en ce moment on n'a plus d'autre choix que
d'accepter ODBL en plus de CC-BY-SA (qui reste encore une licence pour
les données créées ou modifiées en ce moment, faute de quoi on ne
pourrait même plus non plus créer d'oeuvre dérivée publiée uniquement
sous CC-BY-SA.

Par prudence pour ton projet, tu devrais publier sous les 2 licences,
comme en ce moment pour la base OSM, quitte plus tard à retirer
CC-BY-SA. Ce qui n'entrainera alors le minimum d'interruption de ton
service pour qu'il change lui aussi de licence : cela veut dire
mentionner les auteurs de la façon indiquée, en plus de mentionner
encore la licence CC-BY-SA (la première mention étant de toute façon
exigée par les deux licences).

Le 24 mai 2012 22:21, Hendrik Oesterlin  a écrit :
> Le 25/05/2012 à 06:22:28 +1100 "THEVENON Julien" julien_theve...@yahoo.fr a 
> écrit
> Objet: "[OSM-talk-fr] Re :  Licence des fichiers img pour GPS Garmin" :
>
>> Avec ODBL c est justement cense etre plus clair : toute donnee mise
>> dans la meme base de donnee que la donnee OSM doit etre redistribuee en ODBL
>> La carte au format garmin est un travail derive, il doit dont juste crediter 
>> les contributeurs OSM
>
> Si je comprends bien, d'ici quelque temps on pourrait effectivement
> créer un extrait de la base OSM au format Garmin img et le
> redistribuer sous http://creativecommons.org/licenses/by-nc-nd/3.0/
> voir interdire complètement la redistribution?
>
>> Vu que le projet est toujours en CC-by-SA etant donne qu il reste
>> des donnees CC-by-SA il faut redistribuer en CC-by-SA ( cf le text en ci 
>> dessus )
>
> Dans une région du monde où plus rien d'est pas en OdBL on pourrait de
> bonne foi utiliser les données en OdBL?
>
> --
> 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

[OSM-talk-fr] Avignon : mise à jour du tuilage trop longue !!!

[ZIMMY]

Bonjour,

J'ai mis à jour le commerce à Avignon rue  Joseph Vernet face au musée
Calvet jeudi matin et même le lendemain ils n'apparaissent pas !
http://www.openstreetmap.org/?lat=43.946698&lon=4.804022&zoom=18

Quelqu'un peut-il forcer la mise à jour à cet endroit ?

-
Cordialement,
ZIMMY
Jean-Louis ZIMMERMANN
Développeur territorial (ville d'Orange,FR84)
Mandataire OSM-France sur le Grand-Sud-est
--
View this message in context: 
http://gis.19327.n5.nabble.com/Avignon-mise-a-jour-du-tuilage-trop-longue-tp5710113.html
Sent from the France mailing list archive at Nabble.com.

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

[OSM-talk-fr] Osmose - Tag source illegal ou incomplet IGN

[Maetma 91]

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.

 Faut-il les supprimer?

Le test peut-il être filter pour les ignorer ? Merci.

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

Re: [OSM-talk-fr] Avignon : mise à jour du tuilage trop longue !!!

[Ab_fab]

Bonjour Jean-Louis

Le restaurant "La Cour d'Honneur" et le magasin de vêtements "Lola"
s'affichent chez moi.

Pas le marchand de chaussures que l'on peut voir dans les données.
Mais là c'est plutôt une histoire de feuille de style.

As-tu vidé le cache de ton navigateur ?

PS : Les marchands de chaussures sont visibles dans OSM Interest, mais peut
être pas aussi rapidement
http://178.32.101.237/osminterest/?zoom=18&lat=43.94645&lon=4.80419&layers=B0TTT

Bonne journée

Le 25 mai 2012 08:41, ZIMMY  a écrit :

> Bonjour,
>
> J'ai mis à jour le commerce à Avignon rue  Joseph Vernet face au musée
> Calvet jeudi matin et même le lendemain ils n'apparaissent pas !
> http://www.openstreetmap.org/?lat=43.946698&lon=4.804022&zoom=18
>
> Quelqu'un peut-il forcer la mise à jour à cet endroit ?
>
> -
> Cordialement,
> ZIMMY
> Jean-Louis ZIMMERMANN
> Développeur territorial (ville d'Orange,FR84)
> Mandataire OSM-France sur le Grand-Sud-est
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Avignon-mise-a-jour-du-tuilage-trop-longue-tp5710113.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
ab_fab 
"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Avignon : mise à jour du tuilage trop longue !!!

[kimaidou]

Bonjour

Oups, non pas aussi rapidement en ce moment.
Depuis le 1er avril, je n'ai pas remis à jour la base de données. Il faut
que je m'y attelle.. Normallement ensuite ce sera comme avant, mise à jour
une fois par nuit.

Bonne journée
Michael

Le 25 mai 2012 08:56, Ab_fab  a écrit :

> Bonjour Jean-Louis
>
> Le restaurant "La Cour d'Honneur" et le magasin de vêtements "Lola"
> s'affichent chez moi.
>
> Pas le marchand de chaussures que l'on peut voir dans les données.
> Mais là c'est plutôt une histoire de feuille de style.
>
> As-tu vidé le cache de ton navigateur ?
>
> PS : Les marchands de chaussures sont visibles dans OSM Interest, mais
> peut être pas aussi rapidement
>
> http://178.32.101.237/osminterest/?zoom=18&lat=43.94645&lon=4.80419&layers=B0TTT
>
> Bonne journée
>
> Le 25 mai 2012 08:41, ZIMMY  a écrit :
>
> Bonjour,
>>
>> J'ai mis à jour le commerce à Avignon rue  Joseph Vernet face au musée
>> Calvet jeudi matin et même le lendemain ils n'apparaissent pas !
>> http://www.openstreetmap.org/?lat=43.946698&lon=4.804022&zoom=18
>>
>> Quelqu'un peut-il forcer la mise à jour à cet endroit ?
>>
>> -
>> Cordialement,
>> ZIMMY
>> Jean-Louis ZIMMERMANN
>> Développeur territorial (ville d'Orange,FR84)
>> Mandataire OSM-France sur le Grand-Sud-est
>> --
>> View this message in context:
>> http://gis.19327.n5.nabble.com/Avignon-mise-a-jour-du-tuilage-trop-longue-tp5710113.html
>> Sent from the France mailing list archive at Nabble.com.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> ab_fab 
> "Il n'y a pas de pas perdus"
>
> ___
> 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