<div class="gmail_quote">Le 20 février 2012 13:02,  <span dir="ltr"><<a href="mailto:didier2020@free.fr" target="_blank">didier2020@free.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><br>
</div>=> cela depend des données du fichier. cela varie effectivement entre 0 et beaucoup trop.<br>
=> de plus, les coordonnées fournies par les fichiers cleo sont arrondies et moins précises que les données stockée par osm<br>
=> cela a peut etre une influence.<br><br></blockquote><div><br></div><div>Pour info, Qadastre2OSM (l'outil utilisé par cleo pour effectuer la conversion *.pdf vers *.osm) a en effet quelques problèmes dans la gestion des arrondis :</div>

<div>- les coordonnées sont générées à 1e-6 près, alors que la base OSM stocke à 1e-7 près</div><div>- Qadastre2OSM effectue tous ses calculs interne avec des flottants en double précision et ne génère la valeur à 1e-6 près qu'en toute fin de traitement, résultat des noeuds avec des coordonnées du style 48.12345612 et 48.12345634 sont considérés comme différents tout au long du traitement, mais aboutissent à la génération de 2 noeuds avec 48.123456, donc des noeuds dupliqués.</div>

<div><br></div><div>J'ai effectué les corrections dans mon dépôt git local, mais cela n'améliore que les noeuds dupliqués, pas les superpositions de bâtiments.</div><div>J'ai également ajouté un filtre pour les bâtiments dupliqués, mais sur mes fichiers de tests, j'avais essentiellement des superpositions partielles de bâtiments (plus de 1000 ...), et relativement peu de noeuds ou de ways dupliqués, donc je n'ai pas vu de grands changements.</div>

<div><br></div><div>Il faut encore que je contacte Pierre Ducroquet (pinaraf) pour lui faire part de mes modifs.</div><div><br></div><div>Matthias</div><div><br></div></div>