Talk:France/Cadastre/Import semi-automatique des bâtiments

From OpenStreetMap Wiki
Jump to navigation Jump to search

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)

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)

Tout à fait exact (et ajouté) : je l'ignorais et me suis fais piéger. Corrections en cours en Corrèze.--Pantoine 13:55, 9 January 2013 (UTC)

Reverted edits by Pieren

I just reverted some changes by Pieren. Separate accounts for imports have long a best practise principal in OSM.

Example of accounts I own for imports: http://www.openstreetmap.org/user/Coastlines-RJB , http://www.openstreetmap.org/user/Coastline%20Southern%20Africa (coastline had lots of manual cleanup work from the account)

Account which were originally a personal account, but then renamed due to primarily being imports: http://www.openstreetmap.org/user/DaveHansenTiger --Firefishy 12:53, 25 September 2012 (BST)

Pieren did annouce his change of the wiki on our talk-fr list, no complains were raised, and some did accept that this change was written to the wiki in order to clarify what the situation is, and help avoid missunderstandings. Therefore, I oppose the revert you've done about an edit that was accepted by those who use this page.
Your explanation for your revert is inacurate for this specific import. We have had a long best practise of not using a seperate account, and I find pieren's advice and clarification more than apropriate on this page.
The fact that you, personnaly, use a dedicated account for whatever import is imho irrelevent in this case.
I don't want to avoid discussion, wich is currently ongoing both at the french community and at the DWG, but during the mean time, please at least let us explain to our community member what is the current status sletuffe 14:18, 25 September 2012 (BST)
Well. The separate account has been long discussed on the main list last week. We are looking for an agreement with the DWG that the French community will take in charge the French Cadastre import policing himself. My message is not about ALL imports. We accept the "separate account requirement" for appropriate imports. --Pieren 14:25, 25 September 2012 (BST)
And you add that what you say "long best practice" was long a 'recommendation' until the DWG has unilaterally decided that is now a requirement.--Pieren 14:33, 25 September 2012 (BST)
"Separate accounts for imports have long a best practise principal in OSM." OK but integration of french cadastre is NOT an import. So I will never use a separate account for that. Final point for me ! --Ptigrouick 16:29, 25 September 2012 (BST)
Ptigrouick.... "Je ne crois pas qu'on puisse dire que ça n'est pas un import. 99.99% des données ne sont pas affectées par l'intégration. C'est donc bien essentiellement un import. De plus, nombreux sont ceux qui ne corrigent pas les artefacts qui ne sont pas signalés par le Validator de JOSM comme le bâti découpé par des parcelles (sans parler des recouvrements)." (via talk-fr) --Firefishy 17:00, 25 September 2012 (BST)
Firefishy... thanks for taking time to discuss that matter with us, and sorry for beeing a bull at almost starting an edit war with you. I over-reacted, but I think that's what you did as well. Changes on that part of the wiki should probably better be discussed first before done.
For Pieren who wrote the first text, may I suggest, now that we hopefully have all cooled down to re-word a bit the text in order to make it more diplomatic and avoid unecessary blood shed ? I'll be discussing that matter on the talk-fr list. sletuffe 18:09, 25 September 2012 (BST)

Just to make this clear: The current import guidelines require a separate account for imports and they have not been amended or replaced. DWG is happy to work with the French community on resolving this but it will take time and until the matter is resolved, the current import guidelines remain in force. This means that DWG will politely request (at least large-scale) Cadastre importers to create a separate account and might block them if they do not comply. I will not start an edit war with you over this wiki page but I think it is perhaps unwise to instrumentalise a French newcomer who wants to do everything right by telling them that a separate account is not necessary and then they're surprised if they get a DWG email. Just saying. --Frederik Ramm 23:59, 25 September 2012 (BST)

As it seems common on this topic, people are talking about things they don't understand. Just before the suggested reply template, I'm writing "Ceux qui veulent suivre cette recommandation du compte séparé peuvent bien-sûr le faire s'ils le souhaitent." which can be translated by "For those who want to follow the recommendation of the separated account can do it if they wish, of course." --Pieren 13:26, 26 September 2012 (BST)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:France/Cadastre/Import_semi-automatique_des_bâtiments&oldid=1897875"