non, là les points sont beaucoup plus loin que pour l'affichage sur une carte à grande échelle !<br>Sinon c'est qu'ils ont voulu positionner des points dans une ville depuis une carte au 1:1000000 ...<br><br>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 !<br>
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 ...<br><br>Sylvain<br><br><br><div class="gmail_quote">Le 9 octobre 2012 15:49, Philippe Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>></span> a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Le 9 octobre 2012 15:19, Sylvain Maillard <<a href="mailto:sylvain.maillard@gmail.com">sylvain.maillard@gmail.com</a>> a écrit :<br>

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