Bonsoir, 2015-07-25 17:02 GMT-07:00 Jérôme Seigneuret <jseigneuret-...@yahoo.fr>:
> > > Le 26 juillet 2015 00:43, Emilie Laffray <emilie.laff...@gmail.com> a > écrit : > >> Bonjour, >> >> pour enfoncer encore un peu plus le clou que Vincent a enfonce. Je ne >> suis pas convaincue sur l'aspect de la precision des donnees present dans >> les jeux de donnees de type en general. Il me semble d'ailleurs que la >> plupart du temps ils sont plus fournis a titre indicatif et complemente par >> des puces implantes dans l'arbre. Grosso modo, ce n'est la que pour donner >> une indication generale. >> > > J'ai pas compris où tu veux en venir. En quoi le fait d'avoir une puce > pose un problème d'intégration et cela entraînerait un jeu de données de > mauvaise qualité ? > Un jeu de données ça ce test avec un échantillon aléatoire. Question > qualité, il n'existe pas de jeu de données avec une fiabilité à 100% à > cause de plein de raison. > J'ai jamais testé un jeu de données à 100% question coût ;-) > Le point que je faisais passer etait que comme la précision des données concernant les arbres étaient tellement faible, on marque l'arbre avec une puce individuelle, ce qui permet de travailler avec l'arbre que l'on veut sans avoir une localisation precise. > > >> Pour avoir aider a l'import Corine et avoir vu un import similaire peu de >> temps a Girona avant le SOTM 10, on s'est retrouve avec une qualite un peu >> bizarre. Certains d'entre nous avions tente d'etablir la qualite de >> l'import (globalement bon) mais quand on comparait avec des donnees GPS (en >> incluant differentes puces), on se rendait compte que la precision etait >> mediocre (precision de 5 a 10m). N'oublions pas que la quasi totalite des >> puces GPS dont Smartphone ont au mieux une precision de 5 metres et >> qu'OpenStreetMap a une precision de 6 decimales (en gros 15cm si je me >> rappelle bien), on se retrouve avec quelque chose de douteux. Bref, >> lorsqu'on descendra au centrimetrique en GPS, j'aurais plus confiance. >> Anecdocte amusante, les feuilles des arbres absorbent la frequence utilisee >> par les GPS rendant la qualite du GPS bien pire. >> >> Comparer la CLC à des arbres positionnés le plus souvent sur des ortho du > département ou de la ville dont la qualité est quand même pas celle de la > CLC... le pixel d'une ortho a une résolution de 20cm maintenant 50cm pour > la BD Ortho. Reste le calage... Sans compté qu'il est clair que connaitre > le mode de saisie est important. Si c'est la ville je ne pense pas qu'il > face ça avec un smartphone mais avec du Trimble et que c'est corrigé en > bureau. Tu auras plus de décalage avec le changement de projection qu'avec > la levé de terrain... Sinon les données correspondent (en tout cas pour > celles des collectivités) à des données de CAO et à des plans de > plantations. > Moui, enfin, j'ai juste mentionné CLC afin de faire référence au fait que l'import je connais un peu, et le point principal était surtout sur l'import des arbres de la ville de Gerone en Espagne. De plus, si tu veux rentrer dans les détails des puces GPS soit mais je n'ai jamais parle de puce GPS pour Smartphone. Grosso modo, oui, il faut utiliser du GPS différentiel ou du RTK si tu veux de la précision centimétrique, mais je ne suis pas convaincue que la plupart des municipalités s'amusent avec ce genre de matériel en premier lieu. Au final, dans beaucoup de cas, je ne suis pas convaincue que les plans de plantations crées généralement a postériori ou des données de CAO soit vraiment si bon que ça. Bref, on en revient a la source des données au final. > > Dans un de tes precedents emails, tu parlais de l'application potentielle >> de ce genre de donnees. C'est bien joli mais la premiere chose que je >> ferrai si j'avais a traiter ce genre de chose c'est surement de separer ces >> donnees dans une couche a part (voir aussi les arguments de Vincent). >> > > Oui surement comme le bati, le réseau routier ou l'occupation du sol... > reste qu'OSM et une base de données et pas un jeu de shapefile > OSM est en effet une base de données. Je ne suis pas contre un import de ce type, je suis généralement contre un import dont la qualité peut être douteuse. Enfin dans le cas présent, la précision a quelques mètres d'un arbre n'est pas bien grave dans la plupart des cas (voir carte non voyant) par exemple. Historiquement, je fais partie des membres du bureau de la fondation qui se sont opposes a la création d'un map.openstreetmap.com parce que pour moi OSM est une base de donnée. Je suis parfaitement consciente qu'OSM n'est pas un jeu de shapefile mais si tu regardes bien l'usage qui en fait dans de nombreux milieux, tu vois une décomposition en couche ce qui est relativement naturel dans la manière de travailler des gens. La question se pose alors sur la pertinence d'avoir ce jeu de données dans OSM au lieu d'un shapefile différent, en tenant compte de la qualité des données en premier lieu et de ces implications. Un des gros problèmes actuellement est a mes yeux les éditeurs OSM qui gère mal la densité des données. > > >> Bref, oui pour l'import, mais tes marges me font peur. De plus s'il y a >> overlap, soit on ne touche pas, soit on deplace le point existant. >> >> > En effet. C'est pour cela que je lui ai posé la question de savoir ce > qu'il ferait en cas de conflit. Là c'est le terrain qui doit permettre de > faire un choix en cas de conflit ou un fond de plan bien calé pour le > positionnement ou des données GPS de qualité pro. C'est le même principe > pour le reste des éléments comme le nom des voies en cas de conflits entre > différentes sources > > En cas de conflit, on ne touche pas aux données existantes tant que l'on n'a pas été vérifié ce qui est bon ou pas (et a nouveau un problème sur la qualité des données en premier lieu et/ou vérification). Les "données GPS de qualité pro", ça ne court pas les rues et ça n'est utilise que dans des cas très particuliers car le cout est loin d’être négligeable. En conclusion, oui potentiellement a l'import, mais pas a n'importe quel prix.
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
