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
