Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Bonjour Le 01/11/2013 22:46, Ista Pouss a écrit : Le 1 novembre 2013 20:15, allegre.guilla...@free.fr mailto:allegre.guilla...@free.fr a écrit : De: Ista Pouss ista...@gmail.com mailto:ista...@gmail.com Et même la cartopartie dans son ensemble, avec quelque organisation, pourrait faire l'objet d'un article wikipedia... (style Parcours de la place Edmond Maurat) (HEU NON je veux dire de la Concorde). Ça non, l'événement cartopartie sera très certainement considéré comme non admissible dans WP par la grande majorité des contributeurs (et bien que plutôt inclusionniste, je serais d'accord). Oui tu as raison c'était une énorme grosse bourde de ma part, honte éternelle ! Bon... donc c'est foiré pour wikimedia, par cette approche. Je passe mon tour. Pas aussi fermé, mais à voir avec Wikivoyage. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
- Mail original - De: Ista Pouss ista...@gmail.com À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Jeudi 31 Octobre 2013 14:29:18 Objet: Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia Le 31 octobre 2013 11:52, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Je ne crois pas que ça puisse fonctionner dans le cadre des notes, car, pour être importée sur commons, il faut que la photo puisse avoir un usage éducatif, ou puisse avoir une utilisation dans un projet wikimedia : https://commons.wikimedia.org/wiki/Commons:Crit%C3%A8res_d%27inclusion#Objectifs_de_Commons Je suis d'accord. Si la photo ne sert qu'à mettre en évidence une erreur OSM, elle n'a probablement rien à faire sur Commons. Par contre, les éventuelles photos d'une cartopartie (et même peut être les traces GPS), pourraient, avec un peu de rigueur, un peu de formalisme encyclopédique, être intégrées à commons : les intérêts encyclopédique et éducatif me paraissent plus défendables. Oui, à condition que ce ne soient pas juste des photos de type bloc-notes ou photo de devanture. Et même la cartopartie dans son ensemble, avec quelque organisation, pourrait faire l'objet d'un article wikipedia... (style Parcours de la place Edmond Maurat) (HEU NON je veux dire de la Concorde). Ça non, l'événement cartopartie sera très certainement considéré comme non admissible dans WP par la grande majorité des contributeurs (et bien que plutôt inclusionniste, je serais d'accord). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Le 1 novembre 2013 20:15, allegre.guilla...@free.fr a écrit : De: Ista Pouss ista...@gmail.com Et même la cartopartie dans son ensemble, avec quelque organisation, pourrait faire l'objet d'un article wikipedia... (style Parcours de la place Edmond Maurat) (HEU NON je veux dire de la Concorde). Ça non, l'événement cartopartie sera très certainement considéré comme non admissible dans WP par la grande majorité des contributeurs (et bien que plutôt inclusionniste, je serais d'accord). Oui tu as raison c'était une énorme grosse bourde de ma part, honte éternelle ! Bon... donc c'est foiré pour wikimedia, par cette approche. Je passe mon tour. -- Les dérives de rue : C’est chanter que je veux http://drivrsdu.fr/cest-chanter-que-je-veux/ http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Le 30 octobre 2013 12:05, Pieren pier...@gmail.com a écrit : 2013/10/29 Guillaume Allegre allegre.guilla...@free.fr: Voici donc la suite, un peu plus polémique (forcément), et parfois franchement provoc (et sans doute un peu trop long) http://gallaxie.wordpress.com/2013/10/28/openstreetmap-vs-wikipedia-23-differences-et-divergences/ Je ne suis pas contributeur wikipedien et je suis donc mal placé pour critiquer ce côté là. Mais concernant OSM, il manque certains points importants dans la comparaison: - homogénéité : si la longueur des articles sur wikipedia et le niveau des détails dans OSM dépendent tous les deux directement du nombre de contributeurs s'y afférant, on pardonne beaucoup moins à OSM de tels écarts d'informations entre zones géographiques. Ces grands écarts entre zones qui ont tout (rues, adresses, POI) et celles qui n'ont rien empêchent toute exploitation à grande échelle. On peut juste espérer que ces écarts se comblent avec le temps mais rien n'est moins sûr. C'est le principal argument avancé par l'IGN lorsqu'ils parlent d'OSM. Et sur ce point, ils ont raison. Homogénéité d'exhaustivité... oui, c'est très variable sur OSM. En même temps, une parfaite homogénéité d'exhaustivité peut être un énorme frein pour avancer et innover. Le cas de l'IGN est intéressant. Sa mission de service public l'oblige à traiter tout les territoires avec le même niveau de détail (en théorie). Donc avant de passer à un niveau de détail supplémentaire, il faut un énorme travail pour l'atteindre à peu près partout. OSM ne s'embarasse heureusement pas de ce traitement identique des territoires. Si on avait mis en place une telle logique, on serait bloqués à de nombreux endroits car d'autres n'ont pas atteint le niveau minimal pour passer globalement au suivant. Oui, du coup, rien qu'en France on a des zone hyper détaillées où il ne manquera pas une bande podo-tactile sur un passage piéton alors un peu plus loin il manque encore des routes départementales. - vandalisme : les cas sont peut-être beaucoup plus nombreux qu'on ne le pense parce que dans OSM, il est plus difficile d'avoir un suivi des transformations sur une zone que wikipedia sur un article. Et les outils de contrôle ont aussi des lacunes (voir dernier point) Si, par exemple, on peut voir une version T-n_days dans wikipedia en 2 clics de souris, retrouver les données d'une zone géographique à T-n_days dans OSM nécessite beaucoup de temps, de ressources et connaissances informatiques. Et pour le cas où un petit vandalisme ou disons, altération négative lorsque ça n'est pas volontaire, est détecté, il n'y a pas d'outil pour facilement revenir en arrière alors que le undo sur wikipedia se fait en deux clics de souris. Il y a donc un déséquilibre manifeste entre contributions positives et négatives puisque les outils manquent pour lutter contre les secondes. On peut alors assister à deux phénomènes : soit le contributeur abandonne le projet suite à une frustration légitime. Ou alors, il délègue cette tâche à d'autres, en passant par cette liste par exemple ou sur un forum ou par le DWG. C'est ce qui se passe plus ou moins bien depuis les débuts d'OSM et certains sont même satisfait de ce modèle. Mais cela ne marche que s'il y a suffisament de volontaires pour prendre en charge ces annulations et que si elles se font suffisament tôt (techniquement, plus on attends, plus c'est difficile, voire impossible). Et si le nombre de vandalismes venait à fortement augmenter, ce petit groupe ne sera plus capable de faire face. Un des gros points forts de wikipedia est que les annulations sont directement et facilement accessibles par tout le monde. C'est un point majeur pour les projets collaboratifs qu'OSM ne propose pas. +1 ! Plutôt que de parler de vandalisme, je préfère la notion de dégradation volontaire ou involontaire. Les dégradations volontaires sont rares, très rares. Les involontaires sont fréquentes chez les nouveaux contributeurs, mais pas que. Il nous arrive à tous de faire des erreurs. Nous manquons vraiment d'outils à ce niveau pour réparer, mais c'est vrai aussi que ça limite les guerres d'édition et l'annulation presse-bouton un peu facile. La principale difficulté étant je pense les données supprimées et leur impact. Il reste par exemple encore pas mal de zones impactées par la redaction. Je regrette aussi que l'API ne soit pas plus regardante sur les données qu'on lui envoie. Il n'y a quasiment aucun contrôle, ce qui permet de créer des way avec moins de 2 nœuds, des ways non conformes (repassant par le même nœud), des tags vides, etc. Historiquement ça peut se comprendre sur le plan technique (capacité de traitement limité sur les premières implémentations), mais cette absence de tout contrôle ça semble être devenue un principe et je n'en vois pas le bienfait. - sémantique : les tags sont nombreux dans OSM, trop nombreux. Les erreurs de typo ne sont que lentement corrigés, voir pas du
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Pour limiter ce système administratif et se réorienter vers la volarisation du terrain, je suis surpris que Notes ne permette pas de joindre des photos (voir videos) en partenariat avec commons ou d'autres acteurs (projet streetview osm). À l'image de ce que fait wikilovesmonuments ou commons. Chaque utilisateur de rendu pourra y apporter sa vision pour son usge final (rendu ou autre). Le 31 oct. 2013 01:15, Ista Pouss ista...@gmail.com a écrit : Le 30 octobre 2013 23:55, Guillaume Allegre allegre.guilla...@free.fr a écrit : Oui... le modèle osm est une base de données ne fonctionne pas, c'est ce que je pense. Il pose des problèmes irrésolvables de sémantique et de contrôle, entres autres. Tiens, je ne vois pas ce qui te permet de dire ça. Moi je trouve que le modèle de la DB est plutôt bien respecté par OSM (c'est d'ailleurs le problème des reverts impossibles après une autre édition, contrairement au modèle des commits de WP, qu'on sait traiter en texte depuis belle lurette). Heu je me suis mal exprimé que tu m'as mal compris : ce n'est pas qu'il soit bien ou mal respecté que je pense, mais que, par conception, il ne peut pas fonctionner. Certes on arrive toujours à faire des cartes, mais on va de plus en plus dans un modèle administratif, et de moins en moins dans une observation terrain, de mon opinion. C'est parce que sémantique comme contrôle sont des opérations qui dépendent d'une vision, donc d'un mode de rendu. Même une chose qu'on croit exister par elle même dépend d'une vision pour la manipuler, la décrire, la positionner dans l'espace. Or le rendu est considéré comme une sorte d'optionalité, de pluralité libre, et on en conclus que les données doivent être entrées en dehors de tout rendu... mais on perd alors leur sémantique et leur contrôle. Heu... suis-je plus clair ? La solution de mon opinion serait d'interdire purement et simplement toute entrée de données qui n'ait pas au moins un rendu référent... (Mais je ne pense pas que ça soit la tendance actuelle dans la communauté :-) Impossible de faire des cartes avec une base de données, c'est mon opinion : pour faire des cartes il faut d'abord faire de la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par les datas. Je ne comprends vraiment pas ce que tu veux dire, si tu pouvais développer ? La cartographie, ce n'est pas seulement des objets géolocalisés : c'est des objets qu'on projette sur une page blanche, cette projection et ces objets conservant les propriétés que l'on veut, en général les rapports de distance. Par exemple, je peux suivre une route sur une carte et en déduire la distance que je vais parcourir dans la réalité. (heureusement). En se focalisant sur les datas, on perd cette notion de projection. Par exemple le problème des trottoirs, que tantôt on accole à la route principale, que tantôt on trace comme chemin dissocié, ou tantôt comme surface, on éprouve les plus grandes difficultés à savoir ce qu'il faut faire et pourquoi, et encore plus à relier les trottoirs avec les routes, et même les trottoirs entre eux cela vient (de mon opinion) que l'on mélange différents types de projection sans en avoir conscience. La communauté est bien au courant qu'il existe différent types de projection pour la terre, mais elle ne semble pas savoir qu'il existe des types de projection pour les trottoirs, et pratiquement tout ce qui existe. Si l'on admet que j'ai à peu près raison et que je puisse proposer un début de solution, je la vois dans le fait que j'entends quelque fois parler d'OSM non pas comme une base de données, mais comme un éco-système de description terrain. Dans cet écosystème, données, rendus, informatique ne sont pas indépendant les uns des autres, mais se nourrissent les uns les autres, pour tendre au résultat... OSM fonctionne déjà un peu comme ça, mais sans le dire vraiment. Cette approche me parait infiniment plus porteuse, et très originale par rapport à wikipedia. (bien qu'il existe qqchose d'un peu similaire entre wikipedia et commons). Bon, et j'ai toujours pas taggué le col de la république, moi... j'y repense demain. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Voilà l'appli à créer... OSMphotoNotes... prise d'une photo géolocalisée, partagée via une note et un lien qui pointe dessus. Ca permet de documenter la note bien plus efficacement qu'un texte. Par contre, il va falloir gérer les dérives... Le 31 octobre 2013 10:23, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Pour limiter ce système administratif et se réorienter vers la volarisation du terrain, je suis surpris que Notes ne permette pas de joindre des photos (voir videos) en partenariat avec commons ou d'autres acteurs (projet streetview osm). À l'image de ce que fait wikilovesmonuments ou commons. Chaque utilisateur de rendu pourra y apporter sa vision pour son usge final (rendu ou autre). Le 31 oct. 2013 01:15, Ista Pouss ista...@gmail.com a écrit : Le 30 octobre 2013 23:55, Guillaume Allegre allegre.guilla...@free.fra écrit : Oui... le modèle osm est une base de données ne fonctionne pas, c'est ce que je pense. Il pose des problèmes irrésolvables de sémantique et de contrôle, entres autres. Tiens, je ne vois pas ce qui te permet de dire ça. Moi je trouve que le modèle de la DB est plutôt bien respecté par OSM (c'est d'ailleurs le problème des reverts impossibles après une autre édition, contrairement au modèle des commits de WP, qu'on sait traiter en texte depuis belle lurette). Heu je me suis mal exprimé que tu m'as mal compris : ce n'est pas qu'il soit bien ou mal respecté que je pense, mais que, par conception, il ne peut pas fonctionner. Certes on arrive toujours à faire des cartes, mais on va de plus en plus dans un modèle administratif, et de moins en moins dans une observation terrain, de mon opinion. C'est parce que sémantique comme contrôle sont des opérations qui dépendent d'une vision, donc d'un mode de rendu. Même une chose qu'on croit exister par elle même dépend d'une vision pour la manipuler, la décrire, la positionner dans l'espace. Or le rendu est considéré comme une sorte d'optionalité, de pluralité libre, et on en conclus que les données doivent être entrées en dehors de tout rendu... mais on perd alors leur sémantique et leur contrôle. Heu... suis-je plus clair ? La solution de mon opinion serait d'interdire purement et simplement toute entrée de données qui n'ait pas au moins un rendu référent... (Mais je ne pense pas que ça soit la tendance actuelle dans la communauté :-) Impossible de faire des cartes avec une base de données, c'est mon opinion : pour faire des cartes il faut d'abord faire de la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par les datas. Je ne comprends vraiment pas ce que tu veux dire, si tu pouvais développer ? La cartographie, ce n'est pas seulement des objets géolocalisés : c'est des objets qu'on projette sur une page blanche, cette projection et ces objets conservant les propriétés que l'on veut, en général les rapports de distance. Par exemple, je peux suivre une route sur une carte et en déduire la distance que je vais parcourir dans la réalité. (heureusement). En se focalisant sur les datas, on perd cette notion de projection. Par exemple le problème des trottoirs, que tantôt on accole à la route principale, que tantôt on trace comme chemin dissocié, ou tantôt comme surface, on éprouve les plus grandes difficultés à savoir ce qu'il faut faire et pourquoi, et encore plus à relier les trottoirs avec les routes, et même les trottoirs entre eux cela vient (de mon opinion) que l'on mélange différents types de projection sans en avoir conscience. La communauté est bien au courant qu'il existe différent types de projection pour la terre, mais elle ne semble pas savoir qu'il existe des types de projection pour les trottoirs, et pratiquement tout ce qui existe. Si l'on admet que j'ai à peu près raison et que je puisse proposer un début de solution, je la vois dans le fait que j'entends quelque fois parler d'OSM non pas comme une base de données, mais comme un éco-système de description terrain. Dans cet écosystème, données, rendus, informatique ne sont pas indépendant les uns des autres, mais se nourrissent les uns les autres, pour tendre au résultat... OSM fonctionne déjà un peu comme ça, mais sans le dire vraiment. Cette approche me parait infiniment plus porteuse, et très originale par rapport à wikipedia. (bien qu'il existe qqchose d'un peu similaire entre wikipedia et commons). Bon, et j'ai toujours pas taggué le col de la république, moi... j'y repense demain. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Pas forcément à créer mais éventuellement à réutiliser, cela permettra une collaboration commune wikimedia/OSM. Actions OpenStreetMap : * Notes doit pouvoir prendre les images Commons et recevoir les éléments saisis lors de la capture * Créer un système officiel d'affichage des images Commons (semble faisable : http://toolserver.org/~kolossos/openlayers/commons-on-osm.php?lat=52.516389lon=13.38zoom=15 ) Actions Wikimedia : * modifier l'application commons pour incorporer le nécessaire à l'identification d'une photo pour une note et permettre la localisation manuelle de la note : https://play.google.com/store/apps/details?id=org.wikimedia.commonshl=fr * les critères d'inclusion de commons : https://commons.wikimedia.org/wiki/Commons:Crit%C3%A8res_d%27inclusion (et encore, il y a énormément d'articles sur les rues, villes, rivières... Mais c'est surtout qu'OpenStreetMap n'est pas un projet de la sphère Wikimedia) Actions communes : * Passerelles éventuelles entre les utilisateurs Wikimedia OpenStreetMap (OpenID ?) -- Jean-Baptiste Holcroft Le 31 octobre 2013 10:38, Christian Quest cqu...@openstreetmap.fr a écrit : Voilà l'appli à créer... OSMphotoNotes... prise d'une photo géolocalisée, partagée via une note et un lien qui pointe dessus. Ca permet de documenter la note bien plus efficacement qu'un texte. Par contre, il va falloir gérer les dérives... Le 31 octobre 2013 10:23, Jean-Baptiste Holcroft jb.holcr...@gmail.coma écrit : Pour limiter ce système administratif et se réorienter vers la volarisation du terrain, je suis surpris que Notes ne permette pas de joindre des photos (voir videos) en partenariat avec commons ou d'autres acteurs (projet streetview osm). À l'image de ce que fait wikilovesmonuments ou commons. Chaque utilisateur de rendu pourra y apporter sa vision pour son usge final (rendu ou autre). Le 31 oct. 2013 01:15, Ista Pouss ista...@gmail.com a écrit : Le 30 octobre 2013 23:55, Guillaume Allegre allegre.guilla...@free.fra écrit : Oui... le modèle osm est une base de données ne fonctionne pas, c'est ce que je pense. Il pose des problèmes irrésolvables de sémantique et de contrôle, entres autres. Tiens, je ne vois pas ce qui te permet de dire ça. Moi je trouve que le modèle de la DB est plutôt bien respecté par OSM (c'est d'ailleurs le problème des reverts impossibles après une autre édition, contrairement au modèle des commits de WP, qu'on sait traiter en texte depuis belle lurette). Heu je me suis mal exprimé que tu m'as mal compris : ce n'est pas qu'il soit bien ou mal respecté que je pense, mais que, par conception, il ne peut pas fonctionner. Certes on arrive toujours à faire des cartes, mais on va de plus en plus dans un modèle administratif, et de moins en moins dans une observation terrain, de mon opinion. C'est parce que sémantique comme contrôle sont des opérations qui dépendent d'une vision, donc d'un mode de rendu. Même une chose qu'on croit exister par elle même dépend d'une vision pour la manipuler, la décrire, la positionner dans l'espace. Or le rendu est considéré comme une sorte d'optionalité, de pluralité libre, et on en conclus que les données doivent être entrées en dehors de tout rendu... mais on perd alors leur sémantique et leur contrôle. Heu... suis-je plus clair ? La solution de mon opinion serait d'interdire purement et simplement toute entrée de données qui n'ait pas au moins un rendu référent... (Mais je ne pense pas que ça soit la tendance actuelle dans la communauté :-) Impossible de faire des cartes avec une base de données, c'est mon opinion : pour faire des cartes il faut d'abord faire de la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par les datas. Je ne comprends vraiment pas ce que tu veux dire, si tu pouvais développer ? La cartographie, ce n'est pas seulement des objets géolocalisés : c'est des objets qu'on projette sur une page blanche, cette projection et ces objets conservant les propriétés que l'on veut, en général les rapports de distance. Par exemple, je peux suivre une route sur une carte et en déduire la distance que je vais parcourir dans la réalité. (heureusement). En se focalisant sur les datas, on perd cette notion de projection. Par exemple le problème des trottoirs, que tantôt on accole à la route principale, que tantôt on trace comme chemin dissocié, ou tantôt comme surface, on éprouve les plus grandes difficultés à savoir ce qu'il faut faire et pourquoi, et encore plus à relier les trottoirs avec les routes, et même les trottoirs entre eux cela vient (de mon opinion) que l'on mélange différents types de projection sans en avoir conscience. La communauté est bien au courant qu'il existe différent types de projection pour la terre, mais elle ne semble pas savoir qu'il existe des types de projection pour les trottoirs, et pratiquement tout ce qui existe. Si l'on admet que j'ai à peu près raison et
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Le 31 octobre 2013 10:23, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Pour limiter ce système administratif et se réorienter vers la volarisation du terrain, je suis surpris que Notes ne permette pas de joindre des photos (voir videos) en partenariat avec commons ou d'autres acteurs (projet streetview osm). À l'image de ce que fait wikilovesmonuments ou commons. Chaque utilisateur de rendu pourra y apporter sa vision pour son usge final (rendu ou autre). Pour préciser, je ne suis pas contre le système administratif, et encore moins contre l'open data ! (...mais c'est vrai que je serais plutot POUR le terrain) Ce qui me déplait en cette affaire est que les données administratives tendent à être considérées comme des choses concrètes. Par exemple pour nombre de gens une limite communale est une chose concrète. Il faut quasiment qu'ils aillent voir sur le terrain pour se rendre compte qu'il n'y a aucune ligne entre Paris et Issy les moulineaux... Ce n'est déjà qu'un rendu : le rendu administratif. Mais une fois que c'est dit et admis, je n'ai rien contre les données administratives, bien au contraire. Pour en reparler j'admire par exemple le travail sur les limites communales mené au sein d'osm. Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Le 31 octobre 2013 11:52, Jean-Baptiste Holcroft jb.holcr...@gmail.com a écrit : Pas forcément à créer mais éventuellement à réutiliser, cela permettra une collaboration commune wikimedia/OSM. Je ne crois pas que ça puisse fonctionner dans le cadre des notes, car, pour être importée sur commons, il faut que la photo puisse avoir un usage éducatif, ou puisse avoir une utilisation dans un projet wikimedia : https://commons.wikimedia.org/wiki/Commons:Crit%C3%A8res_d%27inclusion#Objectifs_de_Commons Dans le cadre des notes, c'est un usage interne à OSM, qui n'a pas vocation à être utile dans un contexte éducatif ou wikimedia. Par contre, les éventuelles photos d'une cartopartie (et même peut être les traces GPS), pourraient, avec un peu de rigueur, un peu de formalisme encyclopédique, être intégrées à commons : les intérêts encyclopédique et éducatif me paraissent plus défendables. Et même la cartopartie dans son ensemble, avec quelque organisation, pourrait faire l'objet d'un article wikipedia... (style Parcours de la place Edmond Maurat) (HEU NON je veux dire de la Concorde). A+. http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
2013/10/29 Guillaume Allegre allegre.guilla...@free.fr: Voici donc la suite, un peu plus polémique (forcément), et parfois franchement provoc (et sans doute un peu trop long) http://gallaxie.wordpress.com/2013/10/28/openstreetmap-vs-wikipedia-23-differences-et-divergences/ Je ne suis pas contributeur wikipedien et je suis donc mal placé pour critiquer ce côté là. Mais concernant OSM, il manque certains points importants dans la comparaison: - homogénéité : si la longueur des articles sur wikipedia et le niveau des détails dans OSM dépendent tous les deux directement du nombre de contributeurs s'y afférant, on pardonne beaucoup moins à OSM de tels écarts d'informations entre zones géographiques. Ces grands écarts entre zones qui ont tout (rues, adresses, POI) et celles qui n'ont rien empêchent toute exploitation à grande échelle. On peut juste espérer que ces écarts se comblent avec le temps mais rien n'est moins sûr. C'est le principal argument avancé par l'IGN lorsqu'ils parlent d'OSM. Et sur ce point, ils ont raison. - vandalisme : les cas sont peut-être beaucoup plus nombreux qu'on ne le pense parce que dans OSM, il est plus difficile d'avoir un suivi des transformations sur une zone que wikipedia sur un article. Et les outils de contrôle ont aussi des lacunes (voir dernier point) Si, par exemple, on peut voir une version T-n_days dans wikipedia en 2 clics de souris, retrouver les données d'une zone géographique à T-n_days dans OSM nécessite beaucoup de temps, de ressources et connaissances informatiques. Et pour le cas où un petit vandalisme ou disons, altération négative lorsque ça n'est pas volontaire, est détecté, il n'y a pas d'outil pour facilement revenir en arrière alors que le undo sur wikipedia se fait en deux clics de souris. Il y a donc un déséquilibre manifeste entre contributions positives et négatives puisque les outils manquent pour lutter contre les secondes. On peut alors assister à deux phénomènes : soit le contributeur abandonne le projet suite à une frustration légitime. Ou alors, il délègue cette tâche à d'autres, en passant par cette liste par exemple ou sur un forum ou par le DWG. C'est ce qui se passe plus ou moins bien depuis les débuts d'OSM et certains sont même satisfait de ce modèle. Mais cela ne marche que s'il y a suffisament de volontaires pour prendre en charge ces annulations et que si elles se font suffisament tôt (techniquement, plus on attends, plus c'est difficile, voire impossible). Et si le nombre de vandalismes venait à fortement augmenter, ce petit groupe ne sera plus capable de faire face. Un des gros points forts de wikipedia est que les annulations sont directement et facilement accessibles par tout le monde. C'est un point majeur pour les projets collaboratifs qu'OSM ne propose pas. - sémantique : les tags sont nombreux dans OSM, trop nombreux. Les erreurs de typo ne sont que lentement corrigés, voir pas du tout. Il y a, par exemple, 910 valeurs différentes de highway et 983 valeurs différentes de landuse alors qu'il y en a 20 fois moins de documentés. Un autre point est que les tags sont facilement mal interprétés d'un pays à l'autre (amenity=college , power=station), mal utilisés (leisure=park pour une plate-bande de fleurs) ou ne sont pas cohérents, même à l'intérieur d'une zone géographique (chacun a sa propre interprétation d'un highway=tertiary ou du highway=path). Ainsi, si dans wikipedia, on appelle un chat un chat, dans OSM, une voie se verra affubler d'un highway=residential, highway=unclassified, highway=track ou même dans certains cas highway=service au choix et suivant le contributeur sans que cela ne soulève de protestations. J'ajouterais qu'une grande partie de ces problèmes ne sont pas détectables par des outils de qualité et qu'il faut mettre son nez dedans pour les trouver et ne pas tout voir au travers de la lorgnette d'osmose ou de keepright. - le contrôle : bien peu sont ceux qui contrôlent les données OSM en les téléchargeant dans JOSM. Alors que dans wikipedia, tout ce qui ajouté se voit immédiatement par tout lecteur, la plupart des erreurs dans OSM ne sont corrigées que si elles sont visibles donc rendues sur la carte principale. Les autres sont ignorées jusqu'à ce qu'un contributeur s'y intéresse, souvent par hasard, en passant en mode édition et qu'il voit soudainement l'ensemble des données. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Le 30 octobre 2013 12:05, Pieren pier...@gmail.com a écrit : - homogénéité : si la longueur des articles sur wikipedia et le niveau des détails dans OSM dépendent tous les deux directement du nombre de contributeurs s'y afférant, on pardonne beaucoup moins à OSM de tels écarts d'informations entre zones géographiques. Ces grands écarts entre zones qui ont tout (rues, adresses, POI) et celles qui n'ont rien empêchent toute exploitation à grande échelle. On peut juste espérer que ces écarts se comblent avec le temps mais rien n'est moins sûr. C'est le principal argument avancé par l'IGN lorsqu'ils parlent d'OSM. Et sur ce point, ils ont raison. Oui. Mais ça ne dépend pas seulement du nombre de contributeurs : l'homogénéité dépend aussi des règles que tu te donnes. Par exemple à wikipedia l'arrivée de l'éditeur wisiwig provoque la révision de nombre de modèles incompatibles, augmentant du coup l'homogénïté. Cependant il n'est pas complètement clair pour moi que l'homogénéïté, ou des notions proches telles que la cohérence, soient des fins en soi dans les projets collaboratifs. Ce qui est sûr est que ce sont des propriétés intéressantes à suivre, à améliorer, pouvant donner naissances à des règles faisant consensus. - vandalisme : les cas sont peut-être beaucoup plus nombreux qu'on ne le pense parce que dans OSM, il est plus difficile d'avoir un suivi des transformations sur une zone que wikipedia sur un article. Et les outils de contrôle ont aussi des lacunes (voir dernier point) Si, par exemple, on peut voir une version T-n_days dans wikipedia en 2 clics de souris, retrouver les données d'une zone géographique à T-n_days dans OSM nécessite beaucoup de temps, de ressources et connaissances informatiques. Et pour le cas où un petit vandalisme ou disons, altération négative lorsque ça n'est pas volontaire, est détecté, il n'y a pas d'outil pour facilement revenir en arrière alors que le undo sur wikipedia se fait en deux clics de souris. Il y a donc un déséquilibre manifeste entre contributions positives et négatives puisque les outils manquent pour lutter contre les secondes. On peut alors assister à deux phénomènes : soit le contributeur abandonne le projet suite à une frustration légitime. Ou alors, il délègue cette tâche à d'autres, en passant par cette liste par exemple ou sur un forum ou par le DWG. C'est ce qui se passe plus ou moins bien depuis les débuts d'OSM et certains sont même satisfait de ce modèle. Mais cela ne marche que s'il y a suffisament de volontaires pour prendre en charge ces annulations et que si elles se font suffisament tôt (techniquement, plus on attends, plus c'est difficile, voire impossible). Et si le nombre de vandalismes venait à fortement augmenter, ce petit groupe ne sera plus capable de faire face. Un des gros points forts de wikipedia est que les annulations sont directement et facilement accessibles par tout le monde. C'est un point majeur pour les projets collaboratifs qu'OSM ne propose pas. Oui. Espérons. - sémantique : les tags sont nombreux dans OSM, trop nombreux. Les [couic] - le contrôle : bien peu sont ceux qui contrôlent les données OSM en [couic] Oui... le modèle osm est une base de données ne fonctionne pas, c'est ce que je pense. Il pose des problèmes irrésolvables de sémantique et de contrôle, entres autres. Impossible de faire des cartes avec une base de données, c'est mon opinion : pour faire des cartes il faut d'abord faire de la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par les datas. Toutefois, en attendant que j'ai raison, je continue à contribuer :-) Ainsi, .en parcourant wikipedia, et en suivant les discussions osm, j'ai repéré à ma surprise que l'ultra-fréquenté col de la République ( https://fr.wikipedia.org/wiki/Col_de_la_R%C3%A9publique), théâtre d'un des plus tristes événements du Tour de France, n'était pas enregistré dans OSM !? Problème manifeste de homogénéité ! je compte l'y mettre dans la semaine :-) ...je suis surtout un petit contributeur qui parle beaucoup :-) http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Les pieds-tendres peuvent bien tenter des imports de données (parfois utiles, il faut bien le dire), ils n’auront jamais la gloire que confère un *source=GPS survey* judicieusement placé. ahah tout à fait vrai :) Le 30 octobre 2013 13:11, Ista Pouss ista...@gmail.com a écrit : Le 30 octobre 2013 12:05, Pieren pier...@gmail.com a écrit : - homogénéité : si la longueur des articles sur wikipedia et le niveau des détails dans OSM dépendent tous les deux directement du nombre de contributeurs s'y afférant, on pardonne beaucoup moins à OSM de tels écarts d'informations entre zones géographiques. Ces grands écarts entre zones qui ont tout (rues, adresses, POI) et celles qui n'ont rien empêchent toute exploitation à grande échelle. On peut juste espérer que ces écarts se comblent avec le temps mais rien n'est moins sûr. C'est le principal argument avancé par l'IGN lorsqu'ils parlent d'OSM. Et sur ce point, ils ont raison. Oui. Mais ça ne dépend pas seulement du nombre de contributeurs : l'homogénéité dépend aussi des règles que tu te donnes. Par exemple à wikipedia l'arrivée de l'éditeur wisiwig provoque la révision de nombre de modèles incompatibles, augmentant du coup l'homogénïté. Cependant il n'est pas complètement clair pour moi que l'homogénéïté, ou des notions proches telles que la cohérence, soient des fins en soi dans les projets collaboratifs. Ce qui est sûr est que ce sont des propriétés intéressantes à suivre, à améliorer, pouvant donner naissances à des règles faisant consensus. - vandalisme : les cas sont peut-être beaucoup plus nombreux qu'on ne le pense parce que dans OSM, il est plus difficile d'avoir un suivi des transformations sur une zone que wikipedia sur un article. Et les outils de contrôle ont aussi des lacunes (voir dernier point) Si, par exemple, on peut voir une version T-n_days dans wikipedia en 2 clics de souris, retrouver les données d'une zone géographique à T-n_days dans OSM nécessite beaucoup de temps, de ressources et connaissances informatiques. Et pour le cas où un petit vandalisme ou disons, altération négative lorsque ça n'est pas volontaire, est détecté, il n'y a pas d'outil pour facilement revenir en arrière alors que le undo sur wikipedia se fait en deux clics de souris. Il y a donc un déséquilibre manifeste entre contributions positives et négatives puisque les outils manquent pour lutter contre les secondes. On peut alors assister à deux phénomènes : soit le contributeur abandonne le projet suite à une frustration légitime. Ou alors, il délègue cette tâche à d'autres, en passant par cette liste par exemple ou sur un forum ou par le DWG. C'est ce qui se passe plus ou moins bien depuis les débuts d'OSM et certains sont même satisfait de ce modèle. Mais cela ne marche que s'il y a suffisament de volontaires pour prendre en charge ces annulations et que si elles se font suffisament tôt (techniquement, plus on attends, plus c'est difficile, voire impossible). Et si le nombre de vandalismes venait à fortement augmenter, ce petit groupe ne sera plus capable de faire face. Un des gros points forts de wikipedia est que les annulations sont directement et facilement accessibles par tout le monde. C'est un point majeur pour les projets collaboratifs qu'OSM ne propose pas. Oui. Espérons. - sémantique : les tags sont nombreux dans OSM, trop nombreux. Les [couic] - le contrôle : bien peu sont ceux qui contrôlent les données OSM en [couic] Oui... le modèle osm est une base de données ne fonctionne pas, c'est ce que je pense. Il pose des problèmes irrésolvables de sémantique et de contrôle, entres autres. Impossible de faire des cartes avec une base de données, c'est mon opinion : pour faire des cartes il faut d'abord faire de la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par les datas. Toutefois, en attendant que j'ai raison, je continue à contribuer :-) Ainsi, .en parcourant wikipedia, et en suivant les discussions osm, j'ai repéré à ma surprise que l'ultra-fréquenté col de la République ( https://fr.wikipedia.org/wiki/Col_de_la_R%C3%A9publique), théâtre d'un des plus tristes événements du Tour de France, n'était pas enregistré dans OSM !? Problème manifeste de homogénéité ! je compte l'y mettre dans la semaine :-) ...je suis surtout un petit contributeur qui parle beaucoup :-) http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Le mer. 30 oct. 2013 à 14:11 +0100, Ista Pouss a écrit : Oui... le modèle osm est une base de données ne fonctionne pas, c'est ce que je pense. Il pose des problèmes irrésolvables de sémantique et de contrôle, entres autres. Tiens, je ne vois pas ce qui te permet de dire ça. Moi je trouve que le modèle de la DB est plutôt bien respecté par OSM (c'est d'ailleurs le problème des reverts impossibles après une autre édition, contrairement au modèle des commits de WP, qu'on sait traiter en texte depuis belle lurette). Impossible de faire des cartes avec une base de données, c'est mon opinion : pour faire des cartes il faut d'abord faire de la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par les datas. Je ne comprends vraiment pas ce que tu veux dire, si tu pouvais développer ? -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Le 30 octobre 2013 23:55, Guillaume Allegre allegre.guilla...@free.fr a écrit : Oui... le modèle osm est une base de données ne fonctionne pas, c'est ce que je pense. Il pose des problèmes irrésolvables de sémantique et de contrôle, entres autres. Tiens, je ne vois pas ce qui te permet de dire ça. Moi je trouve que le modèle de la DB est plutôt bien respecté par OSM (c'est d'ailleurs le problème des reverts impossibles après une autre édition, contrairement au modèle des commits de WP, qu'on sait traiter en texte depuis belle lurette). Heu je me suis mal exprimé que tu m'as mal compris : ce n'est pas qu'il soit bien ou mal respecté que je pense, mais que, par conception, il ne peut pas fonctionner. Certes on arrive toujours à faire des cartes, mais on va de plus en plus dans un modèle administratif, et de moins en moins dans une observation terrain, de mon opinion. C'est parce que sémantique comme contrôle sont des opérations qui dépendent d'une vision, donc d'un mode de rendu. Même une chose qu'on croit exister par elle même dépend d'une vision pour la manipuler, la décrire, la positionner dans l'espace. Or le rendu est considéré comme une sorte d'optionalité, de pluralité libre, et on en conclus que les données doivent être entrées en dehors de tout rendu... mais on perd alors leur sémantique et leur contrôle. Heu... suis-je plus clair ? La solution de mon opinion serait d'interdire purement et simplement toute entrée de données qui n'ait pas au moins un rendu référent... (Mais je ne pense pas que ça soit la tendance actuelle dans la communauté :-) Impossible de faire des cartes avec une base de données, c'est mon opinion : pour faire des cartes il faut d'abord faire de la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par les datas. Je ne comprends vraiment pas ce que tu veux dire, si tu pouvais développer ? La cartographie, ce n'est pas seulement des objets géolocalisés : c'est des objets qu'on projette sur une page blanche, cette projection et ces objets conservant les propriétés que l'on veut, en général les rapports de distance. Par exemple, je peux suivre une route sur une carte et en déduire la distance que je vais parcourir dans la réalité. (heureusement). En se focalisant sur les datas, on perd cette notion de projection. Par exemple le problème des trottoirs, que tantôt on accole à la route principale, que tantôt on trace comme chemin dissocié, ou tantôt comme surface, on éprouve les plus grandes difficultés à savoir ce qu'il faut faire et pourquoi, et encore plus à relier les trottoirs avec les routes, et même les trottoirs entre eux cela vient (de mon opinion) que l'on mélange différents types de projection sans en avoir conscience. La communauté est bien au courant qu'il existe différent types de projection pour la terre, mais elle ne semble pas savoir qu'il existe des types de projection pour les trottoirs, et pratiquement tout ce qui existe. Si l'on admet que j'ai à peu près raison et que je puisse proposer un début de solution, je la vois dans le fait que j'entends quelque fois parler d'OSM non pas comme une base de données, mais comme un éco-système de description terrain. Dans cet écosystème, données, rendus, informatique ne sont pas indépendant les uns des autres, mais se nourrissent les uns les autres, pour tendre au résultat... OSM fonctionne déjà un peu comme ça, mais sans le dire vraiment. Cette approche me parait infiniment plus porteuse, et très originale par rapport à wikipedia. (bien qu'il existe qqchose d'un peu similaire entre wikipedia et commons). Bon, et j'ai toujours pas taggué le col de la république, moi... j'y repense demain. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Le 31 octobre 2013 01:15, Ista Pouss ista...@gmail.com a écrit : Heu je me suis mal exprimé que tu m'as mal compris : ce n'est pas qu'il soit bien ou mal respecté que je pense, mais que, par conception, il ne peut pas fonctionner. Certes on arrive toujours à faire des cartes, mais on va de plus en plus dans un modèle administratif, et de moins en moins dans une observation terrain, de mon opinion. Le modèle administrtif est juste l'infrstructure de référence de base, sur laquelle viennent ensuite s'accrocher toutes les autres infos (et corrections locales), il l'avantage cependnt d'une couverture à peu près équitable ou au moins suffisante du territoire. Cependant il n'est pas exemple d'erreurs dans les sources dont on dispose pour ces données, ce qui ne signifie pas qu'elles sont sans significations : cela veut juste dire souvent qu'elles manquent un peu de précision (ou parfois de mise à jour plus récente) si on veut accrocher autre chose autour, et c'est là qu'on fait les corrections nécessaires. Cependant c'est vrai aussi que la modélistion dans les sources n'est pas toujours très adaptée pour être directement intégrable (on le voit avec le cadastre, comem aussi avec d'autres sources qui ont des tags spécifiques assez exotiques à réintégrer en trouvant des mappings intelligents utilisbles aussi avec d'autres sources : Ces modélisations tierces ne sont pas à reproduire in extenso, elles sont soit trop précises, dans un contexte purement adinistratif franco-français sans équivalent possible ailleurs ou dans d'autres domaines (auquel cas il faudra passer par des sous-tags d'un autre tag plus générique), soit pas assez (car dans OSM on a pu généraliser des tags descriptifs plus précis : le travail d'intégration demande au minimum de ne pas saccger/supprimer ces sous-classifictions collectives venant d'autres sources, et sinon de pouvoir indiquer dns les données importées que la sous-clssification n'a ps été faite et reste encore trop générique : exemple de building=yes qui ne doit pas remplacer d'autres valeurs existantes de building=*) Et au final aucune de ces sources administrtaives n'a vocation à être réutilisées verbatim dans OSM, c'est tout l'intérêt de l'intégration demandée qui doit chercher à faire cohabiter les différentes sources, qu'elles soient administratives ou d'origine privée, du terrain ou non (imagerie par exemple). Les données de terrain ne sont pas non plus suffisantes : (1) il n'est pas toujours possible de savoir sans utiliser une base de données ouverte tierce: pour des raisons de droit d'accès au terrain ou des raisons légales de protection des données personnelles ou de données commerciales exclusives, on doit demander la permission à la source, et lui faire confiance sur les données qu'elle propose. (2) la couverture du terrain sera toujours très inégale sur le territoire en fonction de * la densité de population, qui influe très directement sur celle des contributeurs locaux, * ou de difficultés locales d'accès à Internet et de défaut d'équipement chez les particuliers locaux (lié à un certain niveau de développement économique, ou des prix pratiqués localement chez les fournisseurs sans grande concurrence locale) * des difficultés de déplacement sur place (prendre en compte l'équipement de transport, privé ou public, et son coût d'usage en argent et en temps) * ou de la présence ou pas sur place d'organisations et associations d'aide et développement au niveau humanitaire (alimentation, santé, assainisssament), social (logement, aide au travail, handicap, enfance et vieillesse), éducatif (y compris la formation professionnelle des adultes), sportif et culturel, ou de sociétés privées en charge de missions de service public (et qui doivent alors rendre des comptes sur les données de leur activité) comme les transports ou l'environnement ou les concessions (voirie, mines, fréquences)... * la présence locale et l'intérêt des grands médias. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Le lun. 21 oct. 2013 à 10:21 +0200, Florence Devouard a écrit : On 10/20/13 7:54 PM, Guillaume Allegre wrote: Twitté car un excellent résumé. J'attend avec impatience la deuxième partie du tryptique ! Flo Le lun. 21 oct. 2013 à 10:43 +0200, Nicolas Moyroud a écrit : Merci pour cet excellent article Guillaume. D'une manière générale, je trouve que ce blog démarre fort ! J'aime le ton décalé qui fait qu'on apprend des choses en s'amusant. J'ai aussi lu le billet sur l'unicode et les 5 libertés du logiciel libre. Excellent le tableau de synthèse des libertés atomiques. On veut plus de billets !! ;-) Merci pour vos encouragements. Voici donc la suite, un peu plus polémique (forcément), et parfois franchement provoc (et sans doute un peu trop long) http://gallaxie.wordpress.com/2013/10/28/openstreetmap-vs-wikipedia-23-differences-et-divergences/ -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia
Le 29 octobre 2013 19:44, Guillaume Allegre allegre.guilla...@free.fr a écrit : Merci pour vos encouragements. Voici donc la suite, un peu plus polémique (forcément), et parfois franchement provoc (et sans doute un peu trop long) http://gallaxie.wordpress.com/2013/10/28/openstreetmap-vs-wikipedia-23-differences-et-divergences/ BIEN. VIFS ENCOURAGEMENTS. -- Les dérives de rue : C’est chanter que je veux http://drivrsdu.fr/cest-chanter-que-je-veux/ http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
