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 ;-) > 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. > > Je suis plus moderee sur l'aspect negatif d'un import sur la communaute > surtout dans le cas d'un import de ce type. Toutefois, je suis convaincue > tout comme Vincent de l'importance d'une communaute locale afin d'assurer > une maintenance continue de la carte. > Je suis aussi de cet avis. En même temps, il y a des gens qui font ça en vacance (cas vu chez nous d'un jeune qui préfère ça à sa playstation) > 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 > 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
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
