Re: [OSM-talk-fr] Héritage et relation
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
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
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
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 maetm...@gmail.com: 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
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=16lat=45.799076lon=4.757899item=5050 http://osmose.openstreetmap.fr/map/?zoom=16lat=45.741816lon=4.918472item=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
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
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
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
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 Rogelchristian.ro...@club-internet.fr 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
Selon Christian Rogel christian.ro...@club-internet.fr: 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.213574lon=-1.558525zoom=18layers=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
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
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.311335lon=1.997581zoom=18layers=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
Le 24 mai 2012 06:16, Balaitous balait...@mailoo.org 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, troll!-- comme ça c'est clair -- 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 ! /troll 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
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
Le jeudi 24 mai 2012 à 14:47 +0200, Marc SIBERT a écrit : Le 24 mai 2012 06:16, Balaitous balait...@mailoo.org 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, troll!-- comme ça c'est clair -- 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 ! /troll 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
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
De : Balaitous balait...@mailoo.org 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
Bonjour, troll!-- comme ça c'est clair -- 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 ! /troll Ç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
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
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
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
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 proposition de relation genre collected tag. Dans ce que tu décris, je ne vois pas de relation
[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. 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
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 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
De : Philippe Verdy verd...@wanadoo.fr 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
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
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
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
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
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
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 hendrikmail2...@yahoo.de 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
