Re: [OSM-dev-fr] Simplifier nos limites admin...
Le 15 décembre 2013 15:07, Christian Quest a écrit : > > Comme indiqué plus haut, celui-ci fonctionne bien dans la très grande > majorité des cas, mais sur certaines communes aux contours tarabiscotés, le > fait de simplifier les limites une à une peut faire qu'elles se croisent. > > Quelques exemples: > - Ferney-Voltaire: http://www.openstreetmap.org/relation/140088 > - Aren: http://www.openstreetmap.org/relation/2809778 > > > J'ai des doutes sur Ferney-Voltaire. La route douanière ne me semble pas faire partie de la commune, ni même du territoire français, même si l'usage est réservé à la France. En tout cas, le cadastre ne contient pas cette route. On a le même schéma au niveau de l'aéroport de Mulhouse-Bâle, avec une route douanière permettant aux Suisses de rejoindre l'aéroport. Mais on n'a pas "étiré" la frontière le long de cette route. Si j'en crois la convention franco-suisse, cette route fait toujours partie du territoire suisse : http://www.admin.ch/opc/fr/classified-compilation/19560067/index.html Voir l'article 13: " La route sera séparée par une clôture du reste des territoires suisse et français, mais la portion de route située en territoire suisse restera partie intégrante de ce territoire." On devrait donc pouvoir supprimer cette "excroissance" de Ferney-Voltaire. Matthias ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] osm2psql, problème de fichier.
2013/3/21 Vincent Pottier
>
>
> *[pid 25569] open("/home/vincent/tmp/france-latest.osm.pbf", O_RDONLY) =
> -1 EOVERFLOW (Value too large for defined data type)*
> [pid 25569] write(2, "Unable to open /home/vincent/tmp"..., 55Unable to
> open /home/vincent/tmp/france-latest.osm.pbf
>
C'est l'appel à open() qui retourne une erreur EOVERFLOW.
http://pubs.opengroup.org/onlinepubs/95399/functions/open.html
[EOVERFLOW]
The named file is a regular file and the size of the file cannot be
represented correctly in an object of type *off_t*.
Tu utilises un OS 32 bits ?
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] calcul d'erreurs
Le 2 octobre 2012 12:18, didier2020 a écrit : > qadastre utilise des float pendant son traitement > mais lors de l'écriture les coordonnées ont 6 décimales > les coordonnées stockées dans openstreetmap ont 7 décimales Ce comportement de qadastre est d'ailleurs générateur d'erreurs (nœuds dupliqués). En ne prenant qu'une coordonnée pour l'exemple : 0.1234561 et 0.1234562 sont considérés comme différents tout au long du traitement par qadastre, mais lors de la génération du fichier .osm, dans les 2 cas on obtiendra 0.123456. Donc on se retrouve parfois avec des nœuds ayant les mêmes coordonnées dans le fichier, bien qu'il aient été considérés comme distincts tout au long du traitement. J'avais commencé à faire des modifications de qadastre, entre autres en générant les coordonnées avec 7 décimales, mais faute de temps, c'est resté en l'état... ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Erreurs dans les fichiers cleo
Le 20 février 2012 13:02, 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. 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 dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Problème de compilation d'osm2pgsql
Le 3 décembre 2011 13:25, Julien Fastré a écrit : >> parse-primitive.o parse-xml2.o pgsql.o reprojection.o middle-ram.o >> output-gazetteer.o text-tree.o node-ram-cache.o -L/usr/lib >> -L/usr/lib64 -lpq /usr/lib/libxml2.so -ldl -lz -lm -lbz2 >> /usr/lib64/libgeos.so -lproj -pthread -Wl,-rpath -Wl,/usr/lib64 >> -Wl,-rpath -Wl,/usr/lib64 >> /usr/lib/libxml2.so: could not read symbols: File in wrong format >> collect2: ld returned 1 exit status >> make[2]: *** [osm2pgsql] Erreur 1 >> make[2] : on quitte le répertoire « >> /home/user/Téléchargements/osm2pgsql/osm2pgsql » >> make[1]: *** [all-recursive] Erreur 1 >> make[1] : on quitte le répertoire « >> /home/user/Téléchargements/osm2pgsql/osm2pgsql » >> make: *** [all] Erreur 2 > Je pense qu'il y a un problème avec libxml2... > > J'utilise opensuse 12.1. Le paquet libxml2 est installé en version 32 et > 64 bits. > > Que pensez-vous que je puisse faire ? L'erreur "File in wrong format" signale que tu mélanges des fichiers objets pour des architectures différentes. J'imagine que tu es sur x86, donc tu dois probablement mélanger du 32bits et du 64 bits. D'après le log, tu utilises un chemin en dur pour libxml2 (/usr/lib/libxml2.so). Essaie de remplacer ça par /usr/lib64/libxml2.so. Matthias ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Idées d'analyses pour Osmose...
Le 25 octobre 2011 10:53, Christian Quest a écrit : > Cohérence de la relation elle même: > - relation type=associatedStreet sans name=* Sur ce point là, il ne faudrait pas être aussi strict. Le wiki dit que le tag name est optionnel (mais recommandé). Et dans le fond, c'est assez logique, puisque le nom de la rue est censé se trouver dans l'élément avec rôle "street" (ou les éléments s'il y en a plusieurs). http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema Matthias ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] pb avec script cadastre
Le 24 octobre 2011 15:04, Nicolas Dumoulin a écrit : > Bonjour, > > Je voulais corriger la limite d'une commune (source CA) qui est vectorisée. > Sur cleo-carto, il n'y a pas tous les fichiers et notament le fichier > -boundary > est manquant. J'ai donc téléchargé les scripts pour le générer. Bonjour, Je viens d'essayer sur cleo-carto et les limites sont disponibles: http://cadastre.cleo-carto.org/data/012/7K226-SAINT-HIPPOLYTE-city-limit.osm Sinon cleo-carto n'utilise pas les scripts bash et perl, mais qadastre2osm (à compiler, voir http://gitorious.org/qadastre/qadastre2osm). Matthias ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
