Talk:WikiProject France/Cadastre/Import semi-automatique des bâtiments
Il y a un truc qui me semble bizarre dans le données importées: tous les bâtiments ont un attribut wall=no, est ce à dire qu'ils n'ont pas de mur ? ce tag est peu documenté, ce qui laisse un doute et me fait penser à un bug... ManuD 20:38, 21 June 2010 (UTC)
- J'ai lu quelque part (je cherche où) que wall=no serai pour les construction apparaissant en jaune claire sur le cadastre. Ce zone étant soit des sous-sol, soit des construction qui n'ont pas 4 mur et un toit. Ce tag serait temporaire, en attendant qu'un tag plus adapté soit trouvé. De mon coté, j'ai quand même une majorité de bâtiment sans ce tag. Le script marche bien chez moi. Keuronde 23:05, 24 Août 2010 (UTC+1)
Les scripts d'importation ne fonctionne pas chez moi, le pdf créé fait 2Mo et est vide, j'ai testé pour Aubagne(13), Gemenos(13) et Caderousse(84), quelqu'un peut me le confirmer ? Elianel 16:44, 28 Juillet 2010
n'est t'il pas possible de créer des fichiers osm par quartier pour les grandes villes ? Le fichier complet est assez lourd à charger dans josm et ça faciliterait la gestion de ce qui est fait ou non. --Christouf 09:42, 4 August 2010 (BST)
Contents |
Code cassé?
Bonjour, Je crois que le code est cassé, j'ai essayé avec l'exemple donné : sh import-bati.sh 085 "GARNACHE (LA)" ImportCadastre RGF93CC47 , cela me donne des fichiers osm presque vides (il n'y a que le cadre, pas de contenu) La ville est bien sur un cadastre vectorisé... Les fichiers pdf et svg ne sont pas vides. Il y a également ce message d'erreur: $ bash import-bati.sh 085 "GARNACHE (LA)" ImportCadastre RGF93CC47 CODE=W1096 BB=1326828.51 6195887.04 1339055.01 6203805.61 Warning: Use of "shift" without parentheses is ambiguous at svg-parser.pl line 112.
Plus de détails ici : http://dl.free.fr/vTtvPANYn --Julien_N 14:48, 21 Novembre 2010 (UTC+1)
- Même souci pour moi avec le même message d'erreur suivi de RuntimeError libproj.so: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce type
- greteck 05 Décembre 2010
- Je ne peux que confirmer un problème d'utilisation des scripts d'import.Je travaille sur un PC avec une version d'Ubuntu 10.10 à jour. L'installation des prérequis s'est apparemment bien passé. J'utilise bien le shell BASH.J'ai choisi deux communes de haute-garonne (après avoir lu que les communes dont le nom comprenait des espaces pouvait poser problème sur [1])
- L ISLE-EN-DODON et BOULOC
- L'exécution du script d'import ne me fournit pas autre chose que des fichiers osm de quelques octets.
- J'ai le même message que donné précédemment : Warning: Use of "shift" without parentheses is ambiguous at svg-parser.pl line 112
- Il manque un contact ou une adresse pour remonter les bugs dans le script à défaut je poste ici
- --Laurent 10:56, 9 December 2010 (UTC)
- J'ai le message d'erreur suivant en exécutant "import-bati.sh 031 "TOULOUSE" toulouse RGF93CC43":
- 'RuntimeError OGR Error: Corrupt data
- Je suis sous Debian Lenny avec la lib gdal-1.7.3 installée manuellement pour contourner le message d'erreur "Can't locate auto/Geo/OSR/SpatialReference/create.al"
- --Don-vip 21:48, 17 December 2010 (UTC)
- En attendant que le problème soit résolu, les fichiers osm des imports sont disponibles sur http://osm.cquest.org/bati/
- greteck 02 Janvier 2011
- Merci ! jusqu'à présent je me basais sur les fichiers fournis ici (qui ont réactualisés aujourd'hui d'ailleurs: http://osm.cleo-carto.org/cadastre) mais certaines communes ne sont toujours pas générées correctement sur ce site alors que sur le tien, oui :)
- --Don-vip 19:16, 2 January 2011 (UTC)
Argument IGNF
Dans la mesure où l'on précise le département, l'argument IGNF ne pourrait-il pas devenir optionnel ? (Vu qu'on peut la déduire du département).--Don-vip 20:09, 17 December 2010 (UTC)
- A priori non, car IGNF dépend aussi du type de projection utilisée. --Dave92 18:12, 12 March 2011 (UTC)
Petit bug du script import-bati.sh
Le script import-bati.sh invoque curl sous la forme curl options >fichier, ce qui peut ne pas fonctionner selon la configuration de curl. Utiliser l'argument standard -o fichier corrige ce défaut. --Dave92 18:21, 12 March 2011 (UTC)
Ajout de précision sur la partie correspondant aux cours d'eau
C'est une très bonne chose de pouvoir importer les bords des cours d'eau directement à partir du cadastre, mais il n'est à aucun endroit fait mention qu'un waterway=riverbank DOIT obligatoirement comporter un tracé du flux du cour d'eau, et ce, dans le sens d'écoulement comme c'est indiqué sur la page correspondante. Est-ce qu'il ne serait pas utile, voire indispensable de l'indiquer dans la partie traitant de leur import à partir de l'extraction du cadastre ? -- Lolo 32 20:14, 14 May 2011 (BST)
