Re: [OSM-talk-fr] Nom d'un groupe d'îles - ar chipel
On lundi 16 novembre 2009, Eric SIBERT wrote: Merci Christian pour m'avoir pointé sur le bon mot-clé. Pour le mot clef, pourquoi pas, mais la proposition ici : http://wiki.openstreetmap.org/wiki/Proposed_features/Archipelago regroupe selon moi toutes les mauvaises pratiques d'osm ! * is_in, is in quoi ? et si le nom du gros archipel change (typo, redécoupage, rétro-cession) ça foire le is_in (et puis basé un is_in sur le nom c'est risqué en cas de doublons comme dit plus bas) * Un point pour placer un archipel, quelle drôle d'idée. Quand on a rien d'autre, pourquoi pas, mais sinon osm a inventé les surfaces depuis quelques temps Bref, oups, edit : sur la page de discussion quelqu'un de très réfléchis semble avoir émis grosso modo les mêmes réserves Avec le is_in:archipelago de la proposition, je vois un risque de confusion si plusieurs archipels ont le même nom (ex : Western Islands). +1 et pour d'autres raisons encore Je serais plus partisan d'une relation. Je vais faire un commentaire dans ce sens là sur la proposition. +1 (et crotte ça m'apprendra à ne pas lire d'abord les messages en entier) Quant au multipolygon (+/- outeur), je suis dubitatif. Autant je comprends bien pour une enclave/excalve de parc naturel ou d'une entité administrative, autant pour un groupe d'îles, je n'ai pas l'impression d'avoir à faire à une enclave/excalve. C'est pourquoi en parle de inner/outer dans la proposition des multipolygon. C'est, à mon sens, un artifice quasi-purement technique pour représenter une seule entité comme composée de plusieurs polygones avec ou sans trous. La proposition, toutefois, précise que le rôle outer sera supposé s'il n'y en a pas. Dans le cas d'un archipel, il me semble alors logique de tout simplement ajouter les îles à la relation et de donner un name=archipel truc bidule à cette relation en plus d'un place=archipelago et de type=multipolygon En gros, je ne me sers jamais de outer qui est le par défaut, j'utilise le inner dans certains rare cas ou le trou ne porte pas les propriété de l'ensemble. (Ensemble de lac portant un même nom avec une ile dans l'un d'eux) Bien que l'on puisse ergoter sur le fait que l'île porte ou nom le nom des lacs en plus de son propre nom d'île -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Extraire le cadastre non vectorisé en image
Bonjour, Lorsque j'avais cette méthode, l'option georeference an image n'existait pas. D'ou ce tutoriel. Comme à l'origine il s'agissait d'import sous QGis, la méthode est quasiment la même. tout du moins au début. Le 16 novembre 2009 23:56, hamster hams...@suna.fdn.fr a écrit : Fabien Marchewka a écrit : une version texte est ici : http://wiki.openstreetmap.org/wiki/User:Fabien_Marchewka/cadastre est au format flash ici : http://void.free.fr/osm/tuto_cadastre_raster.htm mais ??? je ne comprends pas bien pourquoi passer par du PDF qu'on raboute dans gimp puis qgis alors que le resultat est le meme avec la fonction georeference an image du plugin cadastre comme indique la : http://wiki.openstreetmap.org/wiki/FR:JOSM/Fr:Plugin/Cadastre-fr#Utilisation_des_plans_images_contenant_des_croisillons mais peut-etre est-ce qu'il y a une subtilite que je n'ai pas compris ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Fabien Marchewka ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Alerte (mail ?) sur modifications d'une commune
Je n'ai pas trouvé si cela existait ou pas. Je souhaite être averti lors d'une modification OSM sur ma commune (mail ou autre). Cela existe-t-il ? Bonne journée Patrice Vetsel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alerte (mail ?) sur modifications d'une commune
Je souhaite être averti lors d'une modification OSM sur ma commune (mail ou autre). Cela existe-t-il ? via http://www.itoworld.com/ tu peux être averti via un fil RSS des modifications sur une zone de ton choix il suffit de s'inscrire Bonne journée -- Stéphane Péchard ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alerte (mail ?) sur modifications d'une commune
On mardi 17 novembre 2009, Patrice Vetsel wrote: Je n'ai pas trouvé si cela existait ou pas. Je souhaite être averti lors d'une modification OSM sur ma commune (mail ou autre). Cela existe-t-il ? D'après mes recherches, il n'y a pas grand chose autour du monde osm concernant la surveillance. http://www.itoworld.com/ est ce qui s'en rapproche le plus, mais c'est pas encore la joie. Je rêverais également d'une fonctionnalité comme tu proposes (avec d'autres options encore) mais je pense que là, on en est au yaka, faucon. En rapport sur le wiki tu as : http://wiki.openstreetmap.org/wiki/Vandalism http://wiki.openstreetmap.org/wiki/Detect_Vandalism http://wiki.openstreetmap.org/wiki/Osmdiff Si tu trouves autre chose, je serais intéressé -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une association pour OSM
2009/11/16 Jean-Francois Nifenecker jean-francois.nifenec...@laposte.net Christian Rogel a écrit : Pour le lieu, préférez-vous Paris, Orléans ou Bourges? ;-) Bordeaux... pendant les RMLL :-) Avant ca serait mieux :) Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alerte (mail ?) sur modifications d'une commune
2009/11/17 sly (sylvain letuffe) sylv...@letuffe.org On mardi 17 novembre 2009, Patrice Vetsel wrote: Je n'ai pas trouvé si cela existait ou pas. Je souhaite être averti lors d'une modification OSM sur ma commune (mail ou autre). Cela existe-t-il ? D'après mes recherches, il n'y a pas grand chose autour du monde osm concernant la surveillance. http://www.itoworld.com/ est ce qui s'en rapproche le plus, mais c'est pas encore la joie. Je rêverais également d'une fonctionnalité comme tu proposes (avec d'autres options encore) mais je pense que là, on en est au yaka, faucon. En rapport sur le wiki tu as : http://wiki.openstreetmap.org/wiki/Vandalism http://wiki.openstreetmap.org/wiki/Detect_Vandalism http://wiki.openstreetmap.org/wiki/Osmdiff Si tu trouves autre chose, je serais intéressé Il y avait une discussion il y a quelques temps sur la liste de modération par Peter Miller président de ITO. La conclusion était que beaucoup de gens veulent un outil de détection de vandalisme mais il y a peu de gens prêts a écrire le code nécessaire. Peter est donc d'accord pour que ITO aide a condition que le coût ne soit pas supporté uniquement que par ITO (c'est a dire qu'il recherche des devs open source). Maintenant, je ne sais pas si le travail a commence pour ce genre de chose. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une association pour OSM
Emilie Laffray a écrit : Je suis convaincue de l'utilité d'une association; je ne suis pas convaincue de monter une usine a gaz. +1 A mon avis, il faut une association simple (une petite cellule d'administration) et des membres. Le travail de communication peut ensuite être fait par l'un ou l'autre des membres, selon disponibilités et opportunités. Le tout est de se coordonner, mais l'association ne va pas révolutionner OSM France, juste lui donner une existence légale. Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Alerte (mail ?) sur modifications d'une commune
On mardi 17 novembre 2009, Emilie Laffray wrote: Il y avait une discussion il y a quelques temps sur la liste de modération arch, je m'en suis dé-inscrit car ça fait vraiment trop de trafic d'être partout, zut, ça n'avait pas l'air mal. Intéressant thread qui montre un besoin émergeant, et le problème afférent : son développement et son mode de développement. Je n'a pas eu la sensation que osm mapper avait un code dispo. Mais je ne vais rien leur reprocher, c'est déjà un super travail. Peter est donc d'accord pour que ITO aide a condition que le coût ne soit pas supporté uniquement que par ITO (c'est a dire qu'il recherche des devs open source). J'ai vu et ça se comprend... yaka -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment contribuer et naviguer avec Android
Très très joli travail Denis ... Le mapfile est-il disponible quelque part ? Je suis sûr que certains ici seront intéressés. A+ F. PS: attention, le rendu style scan25 est-il copyrighté ? 2009/11/16 Denis dhel...@free.fr Dominique Rousseau a écrit : Il manque (oui, yaka fokon...), je pense, un service similaire à MapOSMatic, permettant d'éditer des cartes papier couvrant une surface plus importante (et donc, forcément, un zomm moins élevé). Des, qu'on puisse stabiloter, pour marquer l'itinéraire prévu, et avoir comme guide, sans de poser la question de l'état des batteries du GPS/laptop/PDA/... quelque chose dans le genre (c'est encore beta) : http://wiki.openstreetmap.org/wiki/Image:Strasbourg_OSM_20091115.jpg ? Pour info, il y a : - un dump (Geofabrik) Alsace des données OSM convertit en base PostGIS (merci osmosis) - quelques vues pour extraire les objets intéressants - un mapfile (avec des morceaux d'icônes de JOSM dedans ;-) - un OpenJUMP pour faire le rendu WMS. Qgis peut aussi bien faire Tout n'est pas encore rendu (les équipements sportifs, les zones industrielles, les labels), mais j'ai été surpris par le côté 75% (voire plus) par rapport au scan25 si j'ai bien compris le besoin initial. Il y a un vrai service à rendre, à certains utilisateurs. Par chance NOTRE base sait faire beaucoup de rendus Denis PS : ce n'est pas taggué pour le rendu ___ 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] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
Bonjour, A la conférence SAGEO 2009 [1] (SPATIAL ANALYSIS AND GEOMATICS, Paris, 25-27 novembre 2009), il y aura un poster sur le travail de Guillaume Touya et Jean-François Girres du laboratoire COGIT de l'IGN. Ils se sont intéressés à l'évaluation de la qualité des données libres d'OpenStreetMap en France. Je les ai contactés, et ils m'ont transmis un résumé PDF de leurs travaux, disponible en [2]. Un article est en cours de soumission à une revue à comité de lecture, et je n'ai donc pas pu accéder au détail de l'étude. Extraits : La comparaison des thèmes linéaires routiers montre des écarts maximaux moyens très supérieurs (Distance de Hausdorff moyenne de 13.57 mètres) à la précision de la base de données de référence (Erreur moyenne quadratique de 2 mètres) mais surtout une très forte hétérogénéité dans la distribution des valeurs, du fait du manque de spécifications de saisie précises. L’étude des carrefours des thèmes routiers a permis d’estimer une erreur de position moyenne trois fois supérieure (distance moyenne de 6.65 mètres) à celle garantie par la BD TOPO®. Pour une saisie manuelle sur fond de traces GPS, ces chiffres me semblent en bon accord avec la précision attendue. Ce qui me semble plus grave, c'est la précision sémantique pas terrible, notamment entre routes résidentielles et tertiaires. On attend la suite des travaux avec impatience ... Cordialement, F. [1] http://sageo09.univ-pau.fr/ [2] http://dl.free.fr/ohUh3LLVh ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la quali té des données libres d'OpenStreetMap en France
On mardi 17 novembre 2009, François Van Der Biest wrote: A la conférence SAGEO 2009 [1] (SPATIAL ANALYSIS AND GEOMATICS, Paris, 25-27 novembre 2009), il y aura un poster sur le travail de Guillaume Touya et Jean-François Girres du laboratoire COGIT de l'IGN. Ils se sont intéressés à l'évaluation de la qualité des données libres d'OpenStreetMap en France. Super intéressant, ça fait du bien un regard extérieur professionnel sur les données osm. Bon, le ton employé dans le document, bien que malgré tout assez objectif reste déviant vers un c'est mieux chez nous, mais ça me semble humain de réagir comme ça. First they ignore you, then they ridicule you, * then they fight you, then you win. * On en est là, ça veut dire que le projet avance sur la gandhi scale ;-) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
2009/11/17 François Van Der Biest francois.vanderbi...@camptocamp.com: La seule partie intéressante de cette étude concerne la précision des positionnements. Ces deux chercheurs travaillant pour l'IGN, leur étude ne peut être que partiale. Ca n'est qu'une charge de l'IGN contre OSM (en particulier, l'attaque facile sur les cours d'eaux (difficile sans orthophotos) et sur la faible cohérence attributaire par rapport à la BD-Topo, ce qui est un non-sens). Tout cela peut se comprendre puisque nombre de leurs clients portent chaque jour d'avantage d'intérêts à OSM et doivent faire pression sur eux pour qu'ils baissent leurs prix (un peu comme Linux qui empêche Microsoft de trop exagérer avec son monopole) alors que l'IGN doit pouvoir les justifier en regard du niveau de précision et de cohérence attributaire justement. On sait aussi que l'IGN tente de mettre en place son propre système collaboratif où les mises à jour et erreurs sont remontées par les clients et ce, à titre grâcieux. Ils pensent donc pouvoir récupérer l'avantage de la méthode (mises à jour à moindre coût) sans en avoir les inconvénients (le client continuant de payer au prix fort). D'où leur conclusion. D'un autre côté, c'est amusant de voir l'IGN s'intéresser à OSM alors qu'il y a deux ou trois ans à peine, ils n'auraient eu que dédain pour ce projet. Encore quelques années et l'IGN constatera que son modèle économique actuel n'est pas tenable. Mais c'est un autre sujet. Pieren Petite question: ces chercheurs considérant la BD-Topo comme le référentiel en matière d'attributs, est-ce qu'il est envisageable de considérer ces attributs comme libres de droits et réutilisable tel quel dans OSM ? Comme attributs, on pense en particulier à la classification highway des routes bien-sûr. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une association pour OSM
Hello, *Robin veut d'abord vérifier, s'il y a une volonté de s'associer, ce qui est un préalable à toute discussion sur la manière de s'associer.* Tout à fait, si la communauté est OK, le reste ne dépend que des volontaires :) * si l'association est considéré comme d'intérêt général (ce dont je en doute pas), Faut quand même faire les démarches, assez lourdes. Et donc, quelqu'un pour se colleter le suivi du machin.* GeoRezo est passé par là, on devrait pouvoir mâcher les démarches ou du moins expliquer la procédure, qui pourra venir dans un deuxième voire troisième temps si une assoc voit le jour. La question est : Comment on s'y prend ? Le minimum est : - des statuts ; - un conseil d'administration Je dirai qu'il faut des volontaires (au minimum) et des statuts bien discutés. Les statut vont fixer les objectifs de l'asso, c'est important de ne pas se louper, même si il est toujours possible d'en changer après, ça n'est pas forcément évident (- paperasse, AG exceptionnelle, publication au JO, etc). Si le projet est bien ficelé sur le wiki et qu'une grande partie des participants sont d'accord, ça sera déjà beaucoup, le suite c'est de l'administratif et des votes. Pour info, le conseil d'administration n'est pas indispensable, il faut à mon avis au moins un bureau (plus simple) pour se charger des trucs administratifs officiels. * Pour le lieu, préférez-vous Paris, Orléans ou Bourges? ;-)* Pour le souci de localisation, par exemple, Georezo est basé chez un des membres officiellement mais on vit partout en France et à l'étranger, donc ça reste un détail administratif. Les statuts seront à mon avis un des points les plus complexe ;) 0.02€ de plus, Robin. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une association pour OSM
Le Mon, 16 Nov 2009 23:11:37 +0100, Nicolas Pouillon n...@ssji.net a écrit : Ouais, enfin... J'ai testé pour vous, c'est très dur de faire entendre aux services préfectoraux qu'une asso n'a pas de bureau renouvelable et pas de roles déterminés. Pour Toulibre [1], les status ne prévoient qu'un «représentant légal». Pas de président ni de trésorier d'après les statuts. Validé par la préfecture de Haute-Garonne. [1] http://www.toulibre.org -- Thomas Petazzoni http://thomas.enix.org Promouvoir et défendre le Logiciel Libre http://www.april.org Logiciels Libres à Toulouse http://www.toulibre.org signature.asc Description: PGP signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la quali té des données libres d'OpenStreetMap en France
Extraits : La comparaison des thèmes linéaires routiers montre des écarts maximaux moyens très supérieurs (Distance de Hausdorff moyenne de 13.57 mètres) En la matière, j'espère qu'à terme, pour les grands axes, il existera des outils pour faire des moyennes automatiques des nombreuses traces GPS que nous saisissons et corriger ainsi les routes existantes. Sans compter le cadastre pour la ville qui doit permettre de descendre vers le mètre. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
2009/11/17 Eric Sibert courr...@eric.sibert.fr Extraits : La comparaison des thèmes linéaires routiers montre des écarts maximaux moyens très supérieurs (Distance de Hausdorff moyenne de 13.57 mètres) En la matière, j'espère qu'à terme, pour les grands axes, il existera des outils pour faire des moyennes automatiques des nombreuses traces GPS que nous saisissons et corriger ainsi les routes existantes. Sans compter le cadastre pour la ville qui doit permettre de descendre vers le mètre. Oui, je suis d'accord sur le fait qu'il y ait besoin d'avoir un outil automatique pour les traces. Je pense que c'est justement ce genre de chose qui nous permettra d'assurer la qualité de OSM a long terme. Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une association pour OSM
Ah oui, exact. Ca marche avec un conseil d'administration un représentant légal...mais au final ca revient un peu au même, il n'y a juste pas de tête de file unique (ce qui pourrait peut être pas mal convenir pour OSM justement, qui se veut populaire comme disent les statuts de toulibrehttp://www.toulibre.org/pub/association/statuts/statuts.pdf 13 personnes élues au CA + 5 personnes avec des mandats spéciaux (comptabilité et trésorerie de l'association, gestion des adhésions, organisation des rencontres, organisation des Qjelt(?), représentation légale) Bien vu :) Robin. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qual ité des données libres d'OpenStreetMap en France
Bonjour, Merci François pour cette information. L'étude semble intéressante. Le résumé est prometteur en tout cas. Je pense qu'il faut dépasser l'idée que l'approche de l'IGN est partiale. Elle l'est, nécessairement. And so what? Tout d'abord, le COGIT a assez d'autonomie pour ne pas avoir autant la tête dans le guidon que la direction commerciale de l'IGN. Les remarques qui sont faites sont des constatations. Même si la méthode était discutable (ce qui reste à démontrer), les ordres de grandeur sont éloquents. Et la raison principale évoquée, à savoir le manque de cadrage à la saisie est absolument vrai. Actuellement, on peut faire à peu près ce que l'on souhaite lorsqu'on fait une contribution, notamment en terme de modèle de données et de topologie. Les pistes de réflexion proposées par le COGIT semblent pertinentes et les actions évoquées, à savoir Le COGIT étudie des méthodes permettant de définir des spécifications au sein de systèmes de saisie collaborative, ne sont pas à prendre à la légère et sont à encourager, au contraire. Ce laboratoire regroupe de vrais experts sur la qualité des données géographiques, et, au lieu de nuire au projet OSM, leur approche pourrait être au contraire bénéfique. Prêtons nous à rêver, et envisageons la complémentarité, à terme, entre une communauté libre et un institut national, qui aurait retrouvé ses missions de service public. Vu comme ça, où est la concurrence? Par contre, il faudrait que cette utopie devienne un peu plus concrète un jour ou l'autre. Or, le terme même de service public passe de moins en moins... Pour en revenir aux problèmes de qualité liés spécifiquement aux libertés trop importantes de saisie, d'une part, et à la relative faiblesse des métadonnées d'autre part, je livre en prime time des extraits d'un document sur lequel GAIAGO travaille depuis quelques mois, en interaction avec le CERTU (autre expert de la qualité des données s'il en est). Ce document est intitulé: LA PROBLEMATIQUE DE LA QUALITE DES DONNEES GEOGRAPHIQUES COLLABORATIVES, Cas d'OpenStreetMap, pistes de solutions. Cas de l'utilisateur Néophyte (chapitre La déprofessionnalisation des producteurs) Situation : Ce contributeur, par définition, n’y connaît à priori rien en géomatique, en production de données et en cartographie, même s’il peut par ailleurs connaître parfaitement bien la zone qu’il cartographie. Problème potentiel : La probabilité est forte que ce néophyte produise des données fausses et non conformes aux spécifications en terme de structuration. Les données sont alors inexploitables en l’état et peuvent conduire à l’avenir l’utilisateur à de mauvais résultats. Il est de plus incapable de documenter sa production au travers de métadonnées. Pistes de solution: (...) 3) Ergonomie encadrée : l’utilisateur ne doit pas avoir la possibilité de produire les données n’importe comment : - Contrôle à la volée de la topologie, - Modèle de données simple et figé pour les néophytes (seuls les experts peuvent ajouter de nouveaux champs aux objets, par exemple) Cas d’OSM : - Actuellement, la topologie peut être contrôlée par certains outils (...). Ce contrôle n’est pas réalisé à la volée, mais par une action volontaire du contributeur. - La création d’un nouvel attribut (tag) est réalisée en concertation avec les autres contributeurs actifs de la communauté (actif étant un statut empirique, non défini). Un contributeur peut néanmoins inventer de nouvelles valeurs possibles de ces attributs sans consulter personne, s’il le souhaite. S’il ne justifie pas sa démarche en associant un commentaire à l’objet comportant une nouvelle valeur pour un attribut donné, il prend le risque de voir cette valeur supprimée un peu plus tard par un autre membre, plus « avancé » de la communauté (ou remplacé par la valeur qui existe déjà et que le contributeur n’a pas pris la peine de chercher). Exemple : un contributeur renseigne un tronçon de voie avec l’attribut highway ayant la valeur « voie piétonne », alors que cette distinction existe déjà, sous la forme « footway » (highway=footway). Un autre contributeur, plus au fait, peut remplacer sans prévenir « voie piétonne » par « footway ». Le risque est encore plus grand que la donnée reste telle quelle, non normalisée donc inexploitable. 4) Métadonnées obligatoires (en règle générale, on ne devrait pas pouvoir valider et enregistrer une quelconque saisie sans avoir rempli une série de métadonnées incontournables). Cette pratique marche aussi pour tous les types de producteurs qu’ils soient ou non néophytes. Cas d’OSM : Actuellement ,lorsqu’on crée un objet, renseigner la source n’est pas obligatoire. Il faudrait non seulement la rendre obligatoire, mais imposer les éléments suivants : ·Estimation de la précision géométrique de la source, ·Date de la source, ·Estimation de l’échelle de la source (dans le cas d’une numérisation à partir d’une photographie aérienne ou d’une source
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
Bonjour Serge, 2009/11/17 Serge Mang GAIAGO s.m...@gaiago.fr Je pense qu'il faut dépasser l'idée que l'approche de l'IGN est partiale. Elle l'est, nécessairement. And so what? Tout d'abord, le COGIT a assez d'autonomie pour ne pas avoir autant la tête dans le guidon que la direction commerciale de l'IGN. Les remarques qui sont faites sont des constatations. Je suis complètement d'accord avec toi ! Même si la méthode était discutable (ce qui reste à démontrer), les ordres de grandeur sont éloquents. Et la raison principale évoquée, à savoir le manque de cadrage à la saisie est absolument vrai. Actuellement, on peut faire à peu près ce que l'on souhaite lorsqu'on fait une contribution, notamment en terme de modèle de données et de topologie. Les pistes de réflexion proposées par le COGIT semblent pertinentes et les actions évoquées, à savoir Le COGIT étudie des méthodes permettant de définir des spécifications au sein de systèmes de saisie collaborative, ne sont pas à prendre à la légère et sont à encourager, Tout à fait ! au contraire. Ce laboratoire regroupe de vrais experts sur la qualité des données géographiques, et, au lieu de nuire au projet OSM, leur approche pourrait être au contraire bénéfique. Prêtons nous à rêver, et envisageons la complémentarité, à terme, entre une communauté libre et un institut national, qui aurait retrouvé ses missions de service public. Vu comme ça, où est la concurrence? Par contre, il faudrait que cette utopie devienne un peu plus concrète un jour ou l'autre. Or, le terme même de service public passe de moins en moins... La encore, +1. Pour en revenir aux problèmes de qualité liés spécifiquement aux libertés trop importantes de saisie, d'une part, et à la relative faiblesse des métadonnées d'autre part, je livre en prime time des extraits d'un document sur lequel GAIAGO travaille depuis quelques mois, en interaction avec le CERTU (autre expert de la qualité des données s'il en est). Ce document est intitulé: LA PROBLEMATIQUE DE LA QUALITE DES DONNEES GEOGRAPHIQUES COLLABORATIVES, Cas d'OpenStreetMap, pistes de solutions. Merci Serge. Nous attendons ce document avec impatience également ;-) A+ F. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
Pour apporter mes 2 centimes, ils comparent OSM à une base ortho. Que donnerait la comparaison de la base Navteq ou Teleatlas avec la même base ortho ? Je pense que OSM risque plutot de faire concurrence à ces deux bases commerciales plutot qu'à une base ortho. 2009/11/17 Pieren pier...@gmail.com: 2009/11/17 François Van Der Biest francois.vanderbi...@camptocamp.com: La seule partie intéressante de cette étude concerne la précision des positionnements. Ces deux chercheurs travaillant pour l'IGN, leur étude ne peut être que partiale. Ca n'est qu'une charge de l'IGN contre OSM (en particulier, l'attaque facile sur les cours d'eaux (difficile sans orthophotos) et sur la faible cohérence attributaire par rapport à la BD-Topo, ce qui est un non-sens). Tout cela peut se comprendre puisque nombre de leurs clients portent chaque jour d'avantage d'intérêts à OSM et doivent faire pression sur eux pour qu'ils baissent leurs prix (un peu comme Linux qui empêche Microsoft de trop exagérer avec son monopole) alors que l'IGN doit pouvoir les justifier en regard du niveau de précision et de cohérence attributaire justement. On sait aussi que l'IGN tente de mettre en place son propre système collaboratif où les mises à jour et erreurs sont remontées par les clients et ce, à titre grâcieux. Ils pensent donc pouvoir récupérer l'avantage de la méthode (mises à jour à moindre coût) sans en avoir les inconvénients (le client continuant de payer au prix fort). D'où leur conclusion. D'un autre côté, c'est amusant de voir l'IGN s'intéresser à OSM alors qu'il y a deux ou trois ans à peine, ils n'auraient eu que dédain pour ce projet. Encore quelques années et l'IGN constatera que son modèle économique actuel n'est pas tenable. Mais c'est un autre sujet. Pieren Petite question: ces chercheurs considérant la BD-Topo comme le référentiel en matière d'attributs, est-ce qu'il est envisageable de considérer ces attributs comme libres de droits et réutilisable tel quel dans OSM ? Comme attributs, on pense en particulier à la classification highway des routes bien-sûr. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
2009/11/17 Serge Mang GAIAGO s.m...@gaiago.fr 4) Métadonnées obligatoires (en règle générale, on ne devrait pas pouvoir valider et enregistrer une quelconque saisie sans avoir rempli une série de métadonnées incontournables). Cette pratique marche aussi pour tous les types de producteurs qu’ils soient ou non néophytes. Cas d’OSM : Actuellement ,lorsqu’on crée un objet, renseigner la source n’est pas obligatoire. Il faudrait non seulement la rendre obligatoire, mais imposer les éléments suivants : ·Estimation de la précision géométrique de la source, ·Date de la source, ·Estimation de l’échelle de la source (dans le cas d’une numérisation à partir d’une photographie aérienne ou d’une source vectorielle existante), ·Estimation de la précision sémantique de la source (pour les valeurs des attributs), ·Droits d’utilisation de la source (type de licence). Je suis globalement d'accord avec ce qui est écrit précédemment mais j'avoue que la j'ai eus du mal de ne pas rire. Ça me rappelle le débat sur le paramètre narrow. Ces considérations sont intéressantes mais complètement infaisables. Je ne vois comment un contributeur peut fournir la plupart des informations qui sont proposées la. Parlons un peu de l'estimation de la précision géométrique de la source dans le cadre d'un GPX par exemple. Cela veut il dire que l'on doit obtenir du constructeur GPS tous les informations sur le chipset GPS, ainsi que la version du firmware, ainsi que l'antenne, etc? On peut mettre peut être Sirf III mais la majorité des gens ne savent pas quelle puce GPS il y a dans leur matériel et encore moins les données théoriques qui varient de toute façon selon le bruit de l'appareil, de la position de l'antenne, etc. Doit on aussi calculer la visibilité des satellites au moment de la trace GPX et de tenir compte des obstacles physiques pour déterminer la précision? Après tout, c'est important de savoir s'il y a du multipath ou peu de satellites visibles! Doit on fournir les informations supplémentaires avec les DOPs? Et rendre tout cela obligatoire? Je ne crois pas. Je pourrais continuer sur chacun des points ad nauseam. Je ne suis pas contre ces suggestions c'est juste que c'est irréalisable dans le cadre de OSM. Qu'on le veuille ou non, le crowd sourcing ne remplacera jamais une prise d'information détaillée et faite par des professionnels. Beaucoup de gens le font parce que c'est amusant. Si on ajoute des contraintes irréalistes, le projet mourra de sa belle mort. On contribue parce que l'on peut. C'est pour ça que je suis d'accord avec une ergonomie renforcée pour réduire la barrière d'entrée a OpenStreetMap, mais on oublie trop souvent que la barrière est déjà plus élevée qu'on le croit. Ce n'est pas la première fois que je le dis. Si on rajoute des contraintes que la majorité des utilisateurs ne pourront pas renseigner, on arrivera a un beau projet théoriquement mais vide. Qu'on le veuille ou non, ce sont même les entrées pas très précises qui fait que la carte progresse et s'améliore. Sur Orleans, j'ai passe un temps fou dans certains endroits a corriger la tangentielle rentrer par quelqu'un d'autre précédemment. Aurais je rentre toutes les données par moi même si quelqu'un n'avait pas utilise des traces GPS initialement? Probablement pas, car c'est le genre de chose qui n'est pas forcement facile a rentrer en utilisant le cadastre. Pour une ville, le cadastre est un outil formidable, on peut facilement étendre la carte et ajouter des rues. Pour les grands axes, généralement, le cadastre devient plus dur a utiliser a moins d'avoir une trace GPS préliminaire. Bref, en gros, c'est un travail progressif. Muki Haklay a montre dans un de ses papiers que pour l'Angleterre la qualité augmentait a mesure qu'il y avait un grand nombre de participants actifs sur une zone. Autrement dit, ce sont les retouches et les corrections progressives qui font que les données sont bonnes au final. Que gagne t'on a garder des méta données qui seront de toute façon obsolète a mesure que c'est corrige? (cf la meme logique avec Corine). Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qual ité des données libres d'OpenStreetMap en France
+1 pour Emilie Emilie Laffray a écrit : 2009/11/17 Serge Mang GAIAGO s.m...@gaiago.fr mailto:s.m...@gaiago.fr 4) Métadonnées obligatoires (en règle générale, on ne devrait pas pouvoir valider et enregistrer une quelconque saisie sans avoir rempli une série de métadonnées incontournables). Cette pratique marche aussi pour tous les types de producteurs qu’ils soient ou non néophytes. Cas d’OSM : Actuellement ,lorsqu’on crée un objet, renseigner la source n’est pas obligatoire. Il faudrait non seulement la rendre obligatoire, mais imposer les éléments suivants : ·Estimation de la précision géométrique de la source, ·Date de la source, ·Estimation de l’échelle de la source (dans le cas d’une numérisation à partir d’une photographie aérienne ou d’une source vectorielle existante), ·Estimation de la précision sémantique de la source (pour les valeurs des attributs), ·Droits d’utilisation de la source (type de licence). Je suis globalement d'accord avec ce qui est écrit précédemment mais j'avoue que la j'ai eus du mal de ne pas rire. Ça me rappelle le débat sur le paramètre narrow. Ces considérations sont intéressantes mais complètement infaisables. Je ne vois comment un contributeur peut fournir la plupart des informations qui sont proposées la. Parlons un peu de l'estimation de la précision géométrique de la source dans le cadre d'un GPX par exemple. Cela veut il dire que l'on doit obtenir du constructeur GPS tous les informations sur le chipset GPS, ainsi que la version du firmware, ainsi que l'antenne, etc? On peut mettre peut être Sirf III mais la majorité des gens ne savent pas quelle puce GPS il y a dans leur matériel et encore moins les données théoriques qui varient de toute façon selon le bruit de l'appareil, de la position de l'antenne, etc. Doit on aussi calculer la visibilité des satellites au moment de la trace GPX et de tenir compte des obstacles physiques pour déterminer la précision? Après tout, c'est important de savoir s'il y a du multipath ou peu de satellites visibles! Doit on fournir les informations supplémentaires avec les DOPs? Et rendre tout cela obligatoire? Je ne crois pas. Je pourrais continuer sur chacun des points ad nauseam. Je ne suis pas contre ces suggestions c'est juste que c'est irréalisable dans le cadre de OSM. Qu'on le veuille ou non, le crowd sourcing ne remplacera jamais une prise d'information détaillée et faite par des professionnels. Beaucoup de gens le font parce que c'est amusant. Si on ajoute des contraintes irréalistes, le projet mourra de sa belle mort. On contribue parce que l'on peut. C'est pour ça que je suis d'accord avec une ergonomie renforcée pour réduire la barrière d'entrée a OpenStreetMap, mais on oublie trop souvent que la barrière est déjà plus élevée qu'on le croit. Ce n'est pas la première fois que je le dis. Si on rajoute des contraintes que la majorité des utilisateurs ne pourront pas renseigner, on arrivera a un beau projet théoriquement mais vide. Qu'on le veuille ou non, ce sont même les entrées pas très précises qui fait que la carte progresse et s'améliore. Sur Orleans, j'ai passe un temps fou dans certains endroits a corriger la tangentielle rentrer par quelqu'un d'autre précédemment. Aurais je rentre toutes les données par moi même si quelqu'un n'avait pas utilise des traces GPS initialement? Probablement pas, car c'est le genre de chose qui n'est pas forcement facile a rentrer en utilisant le cadastre. Pour une ville, le cadastre est un outil formidable, on peut facilement étendre la carte et ajouter des rues. Pour les grands axes, généralement, le cadastre devient plus dur a utiliser a moins d'avoir une trace GPS préliminaire. Bref, en gros, c'est un travail progressif. Muki Haklay a montre dans un de ses papiers que pour l'Angleterre la qualité augmentait a mesure qu'il y avait un grand nombre de participants actifs sur une zone. Autrement dit, ce sont les retouches et les corrections progressives qui font que les données sont bonnes au final. Que gagne t'on a garder des méta données qui seront de toute façon obsolète a mesure que c'est corrige? (cf la meme logique avec Corine). Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la quali té des données libres d'OpenStreetMap en France
On mardi 17 novembre 2009, Emilie Laffray wrote: Je suis globalement d'accord avec ce qui est écrit précédemment mais j'avoue que la j'ai eus du mal de ne pas rire. Quelle belle diplomatie ;-) N'ayant pas de bonnes manières, je dirais que je ne suis pas d'accord que le projet prenne cette direction, pour toutes les bonnes raisons évoquées par Émilie (que je résume) : (...) complètement infaisables. (...) (...) mais la majorité des gens ne savent pas (quoi mettre) (...) Si on ajoute des contraintes irréalistes, le projet mourra de sa belle mort. On contribue parce que l'on peut. Elle est tellement juste cette dernière phrase mais on oublie trop souvent que la barrière est déjà plus élevée qu'on le croit. ... Que gagne t'on a garder des méta données qui seront de toute façon obsolète a mesure que c'est corrige? ça, par contre, soit je n'ai pas compris, soit je ne suis pas d'accord. Qu'il soit logique de ne pas imposer à un contributeur de mettre des méta-informations de qualité, ça okay, mais par contre rien n'empêche de lui permettre de le faire dans un cadre proprement bien défini (tags+wiki), et d'insister régulièrement et lourdement (pieren+source=cadastre ? non je blague) pour que le maximum de contributeur les ajoutent. Mais avec une méthode de formation plutôt que de répression. Je suis très content d'ajouter des source=précision ~5m, puce gps positronique d'interférence de phase SRTK à connecteurs en poils de chameau + note=sisi c'est vrai + fixme=la fin pourrait être mieux + noname=yes ... -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
2009/11/17 sly (sylvain letuffe) sylv...@letuffe.org Que gagne t'on a garder des méta données qui seront de toute façon obsolète a mesure que c'est corrige? ça, par contre, soit je n'ai pas compris, soit je ne suis pas d'accord. Qu'il soit logique de ne pas imposer à un contributeur de mettre des méta-informations de qualité, ça okay, mais par contre rien n'empêche de lui permettre de le faire dans un cadre proprement bien défini (tags+wiki), et d'insister régulièrement et lourdement (pieren+source=cadastre ? non je blague) pour que le maximum de contributeur les ajoutent. Mais avec une méthode de formation plutôt que de répression. Je voulais dire que dans le cas que je donnais les méta données ne voudraient plus rien dire. Quelle source mettre pour ce mélange de cadastre, de traces GPS et de connaissances personnelles du terrain? C'est la même question que pour Corine. Doit on conserver la source alors que l'on a modifie de manière extensive les polygones pour refléter la réalité? J'ai récemment refait en partie le landuse residential de la ville de Sandillon a partir du cadastre et de Corine. Que dois je mettre? Cadastre, Corine, Ou Emilie's touch? Un peu de tout ça? Emilie Laffray ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qual ité des données libres d'OpenStreetMap en France
Emilie Laffray a écrit : Qu'on le veuille ou non, le crowd sourcing ne remplacera jamais une prise d'information détaillée et faite par des professionnels. Beaucoup de gens le font parce que c'est amusant. Si on ajoute des contraintes irréalistes, le projet mourra de sa belle mort. On contribue parce que l'on peut. C'est pour ça que je suis d'accord avec une ergonomie renforcée pour réduire la barrière d'entrée a OpenStreetMap, mais on oublie trop souvent que la barrière est déjà plus élevée qu'on le croit. Ce n'est pas la première fois que je le dis. Si on rajoute des contraintes que la majorité des utilisateurs ne pourront pas renseigner, on arrivera a un beau projet théoriquement mais vide. +1 Qu'on le veuille ou non, ce sont même les entrées pas très précises qui fait que la carte progresse et s'améliore. Sur Orleans, j'ai passe un temps fou dans certains endroits a corriger la tangentielle rentrer par quelqu'un d'autre précédemment. Aurais je rentre toutes les données par moi même si quelqu'un n'avait pas utilise des traces GPS initialement? Probablement pas, car c'est le genre de chose qui n'est pas forcement facile a rentrer en utilisant le cadastre. Pour une ville, le cadastre est un outil formidable, on peut facilement étendre la carte et ajouter des rues. Pour les grands axes, généralement, le cadastre devient plus dur a utiliser a moins d'avoir une trace GPS préliminaire. Bref, en gros, c'est un travail progressif. Fourmis, disait quelqu'un. Une fourmis ne sait pas grand chose, sait-elle elle même ce qu'elle fait. Mais la production de la fourmilière est extraordinaire d'équilibre, de complexité... Muki Haklay a montre dans un de ses papiers que pour l'Angleterre la qualité augmentait a mesure qu'il y avait un grand nombre de participants actifs sur une zone. Autrement dit, ce sont les retouches et les corrections progressives qui font que les données sont bonnes au final. Que gagne t'on a garder des méta données qui seront de tout J'ajouterai une remarque. Bien-sûr, il faut viser l'exhaustivité et la qualité répartie. Mais comme on le faisait remarquer pour Wikipédia. Les erreurs sont corrigées rapidement et la qualité vient vite dans les zones très regardées, très lentement dans les zones peu regardées, mais ça n'est pas très grave puiseque ce sont des zones peu regardées. -- Vincent alias FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la quali té des données libres d'OpenStreetMap en France
On mardi 17 novembre 2009, Emilie Laffray wrote: Que dois je mettre? Cadastre, Corine, Ou Emilie's touch? Un peu de tout ça? Je ne dis pas que ce que je fais est bien, mais soit : - je mets source=gps+image yahoo+corine import+feeling (mode feignant) - soit je place un source différent sur toutes les portions que j'ai changée (oui, cela implique un re-coupage en relation avec plusieurs outer way dont chacun garde sa source de provenance) -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qual ité des données libres d'OpenStreetMap en F rance
-Message d'origine- De : talk-fr-boun...@openstreetmap.org [mailto:talk-fr-boun...@openstreetmap.org]de la part de Serge Mang GAIAGO Envoyé : mardi 17 novembre 2009 15:06 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Première évaluation de la qualité des données libres d'OpenStreetMap en France Bonjour, Merci François pour cette information. L'étude semble intéressante. Le résumé est prometteur en tout cas. ... Tout à fait et le COGIT peut sûrement apporter quelques éléments de réflexion utiles. Juste une remarque : OSM-France a, grosso modo, 2 ans d'âge, peut utiliser le cadastre ou d'autres données libérées depuis moins d'un an. Comparer cette base de données en plein essor avec un produit qui a plus de 5 ans, n'est pas tout à fait honnête. Et je ne parle pas des moyens qui sont consacrés de part et d'autres tant pour la constitution que pour l'entretien des bases respectives. ... Ce document est intitulé: LA PROBLEMATIQUE DE LA QUALITE DES DONNEES GEOGRAPHIQUES COLLABORATIVES, Cas d'OpenStreetMap, pistes de solutions. Encore de la lecture qui s'annonce très instructive... Cas de l'utilisateur Néophyte (chapitre La déprofessionnalisation des producteurs) ... Pistes de solution: (...) 3) Ergonomie encadrée : l’utilisateur ne doit pas avoir la possibilité de produire les données n’importe comment : Je verrais bien des applications en ligne (à base d'Openlayers ?) spécialisées : limites communales, occupation du sol, POI, etc. Les controles de tag et la topologie pourraient être plus simple à mettre en oeuvre. C'est vrai qu'aujourdhui le controle qualité de la base se fait en aval de la production et non pas en amont. ... 4) Métadonnées obligatoires (en règle générale, on ne devrait pas pouvoir valider et enregistrer une quelconque saisie sans avoir rempli une série de métadonnées incontournables). Cette pratique marche aussi pour tous les types de producteurs qu’ils soient ou non néophytes. Je crois que les métadonnées sont nécessaires et hélas trop souvent absentes. Avoir des métadonnées complètes au niveau de l'objet est utopique ; c'est un problème de granularité : on passerait autant de temps à créer des objets qu'à décrire comment ils ont été faits. D'ailleurs, la BD TOPO se contente d'un attribut source. En revanche, des produits dérivés de la base OSM (une base routière ou des limites administratives, par exemple) devrait impérativement avoir des métadonnées. Là on pourrait parler de qualité géométrique, d'exhaustivité, de précision sémantique. Après avoir mené, bien sûr, une analyse en fonction d'un cahier des charges. Comme l'a dit Emilie, si nous placons la barre trop haut, les contributeurs vont déserter. Il faut garder le côté fun et laisser la porte d'entrée grande ouverte même s'il y a des courants d'air (c'est peut-être cela aussi le Web 2.0). Cela n'empêche pas d'avoir des pièces un peu plus isolées et autres sas de décompression. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment contribuer et naviguer avec Android
-Message d'origine- De : talk-fr-boun...@openstreetmap.org [mailto:talk-fr-boun...@openstreetmap.org]de la part de François Van Der Biest Envoyé : mardi 17 novembre 2009 13:06 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Comment contribuer et naviguer avec Android Très très joli travail Denis ... merci Le mapfile est-il disponible quelque part ? Je suis sûr que certains ici seront intéressés. Pas encore mais ça viendra ; je voudrais mettre quelques libellés et quelques autres couches, mais je ne suis pas un pro de Mapserver. Je mettrais aussi les vues utilisées par le mapfile. PS: attention, le rendu style scan25 est-il copyrighté ? Rh, c'est si ressemblant que cela ? Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
2009/11/17 François Van Der Biest francois.vanderbi...@camptocamp.com: Bonjour Serge, 2009/11/17 Serge Mang GAIAGO s.m...@gaiago.fr Je pense qu'il faut dépasser l'idée que l'approche de l'IGN est partiale. Elle l'est, nécessairement. And so what? Tout d'abord, le COGIT a assez d'autonomie pour ne pas avoir autant la tête dans le guidon que la direction commerciale de l'IGN. Les remarques qui sont faites sont des constatations. Je suis complètement d'accord avec toi ! Pas moi. Toute l'étude se fait sur une comparaison avec leur BD en référentiel, donc toute différence est jugée comme une erreur en défaveur d'OSM sans jamais se poser la question de savoir qui a raison ou même si quelqu'un a raison. C'est la crédibilité même de l'étude qui est en jeu par cette méthode. Dire par exemple 40% d'erreur sur la nature des routes est un non-sens parce qu'OSM ne veut justement pas recopier la même classification des routes que la BD-Topo. Il ne faut pas dire 40% d'erreur mais 40% de différence. Je pourrais tout aussi bien dire que c'est l'IGN qui a 40% d'erreur avec OSM. Certaines routes primaires (nationales) de l'IGN sont moins fréquentées que certaines départementales et OSM tient compte dans cette réalité alors que l'IGN est tenu par les classifcations administratives. Alors qui a raison ? et sur quelle base ? Rejeter l'attribut tertiary parce qu'il n'entre pas dans les cases existantes (donc forcément mal définie) est assez exemplaire de l'impossibilité de comparer des choses incomparables mais qui amènent des conclusions tendencieuses. Même si la méthode était discutable (ce qui reste à démontrer), les ordres de grandeur sont éloquents. Et la raison principale évoquée, à savoir le manque de cadrage à la saisie est absolument vrai. Actuellement, on peut faire à peu près ce que l'on souhaite lorsqu'on fait une contribution, notamment en terme de modèle de données et de topologie. Les pistes de réflexion proposées par le COGIT semblent pertinentes et les actions évoquées, à savoir Le COGIT étudie des méthodes permettant de définir des spécifications au sein de systèmes de saisie collaborative, ne sont pas à prendre à la légère et sont à encourager, Tout à fait ! Discussion toute théorique qui, si elle sort un jour des laboratoires, ne serait mise en application que par l'IGN. Prêtons nous à rêver, et envisageons la complémentarité, à terme, entre une communauté libre et un institut national, qui aurait retrouvé ses missions de service public. La encore, +1. C'est aussi ama la seule issue possible. Pour en revenir aux problèmes de qualité liés spécifiquement aux libertés trop importantes de saisie, d'une part, et à la relative faiblesse des métadonnées d'autre part, je livre en prime time des extraits d'un document sur lequel GAIAGO travaille depuis quelques mois, en interaction avec le CERTU (autre expert de la qualité des données s'il en est). Ce document est intitulé: LA PROBLEMATIQUE DE LA QUALITE DES DONNEES GEOGRAPHIQUES COLLABORATIVES, Cas d'OpenStreetMap, pistes de solutions. J'ai fait une recherche sans succès pour retrouver dans les archives les premiers messages venant du monde des SIG (les pros) au tout début d'OSM et proposant déjà ce modèle figé des attributs (il y a en a aussi dans le wiki) normés et même standardisés au niveau international. C'est le concept du limited crowdsourcing ou encore les contributions sont libres mais la manière est figée. Ce modèle a été rejeté dès le départ par les fondateurs du projet qui parient sur l'imagination et la créativité des utilisateurs. Mais libre à certains de proposer des solutions alternatives et mieux encadrées mais elles ne seront pas adoptées par OSM. Peut-être devraient-ils s'adresser à UPTC. Pour le reste, essayer de rendre un tag source obligatoire et imposer cinq champs d'informations pour chaque objet créé prête effectivement à sourir tant on se retrouve éloigné des pratiques actuelles de contributeurs amateurs et bénévoles que nous sommes dans l'immense majorité. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qual ité des données libres d'OpenStreetMap en France
Serge Mang GAIAGO a écrit : 3) Ergonomie encadrée : l’utilisateur ne doit pas avoir la possibilité de produire les données n’importe comment : - Contrôle à la volée de la topologie, - Modèle de données simple et figé pour les néophytes (seuls les experts peuvent ajouter de nouveaux champs aux objets, par exemple) Cas d’OSM : - Actuellement, la topologie peut être contrôlée par certains outils (...). Ce contrôle n’est pas réalisé à la volée, mais par une action volontaire du contributeur. je pense que ca serait une erreur psychologique grossiere : il faut savoir eviter de prendre les gens pour des cons ou des imbeciles il y a dans OSM comme dans wikipedia la possibilite pour chacun de tout faire, c'est a dire que le debutant qui decouvre que oui, il peut vraiment modifier comme il veut sent assez vite qu'il doit faire attention il y a un effet responsabilisant au contraire si on considerait le francais moyen comme un gamin incapable de bien faire si on l'encadre pas et on lui mets pas des gardes fou ca serait deresponsabilisant et ca donnerait l'impression d'etre un pauvre pekin qui vient jouer un peu sur le grand OSM (merci a lui de nous accepter) et non pas d'etre un auteur/contributeur a part entiere ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
2009/11/17 Pieren pier...@gmail.com 2009/11/17 François Van Der Biest francois.vanderbi...@camptocamp.com: Bonjour Serge, 2009/11/17 Serge Mang GAIAGO s.m...@gaiago.fr Je pense qu'il faut dépasser l'idée que l'approche de l'IGN est partiale. Elle l'est, nécessairement. And so what? Tout d'abord, le COGIT a assez d'autonomie pour ne pas avoir autant la tête dans le guidon que la direction commerciale de l'IGN. Les remarques qui sont faites sont des constatations. Je suis complètement d'accord avec toi ! Pas moi. Toute l'étude se fait sur une comparaison avec leur BD en référentiel, donc toute différence est jugée comme une erreur en défaveur d'OSM sans jamais se poser la question de savoir qui a raison ou même si quelqu'un a raison. Je rappelle que nous n'avons pas l'étude complète entre nos mains, mais un résumé rapide. Ce genre de réflexion y est peut-être présent. Et s'il n'y est pas encore, ne fermons pas le dialogue avec ces chercheurs ! C'est la crédibilité même de l'étude qui est en jeu par cette méthode. Dire par exemple 40% d'erreur sur la nature des routes est un non-sens parce qu'OSM ne veut justement pas recopier la même classification des routes que la BD-Topo. Il ne faut pas dire 40% d'erreur mais 40% de différence. Je pourrais tout aussi bien dire que c'est l'IGN qui a 40% d'erreur avec OSM. Certaines routes primaires (nationales) de l'IGN sont moins fréquentées que certaines départementales et OSM tient compte dans cette réalité alors que l'IGN est tenu par les classifcations administratives. Alors qui a raison ? et sur quelle base ? Rejeter l'attribut tertiary parce qu'il n'entre pas dans les cases existantes (donc forcément mal définie) est assez exemplaire de l'impossibilité de comparer des choses incomparables mais qui amènent des conclusions tendencieuses. Je ne pense pas qu'il faille y voir une volonté à enfoncer à OSM, mais plutot une méconnaissance des réalités fines de notre projet communautaire. Là encore, nous avons tout intérêt à entretenir le dialogue. Même si la méthode était discutable (ce qui reste à démontrer), les ordres de grandeur sont éloquents. Et la raison principale évoquée, à savoir le manque de cadrage à la saisie est absolument vrai. Actuellement, on peut faire à peu près ce que l'on souhaite lorsqu'on fait une contribution, notamment en terme de modèle de données et de topologie. Les pistes de réflexion proposées par le COGIT semblent pertinentes et les actions évoquées, à savoir Le COGIT étudie des méthodes permettant de définir des spécifications au sein de systèmes de saisie collaborative, ne sont pas à prendre à la légère et sont à encourager, Tout à fait ! Discussion toute théorique qui, si elle sort un jour des laboratoires, ne serait mise en application que par l'IGN. Et pourquoi donc ? Comment ce genre de réflexion ne pourrait-il pas nous être profitable ? Pour en revenir aux problèmes de qualité liés spécifiquement aux libertés trop importantes de saisie, d'une part, et à la relative faiblesse des métadonnées d'autre part, je livre en prime time des extraits d'un document sur lequel GAIAGO travaille depuis quelques mois, en interaction avec le CERTU (autre expert de la qualité des données s'il en est). Ce document est intitulé: LA PROBLEMATIQUE DE LA QUALITE DES DONNEES GEOGRAPHIQUES COLLABORATIVES, Cas d'OpenStreetMap, pistes de solutions. J'ai fait une recherche sans succès pour retrouver dans les archives les premiers messages venant du monde des SIG (les pros) au tout début d'OSM et proposant déjà ce modèle figé des attributs (il y a en a aussi dans le wiki) normés et même standardisés au niveau international. C'est le concept du limited crowdsourcing ou encore les contributions sont libres mais la manière est figée. Ce modèle a été rejeté dès le départ par les fondateurs du projet qui parient sur l'imagination et la créativité des utilisateurs. Mais libre à certains de proposer des solutions alternatives et mieux encadrées mais elles ne seront pas adoptées par OSM. Peut-être devraient-ils s'adresser à UPTC. Rhôoo, tu es cassant là ;-) Quant on connait la fin de UPCT ... Pour le reste, essayer de rendre un tag source obligatoire et imposer cinq champs d'informations pour chaque objet créé prête effectivement à sourir tant on se retrouve éloigné des pratiques actuelles de contributeurs amateurs et bénévoles que nous sommes dans l'immense majorité. Certes ! F. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qual ité des données libres d'OpenStreetMap en France
A Denis: J'ai bien aimé la comparaison avec les pièces d'une habitation. A Emilie: Oui, je suis d'accord sur le fait qu'une application trop contraignante ferait fuir les contributeurs, et donc tuerait le projet. L'idée était de partir de la théorie, pour lancer le débat. Apparemment, les réactions n'ont pas trainé et prouvent la réactivité de la communauté. Il faut réflechir ensemble à des spécifications qui permettraient de vérouiller un peu plus la topologie et le modèle de données, et qui permettraient d'augmenter la quantité de métadonnées, sans pour autant contraindre le contributeur. Et c'est possible, selon moi. Pour les métadonnées, il faut au moins forcer le renseignement de la (ou des) source(s). Si on n'a pas d'informations sur la précision géométrique de la source, il faut pouvoir donner à ceux qui souhaitent en savoir plus les moyens de retrouver cette information. En indiquant qu'on a utilisé un GPS standard, on indique déjà quelque chose (précision de +/- 10 m voire pire en milieu urbain dense ou avec couvert végétal). En indiquant qu'on s'est basé sur la photo aérienne de Yahoo, en tel endroit, on dit aussi des choses, sans forcément connaître soi-même la précision altimétrique de l'ortho en cet endroit (mais quelqu'un qui veut retrouver l'info pour compléter le peut, et ce, sur une granulométrie plus large que le seul objet saisi). En indiquant qu'on a utilisé le cadastre, là, on ne donne aucune information de précision géométrique, car cette dernière est très hétérogène d'une zone à l'autre. Lorsqu'il y a plusieurs sources, ou lorsqu'on modifie un objet déjà produit avec une source A pour le préciser à l'aide d'une source B, alors intervient la notion très importante de généalogie de l'objet (un peu comme la traçabilité d'une barquette de côtes d'agneau). Cette notion doit être approfondie. On pourrait donc simplement demander le renseignement de la source de la contribution (donc cette information serait portée non plus par l'objet mais par l'historique de ses modifications) parmi une liste de valeurs FIXEE (GPS, french cadastre, aerial photography, local knowledge, other...). Mais là, j'ouvre un autre débat: qui a le droit de fixer et d'étendre cette liste de valeurs? Comme dans Wikipédia, la notion des différents niveaux d'écriture se fait jour, d'une manière ou d'une autre. La validation de la saisie (ou de la modification) ne serait acquise que lorsque la source serait renseignée. D'autres informations, qui dépendent de la valeur précédemment rentrée et du lieux pourraient être affectées automatiquement (on sait que sur Toulouse, l'ortho a telle précision en EMQ, on sait que les droits d'utilisation du cadastre sont restreints, etc...). Je pense que les métadonnées doivent au maximum descendre au niveau le plus bas de granularité, quand cela est possible, et quand cela ne risque pas de faire fuir le contributeur. J'attire l'attention sur la notion de responsabilité d'un producteur de données, quelles qu'elles soient (critiques sur Allociné, article sur Moïse dans Wikipédia, container à verre dans OSM, article dans Rue89, etc...). En tant que contributeur citoyen, il n'est pas sensé écrire, ou produire, n'importe quoi. Son action peut avoir des conséquences immenses, et il est sensé le savoir, et l'assumer. Le Web 2.0 n'est pas qu'une fenêtre ouverte sur le monde sans garde corps, et OSM n'échappe pas à cette règle. Si on s'investit pour comprendre Potlatch, JOSM et les outils annexes, si on passe ses soirées et ses week end à représenter le monde autour de chez soi, ce n'est pas pour le faire par dessus la jambe, même si c'est un loisir. Il y a un principe de responsabilité auquel on ne peut pas échapper. Dans ce cadre, il est normal de qualifier l'information qu'on fournit, notamment ses sources, et de s'efforcer à tendre vers un certain niveau de qualité, qui qu'on soit, quel que soit son niveau, à partir du moment où on est Internaute 2.0 OSM n'aurait pas le succès qu'il a si - en majorité - les contributeurs n'étaient pas dans cet état d'esprit. Les données seraient purement et simplement fantaisistes et donc inexploitables. Les contributeurs ont déjà cette notion de responsabilité. Leur demander une ou deux métadonnées supplémentaires ne ferait que renforcer ce sentiment, je ne pense pas qu'ils s'enfuiraient en courant, dans la mesure où le cadrage resterait raisonnable. Pour finir, les données non qualifiées n'ont que peu d'usages possibles. L'importance des métadonnées est encore mal perçue, mais même ce phénomène évolue assez vite. Merci à tous pour vos réactions. Serge Mang ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
2009/11/17 Serge Mang GAIAGO s.m...@gaiago.fr: J'ai déjà entendu cela de la part de ceux qui voudraient voir OSM devenir un référentiel. Avec son corollaire de restrictions (attributs et objets figés, nouvelles contributions sous contrôle). Mais, je l'ai déjà dit par ailleurs, il ne faut pas trop attendre de ce modèle et de son résultat. Nous pouvons tendre vers une amélioration de la qualité et une meilleure exaustivité mais nous n'atteindrons jamais la qualité ni la couverture de l'IGN. C'est impossible mais en même temps pas grave. Nos concurents se trouvent d'avantage du côté de TeleAtlas, Navteq et GoogleMaps. A propos de ce dernier, son succès partout sur internet (y compris sur de nombreux sites institutionels) montre qu'il y a de nombreux besoins en matière de données géographiques qui n'ont pas besoin d'un niveau de qualité et de précisions délirants. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en France
Non, ce mail n'est pas vide :) (voir ci-dessous) Le 17 nov. 2009 à 16:57, Pieren a écrit : Pas moi. Toute l'étude se fait sur une comparaison avec leur BD en référentiel, donc toute différence est jugée comme une erreur en défaveur d'OSM sans jamais se poser la question de savoir qui a raison ou même si quelqu'un a raison. C'est la crédibilité même de l'étude qui est en jeu par cette méthode. Dire par exemple 40% d'erreur sur la nature des routes est un non-sens parce qu'OSM ne veut justement pas recopier la même classification des routes que la BD-Topo. Il ne faut pas dire 40% d'erreur mais 40% de différence. Je pourrais tout aussi bien dire que c'est l'IGN qui a 40% d'erreur avec OSM. Certaines routes primaires (nationales) de l'IGN sont moins fréquentées que certaines départementales et OSM tient compte dans cette réalité alors que l'IGN est tenu par les classifcations administratives. Alors qui a raison ? et sur quelle base ? Rejeter l'attribut tertiary parce qu'il n'entre pas dans les cases existantes (donc forcément mal définie) est assez exemplaire de l'impossibilité de comparer des choses incomparables mais qui amènent des conclusions tendencieuses. Complètement d'accord. Autant sur la géométrie je pense qu'ils ont sans doute raison de prendre leur base comme référence autant sur la classification c'est n'importe quoi. Même si la méthode était discutable (ce qui reste à démontrer), les ordres de grandeur sont éloquents. Et la raison principale évoquée, à savoir le manque de cadrage à la saisie est absolument vrai. Actuellement, on peut faire à peu près ce que l'on souhaite lorsqu'on fait une contribution, notamment en terme de modèle de données et de topologie. Les pistes de réflexion proposées par le COGIT semblent pertinentes et les actions évoquées, à savoir Le COGIT étudie des méthodes permettant de définir des spécifications au sein de systèmes de saisie collaborative, ne sont pas à prendre à la légère et sont à encourager, Tout à fait ! Discussion toute théorique qui, si elle sort un jour des laboratoires, ne serait mise en application que par l'IGN. Oui et non. S'ils y a de bonnes idées on serait bien bête de cracher dessus par principe. Pour le reste, essayer de rendre un tag source obligatoire et imposer cinq champs d'informations pour chaque objet créé prête effectivement à sourir tant on se retrouve éloigné des pratiques actuelles de contributeurs amateurs et bénévoles que nous sommes dans l'immense majorité. Concernant le tag source, je pense que c'est très compliqué d'avoir une information pertinente. Plusieurs exemples où ça devient compliqué : - J'enregistre une trace GPS. Supposons que j'ai un GPS précis au mètre (oui je sais), je suis sur autoroute en voiture. Ma trace n'est que celle du parcours de ma voiture. Si la voirie comprend plus d'une voie, dois-je sourcer sur quelle voie j'ai conduit ? Que faire quand je double un autre véhicule ? Le GPS était-il sur la planche de bord ou la plage arrière ? Côté conducteur ? passager ? au milieu ? On s'en sort pas... - Je passe dans un tunnel (toujours avec mon GPS métrique), du coup je fais une interpolation via les images yahoo de la partie couverte. Là encore se pose un problème : changer la source ? même si j'ai appliqué une correction pour translater l'image yahoo de manière à ce qu'elle soit correctement rattachée à la partie GPS de ma trace ? - Plus loin je passe sur un pont métallique. Je ne pers pas le signal GPS, mais entre le multipath dû au haubanage, et les pilonnes, la précision est tombée à 25m, je dois changer la source ou reporter le DOP de chaque point ? Bref tout ça me parait assez impraticable à moins de passer nos journées à ne bosser que pour OSM, à faire du relevé sur le terrain exclusivement et avec du matos pro. Ne pas oublier non plus la formation de géomètre... De toute façon il m'a toujours semblé qu'OSM ne se targuait pas d'une précision métrique mais plutot décamétrique en moyenne. D'un autre côté, si je me souviens bien Navteq se targue d'une point tous les 10m en ville, 50m hors agglo et tous les 100m sur autoroute. On n'a donc sans doute pas trop à rougir... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la quali té des données libres d'OpenStreetMap en France
Je reviens un peu sur la précision. D'abord, comme le suggère quelques un, j'essaie de toujours mettre source=GPS quand j'ai utilisé une trace de mon GPS... surtout si je me doute que la qualité est médiocre, ce que je vérifie en temps réel sur le terrain en regardant l'erreur probable annoncée. Je vérifie éventuellement à postériori en reportant ma trace dans Google Earth. A propos des moyennes, regardez l'exemple suivant: http://osm.org/go/0Aq6qOk1B-- Allez dans Potlatch et faites afficher les traces GPS (G). C'est dans une vallée un peu encaissée. Non seulement, ce n'est pas trop divergent mais au nord du carrefour sur la route principale, il y a un terre-plein central qu'on distingue entre les deux faisceaux de traces. Au sud du carrefour, on voit aussi que le chemin actuel est bien dans les choux. Question précision, les 10 m, c'est jouable dans pas mal de cas. Imaginons maintenant qu'il apparaisse des logiciels de navigation sur PDA... qui en retour de parcours, envoient automatiquement leurs données à OSM. On peut alors facilement affiner les grands axes, découvrir les petites routes non encore cartographiées, les connectivités foireuses ou manquantes. Si en plus, c'est assisté par l'utilisateur, en lui posant des questions quand son parcours ne correspond pas à OSM, du style : Vous êtes sur une route inconnue. De quoi s'agit-il? - L'accès à mon garage, nouvelle route, chemin forestier... A mon avis, la précision, ce n'est pas l'urgent. Ca peut venir quand OSM sera largement employé et pour ça, il faut surtout qu'il y ai la majorité des routes et des connexions. Mes 0,02 € Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Rencontres SIG La Lettre
Bonsoir, Du 4 au 6 mai 2010, il y aura les Rencontres SIG La Lettre à l'ENSG. L'OSGeo-fr tiendra un stand au sein du village opensource, et se propose de le partager avec OSM(-fr ?). Nous pourrons, je pense, rembourser les frais de transports (depuis France métropolitaine) et les repas de midi pour une personne. Y a t'il des gens intéressés ? Eventuellement, on peut imaginer un roulement de contributeurs sur les 3 jours... A+ F. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
Bonsoir, C'est intéressant la responsabilité du mappeur sur OSM Je vise 1. Au respect de la vie privée de tout un chacun (on ne renseigne pas de nom sur les maisons par exemples) 2. Au respect des ajouts des autres contributeurs (pas de vandalisme) 3. A m'éviter de passer pour un boulet vis à vis des autres contributeurs dans mes ajouts Sorti de cela, auprès de qui suis-je responsable de la qualité de ma prestation ? Le 17 novembre 2009 17:14, Serge Mang GAIAGO s.m...@gaiago.fr a écrit : A Denis: J'ai bien aimé la comparaison avec les pièces d'une habitation. A Emilie: Oui, je suis d'accord sur le fait qu'une application trop contraignante ferait fuir les contributeurs, et donc tuerait le projet. L'idée était de partir de la théorie, pour lancer le débat. Apparemment, les réactions n'ont pas trainé et prouvent la réactivité de la communauté. Il faut réflechir ensemble à des spécifications qui permettraient de vérouiller un peu plus la topologie et le modèle de données, et qui permettraient d'augmenter la quantité de métadonnées, sans pour autant contraindre le contributeur. Et c'est possible, selon moi. Pour les métadonnées, il faut au moins forcer le renseignement de la (ou des) source(s). Si on n'a pas d'informations sur la précision géométrique de la source, il faut pouvoir donner à ceux qui souhaitent en savoir plus les moyens de retrouver cette information. En indiquant qu'on a utilisé un GPS standard, on indique déjà quelque chose (précision de +/- 10 m voire pire en milieu urbain dense ou avec couvert végétal). En indiquant qu'on s'est basé sur la photo aérienne de Yahoo, en tel endroit, on dit aussi des choses, sans forcément connaître soi-même la précision altimétrique de l'ortho en cet endroit (mais quelqu'un qui veut retrouver l'info pour compléter le peut, et ce, sur une granulométrie plus large que le seul objet saisi). En indiquant qu'on a utilisé le cadastre, là, on ne donne aucune information de précision géométrique, car cette dernière est très hétérogène d'une zone à l'autre. Lorsqu'il y a plusieurs sources, ou lorsqu'on modifie un objet déjà produit avec une source A pour le préciser à l'aide d'une source B, alors intervient la notion très importante de généalogie de l'objet (un peu comme la traçabilité d'une barquette de côtes d'agneau). Cette notion doit être approfondie. On pourrait donc simplement demander le renseignement de la source de la contribution (donc cette information serait portée non plus par l'objet mais par l'historique de ses modifications) parmi une liste de valeurs FIXEE (GPS, french cadastre, aerial photography, local knowledge, other...). Mais là, j'ouvre un autre débat: qui a le droit de fixer et d'étendre cette liste de valeurs? Comme dans Wikipédia, la notion des différents niveaux d'écriture se fait jour, d'une manière ou d'une autre. La validation de la saisie (ou de la modification) ne serait acquise que lorsque la source serait renseignée. D'autres informations, qui dépendent de la valeur précédemment rentrée et du lieux pourraient être affectées automatiquement (on sait que sur Toulouse, l'ortho a telle précision en EMQ, on sait que les droits d'utilisation du cadastre sont restreints, etc...). Je pense que les métadonnées doivent au maximum descendre au niveau le plus bas de granularité, quand cela est possible, et quand cela ne risque pas de faire fuir le contributeur. J'attire l'attention sur la notion de responsabilité d'un producteur de données, quelles qu'elles soient (critiques sur Allociné, article sur Moïse dans Wikipédia, container à verre dans OSM, article dans Rue89, etc...). En tant que contributeur citoyen, il n'est pas sensé écrire, ou produire, n'importe quoi. Son action peut avoir des conséquences immenses, et il est sensé le savoir, et l'assumer. Le Web 2.0 n'est pas qu'une fenêtre ouverte sur le monde sans garde corps, et OSM n'échappe pas à cette règle. Si on s'investit pour comprendre Potlatch, JOSM et les outils annexes, si on passe ses soirées et ses week end à représenter le monde autour de chez soi, ce n'est pas pour le faire par dessus la jambe, même si c'est un loisir. Il y a un principe de responsabilité auquel on ne peut pas échapper. Dans ce cadre, il est normal de qualifier l'information qu'on fournit, notamment ses sources, et de s'efforcer à tendre vers un certain niveau de qualité, qui qu'on soit, quel que soit son niveau, à partir du moment où on est Internaute 2.0 OSM n'aurait pas le succès qu'il a si - en majorité - les contributeurs n'étaient pas dans cet état d'esprit. Les données seraient purement et simplement fantaisistes et donc inexploitables. Les contributeurs ont déjà cette notion de responsabilité. Leur demander une ou deux métadonnées supplémentaires ne ferait que renforcer ce sentiment, je ne pense pas qu'ils s'enfuiraient en courant, dans la mesure où le cadrage resterait raisonnable. Pour finir, les données non qualifiées
Re: [OSM-talk-fr] Première évaluation de la quali té des données libres d'OpenStreetMap en France
Effectivement, la précision géométrique n'est pas la pierre d'achoppement d'OSM, pour le moment. L'exhaustivité, la topologie, l'homogénéité des tags et la précision sémantique sont des éléments plus importants. On a souvent tendance à faire un raccourci rapide entre qualité et précision géométrique. Le premier ne se résume pas au second. Et la connaissance du premier ne se limite pas à la connaissance du second. Le fait de connaître une source donne certes des indications potentielles ou directes sur la précision géométrique (et encore, les exemples cités sur le GPS par bon nombre d'entre vous l'infirment), mais aussi d'autres informations: l'année où la source a été produite, le producteur de la source, les droits d'utilisation des données sources, etc... Les métadonnées donnent des éléments précieux sur ces points là aussi, et ces éléments peuvent ensuite déterminer si les données sont utilisables ou pas pour telle ou telle application, et avec quelle plage de risque. Je vois que les réactions sont vives et fournies. Je m'en réjouis, même si beaucoup d'avis s'opposent à mes idées trop théoriques. C'est le but d'un débat, et j'apprends beaucoup à partir des argumentaires exposés. Veuillez excuser le ton yaka focon de mon extrait de document. Le but, encore une fois, était d'alimenter le débat sur la qualité et le contrôle de cette qualité. Dans mon esprit, l'idée finale est qu'OSM puisse être utilisé par une collectivité locale, voire par un SDIS ! La précision géométrique n'est pas forcément le plus important en regard de la topologie ou de la précision sémantique. Eric Sibert a écrit : Je reviens un peu sur la précision. D'abord, comme le suggère quelques un, j'essaie de toujours mettre source=GPS quand j'ai utilisé une trace de mon GPS... surtout si je me doute que la qualité est médiocre, ce que je vérifie en temps réel sur le terrain en regardant l'erreur probable annoncée. Je vérifie éventuellement à postériori en reportant ma trace dans Google Earth. A propos des moyennes, regardez l'exemple suivant: http://osm.org/go/0Aq6qOk1B-- Allez dans Potlatch et faites afficher les traces GPS (G). C'est dans une vallée un peu encaissée. Non seulement, ce n'est pas trop divergent mais au nord du carrefour sur la route principale, il y a un terre-plein central qu'on distingue entre les deux faisceaux de traces. Au sud du carrefour, on voit aussi que le chemin actuel est bien dans les choux. Question précision, les 10 m, c'est jouable dans pas mal de cas. Imaginons maintenant qu'il apparaisse des logiciels de navigation sur PDA... qui en retour de parcours, envoient automatiquement leurs données à OSM. On peut alors facilement affiner les grands axes, découvrir les petites routes non encore cartographiées, les connectivités foireuses ou manquantes. Si en plus, c'est assisté par l'utilisateur, en lui posant des questions quand son parcours ne correspond pas à OSM, du style : Vous êtes sur une route inconnue. De quoi s'agit-il? - L'accès à mon garage, nouvelle route, chemin forestier... A mon avis, la précision, ce n'est pas l'urgent. Ca peut venir quand OSM sera largement employé et pour ça, il faut surtout qu'il y ai la majorité des routes et des connexions. Mes 0,02 € Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en France
Ab_fab a écrit : Bonsoir, C'est intéressant la responsabilité du mappeur sur OSM Je vise 1. Au respect de la vie privée de tout un chacun (on ne renseigne pas de nom sur les maisons par exemples) 2. Au respect des ajouts des autres contributeurs (pas de vandalisme) 3. A m'éviter de passer pour un boulet vis à vis des autres contributeurs dans mes ajouts Sorti de cela, auprès de qui suis-je responsable de la qualité de ma prestation ? Auprès des utilisateurs de données, tout simplement. Des dégats matériels et environnementaux, des pertes financières, et même des vies humaines sont potentiellement en jeux si on utilise des données qui ont été produites n'importe comment. Même des données libres. Elles n'ont aucune raison d'échapper à cette règle. Si demain, un SDIS veut utiliser OSM, il voudra s'assurer de la responsabilité des producteurs avant de basculer vers une appli full OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
(re)bonsoir Je rebondis sur les exemples ci-dessous, car ils sont très bien choisis En tant que mappeur, je ne me reconnais pas de responsabilité vis à vis de l'utilisation que pourra faire de mes contributions un SDIS ou un élu local ! Une satisfaction probablement de voir mon travail utile à un service public, mais certainement pas une responsabilité juridique vis-à-vis d'un camion de pompier qui se perdra à cause d'un rond-point mal goupillé. Il faut des intermédiaires qui endossent cette responsabilité, qui peut aller loin. En contrepartie de cette garantie qu'ils apporteront, ils pourront certainement monnayer leur plus-value Le 17 novembre 2009 18:40, Serge Mang GAIAGO s.m...@gaiago.fr a écrit : Effectivement, la précision géométrique n'est pas la pierre d'achoppement d'OSM, pour le moment. L'exhaustivité, la topologie, l'homogénéité des tags et la précision sémantique sont des éléments plus importants. On a souvent tendance à faire un raccourci rapide entre qualité et précision géométrique. Le premier ne se résume pas au second. Et la connaissance du premier ne se limite pas à la connaissance du second. Le fait de connaître une source donne certes des indications potentielles ou directes sur la précision géométrique (et encore, les exemples cités sur le GPS par bon nombre d'entre vous l'infirment), mais aussi d'autres informations: l'année où la source a été produite, le producteur de la source, les droits d'utilisation des données sources, etc... Les métadonnées donnent des éléments précieux sur ces points là aussi, et ces éléments peuvent ensuite déterminer si les données sont utilisables ou pas pour telle ou telle application, et avec quelle plage de risque. Je vois que les réactions sont vives et fournies. Je m'en réjouis, même si beaucoup d'avis s'opposent à mes idées trop théoriques. C'est le but d'un débat, et j'apprends beaucoup à partir des argumentaires exposés. Veuillez excuser le ton yaka focon de mon extrait de document. Le but, encore une fois, était d'alimenter le débat sur la qualité et le contrôle de cette qualité. Dans mon esprit, l'idée finale est qu'OSM puisse être utilisé par une collectivité locale, voire par un SDIS ! La précision géométrique n'est pas forcément le plus important en regard de la topologie ou de la précision sémantique. Eric Sibert a écrit : Je reviens un peu sur la précision. D'abord, comme le suggère quelques un, j'essaie de toujours mettre source=GPS quand j'ai utilisé une trace de mon GPS... surtout si je me doute que la qualité est médiocre, ce que je vérifie en temps réel sur le terrain en regardant l'erreur probable annoncée. Je vérifie éventuellement à postériori en reportant ma trace dans Google Earth. A propos des moyennes, regardez l'exemple suivant: http://osm.org/go/0Aq6qOk1B-- Allez dans Potlatch et faites afficher les traces GPS (G). C'est dans une vallée un peu encaissée. Non seulement, ce n'est pas trop divergent mais au nord du carrefour sur la route principale, il y a un terre-plein central qu'on distingue entre les deux faisceaux de traces. Au sud du carrefour, on voit aussi que le chemin actuel est bien dans les choux. Question précision, les 10 m, c'est jouable dans pas mal de cas. Imaginons maintenant qu'il apparaisse des logiciels de navigation sur PDA... qui en retour de parcours, envoient automatiquement leurs données à OSM. On peut alors facilement affiner les grands axes, découvrir les petites routes non encore cartographiées, les connectivités foireuses ou manquantes. Si en plus, c'est assisté par l'utilisateur, en lui posant des questions quand son parcours ne correspond pas à OSM, du style : Vous êtes sur une route inconnue. De quoi s'agit-il? - L'accès à mon garage, nouvelle route, chemin forestier... A mon avis, la précision, ce n'est pas l'urgent. Ca peut venir quand OSM sera largement employé et pour ça, il faut surtout qu'il y ai la majorité des routes et des connexions. Mes 0,02 € Eric ___ 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 -- -- ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en France
Serge Mang GAIAGO a écrit : A Denis: J'ai bien aimé la comparaison avec les pièces d'une habitation. A Emilie: Oui, je suis d'accord sur le fait qu'une application trop contraignante ferait fuir les contributeurs, et donc tuerait le projet. L'idée était de partir de la théorie, pour lancer le débat. Apparemment, les réactions n'ont pas trainé et prouvent la réactivité de la communauté. Il faut réflechir ensemble à des spécifications qui permettraient de vérouiller un peu plus la topologie et le modèle de données, et qui permettraient d'augmenter la quantité de métadonnées, sans pour autant contraindre le contributeur. pour moi c'est tout trouve : une bonne aide bien redigee y'a deja la page map_features qui est tres bien, y'a des manques sur d'autres points plus orientes comment on taggue ca exemples : le groupe d'iles qui a un nom en tant que groupe, une place dans une ville qui a des voies balisees pour la circulation des voitures, une ecole avec plusieurs batiments, etc... c'est tout des choses qu'on sait comment faire mais c'est pas dans le wiki, ou alors bien cache y'a aussi des manques sur ce qu'il est important de faire meme si ca semble pas evident : connectivite pour les bots qui cherchent des chemins, sources, differentes relations et leurs usages, etc... les contributeurs qui cherchent a bien faire (presque tous) ne manqueront pas de s'y referer abondamment ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en France
On mardi 17 novembre 2009, Serge Mang GAIAGO wrote: été produites n'importe comment. Même des données libres. Elles n'ont aucune raison d'échapper à cette règle. Si demain, un SDIS veut utiliser OSM, il voudra s'assurer de la responsabilité des producteurs avant de basculer vers une appli full OSM. Et ben ils vont pas être déçu : http://wiki.openstreetmap.org/wiki/Terms_of_Use_-_Discussion_Draft (Section Disclaimers; No Warranties ) Je ne prétend pas qu'il y ait dé-responsabilisassions totale (notamment personnelle, morale et ce genre de chose) mais à mon avis, de non juriste, elle ne vaut plus grand chose à partir du moment où l'utilisateur des données OSM a accepté de se conformer au contrat qu'il signe (virtuellement) en les utilisant/téléchargeant sur le site osm.org et qui sont indiquées dans le lien précédent, et qui sont un très grand classique de la plupart des logiciels libres, et qui n'ont pas, devant une court, et à ma connaissance, été remis en cause. Et en gros ça se résume toujours à : No warranties TO THE FULLEST EXTENT PERMISSIBLE PURSUANT TO APPLICABLE LAW, OSMF DISCLAIMS ALL WARRANTIES, STATUTORY, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT OF PROPRIETARY RIGHTS. NO ADVICE OR INFORMATION, WHETHER ORAL OR WRITTEN, OBTAINED BY YOU FROM OSMF OR THROUGH THE OSMF SITE, WILL CREATE ANY WARRANTY NOT EXPRESSLY STATED HEREIN. -- sly Sylvain Letuffe sylv...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en France
Je ne parlais pas de responsabilité juridique, mais, pour employer des gros mots, plutôt d'ordre éthique. Un internaute 2.0 est un citoyen. En ce sens, il a la possibilité de contribuer (droit) et est responsable (devant la société) de ce qu'il produit (devoir). A fond pour une aide détaillée, pédagogique, etc... sly (sylvain letuffe) a écrit : On mardi 17 novembre 2009, Serge Mang GAIAGO wrote: été produites n'importe comment. Même des données libres. Elles n'ont aucune raison d'échapper à cette règle. Si demain, un SDIS veut utiliser OSM, il voudra s'assurer de la responsabilité des producteurs avant de basculer vers une appli full OSM. Et ben ils vont pas être déçu : http://wiki.openstreetmap.org/wiki/Terms_of_Use_-_Discussion_Draft (Section Disclaimers; No Warranties ) Je ne prétend pas qu'il y ait dé-responsabilisassions totale (notamment personnelle, morale et ce genre de chose) mais à mon avis, de non juriste, elle ne vaut plus grand chose à partir du moment où l'utilisateur des données OSM a accepté de se conformer au contrat qu'il signe (virtuellement) en les utilisant/téléchargeant sur le site osm.org et qui sont indiquées dans le lien précédent, et qui sont un très grand classique de la plupart des logiciels libres, et qui n'ont pas, devant une court, et à ma connaissance, été remis en cause. Et en gros ça se résume toujours à : No warranties TO THE FULLEST EXTENT PERMISSIBLE PURSUANT TO APPLICABLE LAW, OSMF DISCLAIMS ALL WARRANTIES, STATUTORY, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT OF PROPRIETARY RIGHTS. NO ADVICE OR INFORMATION, WHETHER ORAL OR WRITTEN, OBTAINED BY YOU FROM OSMF OR THROUGH THE OSMF SITE, WILL CREATE ANY WARRANTY NOT EXPRESSLY STATED HEREIN. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
Le Tue 17 Nov 2009 a 13:46 +, Emilie Laffray a ecrit : Oui, je suis d'accord sur le fait qu'il y ait besoin d'avoir un outil automatique pour les traces. Je pense que c'est justement ce genre de chose qui nous permettra d'assurer la qualit� de OSM a long terme. ++ Par contre, �a exige de repenser de fond en comble l'API, il me semble, et de conserver une quantit� de donn�es bien plus importante. -- � /\Guillaume All�greMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et d�fendre le logiciel libre / /~~\t�l. 04.76.63.26.99 http://www.april.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en France
Pieren a écrit : J'ai déjà entendu cela de la part de ceux qui voudraient voir OSM devenir un référentiel. Avec son corollaire de restrictions (attributs et objets figés, nouvelles contributions sous contrôle). Mais, je l'ai déjà dit par ailleurs, il ne faut pas trop attendre de ce modèle et de son résultat. Nous pouvons tendre vers une amélioration de la qualité et une meilleure exaustivité mais nous n'atteindrons jamais la qualité ni la couverture de l'IGN. C'est impossible mais en même temps pas grave. Nos concurents se trouvent d'avantage du côté de TeleAtlas, Navteq et GoogleMaps. A propos de ce dernier, son succès partout sur internet (y compris sur de nombreux sites institutionels) montre qu'il y a de nombreux besoins en matière de données géographiques qui n'ont pas besoin d'un niveau de qualité et de précisions délirants. OSM a jeté un pavé dans la mare du monde de l'information géographique par son côté iconoclaste. D'un autre côté, de nombreux acteurs publics (collectivités locales, associations, ...) s'efforcent de mutualiser leurs ressources pour optimiser les efforts (financiers, travail). Ce sont des partenariats coopératifs pas toujours d'une efficacité redoutable à tel point qu'un jour j'en suis venu à me demander s'il n'était pas moins coûteux que chaque partenaire y aille de son côté plutôt que d'espérer une hypothétique solution à plusieurs. Ces deux mouvements ont créé des fronts d'onde qui se rencontrent aujourd'hui. Il y a du clapotis, visiblement. Qu'allons-nous en faire ? Attendre que les dernières ridules disparaissent avec le temps ou battre un tempo capable d'amplifier ces ondes jusqu'à ce qu'une fréquence soit audible par le citoyen ? Les seuls producteurs d'information géographiques considérables sont les collectivités locales (pour remplir leur missions) et les citoyens. Les autres acteurs ne font que combler des trous (avec brio pour Google misant sur l'utilisation plus que sur la donnée). Si nous parlons bien tous du même territoire, même si nous le voyions avec nos paires d'yeux tous différents, ce serait quand même le bout du monde si nous ne pouvions pas converger sur une description commune des choses qui nous entourent, dans lequelles nous vivont. L'intersection de nos deux approches ne devrait pas être vide ! Oui, il reste la méthode et ce n'est pas ce qui sera le plus facile, mais chacun a beaucoup y gagner, à apprendre. Cela peut se faire pas à pas. Claquer la porte d'emblée n'aboutira qu'à respirer un air de plus en plus confiné. Denis, militant des Portes Ouvertes ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la quali té des données libres d'OpenStreetMap en France
Guillaume Allegre wrote: Le Tue 17 Nov 2009 a 13:46 +, Emilie Laffray a ecrit : Oui, je suis d'accord sur le fait qu'il y ait besoin d'avoir un outil automatique pour les traces. Je pense que c'est justement ce genre de chose qui nous permettra d'assurer la qualit� de OSM a long terme. ++ Par contre, �a exige de repenser de fond en comble l'API, il me semble, et de conserver une quantit� de donn�es bien plus importante. Je ne pense pas. Ça demande juste de travailler en plusieurs étapes avant de travailler sur l'API et d'avoir quelque chose d'intermédiaire en tant que base de donnée. Tout dépend de la manière dont tu comptes faire l'analyse. Actuellement, les GPX ne font pas partie de OSM en tant que tel. Il n'y a pas de raison pour que ce dépôt ne serve pas a autre chose. Pour cela, nul besoin de changer l'API de OSM a moins que tu comptes faire cela en temps réel. Emilie Laffray signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en Franc e
Le Tue 17 Nov 2009 à 16:02 +0100, sly (sylvain letuffe) a ecrit : Je suis très content d'ajouter des source=précision ~5m, puce gps positronique d'interférence de phase SRTK à connecteurs en poils de chameau Et t'en es content ? Parce que j'ai la même, avec connecteurs en poils de dromadaire, et j'ai des problèmes de précision par temps humide. -- ° /\Guillaume AllègreMembre de l'April /~~\/\ allegre.guilla...@free.fr Promouvoir et défendre le logiciel libre / /~~\tél. 04.76.63.26.99 http://www.april.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Une association pour OSM - Wiki
Suite au plébiscite sur Doodle j'ai pris l'initiative de reprise de ce qui c'est dit dans ce fil de discutions et je l'ai posé sur le wiki. http://wiki.openstreetmap.org/wiki/WikiProject_France/Projet_d'association_en_France En espérant avoir été aussi partial que possible et ne pas trop avoir déformé les dires des uns et des autres. Fred ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nom d'un groupe d'îles - ar chipel
Bref, oups, edit : sur la page de discussion quelqu'un de très réfléchis semble avoir émis grosso modo les mêmes réserves Merci ;-) J'ai même poussé le vice plus loin. J'ai commencé à mettre des relations place=archipelago à droite, à gauche. Mais quand je suis arrivé aux Glénan, j'ai pleuré tellement c'était mal codé et incohérent alors j'ai arrêté :-( (Ensemble de lac portant un même nom avec une ile dans l'un d'eux) Bien que l'on puisse ergoter sur le fait que l'île porte ou nom le nom des lacs en plus de son propre nom d'île À propos de lac, comment on fait pour un ensemble de lacs qui ont des noms individuelles et un nom collectif. Exemple : Les 7 Laux. Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nom d'un groupe d'îles - ar chipel
Eric SIBERT a écrit : À propos de lac, comment on fait pour un ensemble de lacs qui ont des noms individuelles et un nom collectif. Exemple : Les 7 Laux. Avoir fait mono à Fond-de-France et être monté à pied aux Sept-Laux, il y a 45 ans, me permet d'avancer que les Sept-Laux sont plutôt un lieu-dit et non... un archipel de sept lacs. ;-) L'exemple serait plus difficile, si on voulait relier les lacs subalpins de l'Italie du Nord, mais y-en aurait-il besoin? Christian ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nom d'un groupe d'îles - ar chipel
Selon Eric SIBERT courr...@eric.sibert.fr: J'ai même poussé le vice plus loin. J'ai commencé à mettre des relations place=archipelago à droite, à gauche. Mais quand je suis arrivé aux Glénan, j'ai pleuré tellement c'était mal codé et incohérent alors j'ai arrêté :-( ? comment ça peut être mal codé y'a bien un way en rond qui fait le tour de chaque île, yaka l'ajouter à la relation (désolé, je suis pas aller voir, j'ai le mal de mer) À propos de lac, comment on fait pour un ensemble de lacs qui ont des noms individuelles et un nom collectif. Exemple : Les 7 Laux. T'as fait comment pour tes îles ? Ben pareil non ? une relation name=7 laux pleins de ways fermés name=Lac carré/Lac je sais plus/etc. -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nom d'un groupe d'îles - ar chipel
Selon Christian Rogel christian.ro...@club-internet.fr: Avoir fait mono à Fond-de-France et être monté à pied aux Sept-Laux, il y a 45 ans, me permet d'avancer que les Sept-Laux sont plutôt un lieu-dit Je l'ai fait il y a pas longtemps donc ça a changé en 45 ans, le lieu-dit est parti un peu plus loin et les lacs sont arrivés. La tectonique va vite le nom a donc été transféré vers les lacs ! Bon, je plaisante, et la question était d'ordre technique au début et on pourrait prendre un autre exemple. Mais tu avouera que ton argument n'est pas super convainquant ? On peu en discuter sur talk-fr-belledonnes@ (si si avec un s) si vous voulez... et non... un archipel de sept lacs. ;-) J'aurais plutôt pensé que oui, puisque laux provient d'un patois quelconques voulant dire lacs et 7 étant leur nombre, ça semblait cohérent de dire que 7 laux est donc bien le nom du lieu-dit (au sens lieu nommé) qui est le lieu les 7 lacs donc une surface. L'exemple serait plus difficile, si on voulait relier les lacs subalpins de l'Italie du Nord, mais y-en aurait-il besoin? Je dirais que c'est différent puisque l'appellation lacs subalpins de l'Italie du Nord ne réfère à rien de connu par son nom puisqu'il s'agit plus d'une description. Par contre on pourrait tagguer une surface subalpine d'Italie du nord y mettre nos lacs et pouvoir définir leur présence en ces lieux est à l'intérieur de la surface. -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Première évaluation de la qualit é des données libres d'OpenStreetMap en France
bonsoir, je prends connaissance du débat OSM = IGN du jour...qui fait suite au débat OSM = Navteq+TA d'hier, décidément. Je rejoins l'avis des amateurs de portes ouvertes courants d'air, avec tous les défauts que ça occasionne. Je ne sais pas combien nous sommes sur la France mais dans la mesure où une connaissance locale est requise pour faire les choses correctement, on ne peut que souhaiter l'accroissement de la fourmilière. A quand le cap symbolique des 36.000 contributeurs, un par commune ? (une belle occasion de communication !) Côté compétences, l'ouverture à tout volontaire est à mon avis une nécessité. Le premier mappeur sur une zone doit accepter de voir son travail repris, façonné, au fil des passages (les siens comme ceux des autres). Sur ma ville, je reprends actuellement un grand tas de nouilles, des rues sans connexité, tracées via Potlach+Yahoo, avec comme souci premier d'obtenir un (beau) dessin. Au début ça me déprimais et j'en voulais même au mappeur qui a consacré tant de temps à mal faire ! A la réflexion, je lui suis désormais reconnaissant d'avoir défriché le terrain, saisi beaucoup de noms de rues, usé ses yeux sur la photo aérienne et apporté sa réelle connaissance du terrain. Sa contribution a une valeur que je sous-estimais. Ensuite, le cadastre (merci Pieren !) est très précieux pour affiner ce genre de première saisie. Et d'autres passeront derrière moi, la roue tourne. Des outils comme Keep Right faciliteront grandement la detection et la correction d'erreurs de topologie. Bref, y'a de l'espoir ;o) Concernant les meta-données, autant je ne crois pas à une saisie par tout un chacun de notions de précision, autant je trouve dommage qu'à l'heure actuelle on ne garde pas plus d'infos sur le contexte de saisie, infos qui pourraient déjà en dire long sur la précision à espérer d'un tracé. On sait parfois pour un objet au moyen de quel éditeur (JOSM, Potlach...) il a été saisi, via le tagcreated_by. En rajoutant quelques infos comme : - l'existence d'un vrai fond photo affiché au moment de la saisie - la présence de traces GPS à proximité immédiate du tracé réalisé - et surtout l'échelle de l'affichage (même si elle peut varier en cours de saisie) de la carte lorsque l'objet a été rentré on aurait à mon sens quelques meta-données sur le contexte, et par suite une aide pour évaluer la qualité des tracés. L'intérêt que je vois à ces informations est qu'il ne nécessite pas d'interaction, étant collectée silencieusement par le logiciel. Ca évite des questions fastidieuses qui monopolisent l'interface, allège l'ergonomie, et évite de poser des colles à des personnes pas au fait de notions géo-cartographiques. Sans aller bien loin, combien de personnes font le contre-sens sur petite et grande échelle ? Et par ailleurs la précision absolue ne fait pas tout. Elle a du sens en routing, mais que des tracés soient décalés de plusieurs dizaines de mètres peut ne pas impacter un usage comme Maposmatic, dès lors que le positionnement relatif des objets -les uns par rapport aux autres- est préservé. Et, comme déjà dit auourd'hui, non, OSM n'est pas un référentiel, en revanche la qualité du lien que la base peut offrir vers des bases de référence (exemple récent : le code INSEE) apportera de nombreuses opportunités de voir la base utilisée et popularisée. Trop long o;( Allez, bonne nuit, vincent (vdct) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
