Le lundi 20 février 2012 à 13:47 +0100, Matthias Dietrich a écrit : > Le 20 février 2012 13:02, <[email protected]> a écrit : > > > => cela depend des données du fichier. cela varie > effectivement entre 0 et beaucoup trop. > => de plus, les coordonnées fournies par les fichiers cleo > sont arrondies et moins précises que les données stockée par > osm > => cela a peut etre une influence. > > > > 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 : > - les coordonnées sont générées à 1e-6 près, alors que la base OSM > stocke à 1e-7 près > - 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. > merci pour ces informations, la source de Qadastre2Osm etant en C-hinois pour moi ;-) > > 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. > 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. > > > Il faut encore que je contacte Pierre Ducroquet (pinaraf) pour lui > faire part de mes modifs. > > > Matthias > > > _______________________________________________ > dev-fr mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev-fr
_______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
