non, là les points sont beaucoup plus loin que pour l'affichage sur une carte à grande échelle ! Sinon c'est qu'ils ont voulu positionner des points dans une ville depuis une carte au 1:1000000 ...
au début j'ai pensé n'avoir rien compris à ce fichier xml, mais dans l'exemple que j'ai donné le point est clairement situé dans la mer (enfin, dans le port) et non pas en pleine ville, et il doit bien y avoir 2 km de décalage ! A ce point là ça n'est plus de l'affinage de position qu'il faut faire, c'est carrément la géolocalisation complète qui est à revoir ... Sylvain Le 9 octobre 2012 15:49, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Le 9 octobre 2012 15:19, Sylvain Maillard <sylvain.maill...@gmail.com> a > écrit : > > Salut, > > > > pour ma part je met un gros WARNING sur ce fichier ! > > > > un géo-codage effectué par la fédération de tourisme des bouches-du-rhône > > c'est suspect par nature (quand on a vu ce qu'ils ont sorti sur > > http://data.visitprovence.com), et à première vue les quelques poi que > j'ai > > testé ont tous une position absolument mauvaise, au mieux pas bonne ! > > Peut-être parce que leurs données ont été géocododées uniquelent pour > une représentation sur une carte à une échelle limitée. L'imprécision > est suffisante pour leur application et pour pouvoir discerner les > points entre eux et localiser les zones que chaque POI dessert (par > exemple tout un quartier). > > Cela n'ôte pas l'intérêt de ces données, si elles sont assez > exhaustives. Mais cela veut dire qu'il faut les regéolocaliser de > façon plus précise lors de l'intégration, en cherchant autour de façon > plus fine. > > C'est le même problème d'ailleurs avec les données des bureaux de La > Poste, ou des agences bancaires, ou d'autres sociétés, qui ne sont pas > à 200 mètres près, ou qui se contentent de localiser un point au > milieu de la bonne rue mais pas forcément au bon numéro ni du bon côté > de la rue. > > Bref on ne les "importe" pas directement, on les "intègre". > > Ce serait bien d'ailleurs que les imports de données qui contiennent > des positions géolocalisées indiquent une longueur de rayon pour > estimer l'erreur maximale commise dans la source. Ce qui aurait pour > effet de ne pas importer des nœuds simples mais des cercles autour du > point. Le tag de rayon de recherche indiquerait alors explicitement où > chercher le point si on veut le positionner de façon plus précise. Et > cela pourrait être suivi : en repositionnant le point plus > précisément, le tag de rayon pourrait alors être enlevé manuellement. > On aurait ensuite un suivi possible par des outils automatique, du > travail d'intégration consistant à les repositionner précisément. Et > tant que ce tag d'imprécision est présent, le nœud ne devrait pas > apparaître sur aucune carte de rendu (il devrait être caché par défaut > et ne serait visible que dans les éditeurs, et ne devrait même pas > pouvoir être lié à d'autres objets "précis" ne contenant aucun objet > imprécis, ou juste lié à des objets de d'imprécision équivalente). > > Cela permettrait de distinguer effectivement dans la base ce qui est > "importé" (imprécis par défaut et non rendu, y compris les bâtiments, > pusique le rayon d'imprécision serait même plus grand que les points > de polygone du bâtiment lui-même) de ce qui est "intégré". Jusqu'à > même permettre d'importer des doublons qui ne gêneront pas le rendu de > l'existant plus précis, et par des outils de vérifier ces doublons. > > Je proposerais par exemple "import_precision=<longueur en mètres de > l'imprécision>", à mettre surtout sur tous les noeuds importés (des > polygones peuvent être formés dessus, mais ils n'ont pas besoin de ce > tag car ils seront cachés par défaut dans les rendus puisqu'ils > référencent des noeuds imprécis. > > A la limite un rendu pourrait malgré tout les afficher si nécessaire > pour un rendu a faible niveau de zoom/échelle, où cette distance > d'imprécision n'est pas perceptible et fait moins de 1 pixel (mais il > resterait le risque de doublon non éliminé), ou bien les présenter > effectivement juste comme des disques semi-transparents ayant ce > rayon. > > _______________________________________________ > 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
