[OSM-talk-fr] Fichiers bâti cadastral (était: "Restreignons les imports des cours d'eau")

Pieren pieren3 at gmail.com
Lun 1 Oct 12:03:37 UTC 2012


2012/10/1 Christophe Merlet <redfox at redfoxcenter.org>:
> Je ne vois pas en quoi être identifié pour télécharger certain fichier
> du cadastre va responsabiliser ceux qui travaille comme des porcs alors
> qu'ils sont déjà identifié dans OSM.

Je suis assez d'accord avec ça. Ajouter une barrière au téléchargement
ne règlera pas le problème des imports mal préparés.
Je propose une autre piste (dans la série "y-a-ka, fô-kon):
- suspendre la génération des fichiers bâti jusqu'à ce que soit mis à
disposition une version améliorée qui supprimerait 2 des principaux
problèmes actuels:
- éliminer autant que possible les "recouvrements". D'après ce que
j'ai compris, un script existe déjà quelque part (signalé sur cette
liste) mais il faudrait l'appliquer avant import et pas après. Ce
qu'il ne peut corriger de manière automatique devrait être signalé par
un tag, genre "fixme:cadastre=corrige moi puis supprime le tag". Il
serait ensuite facile de repérer ceux qui font des uploads sans avoir
corriger les problèmes de recouvrements.
- éliminer les segmentations intérieures au bâtiment. Je vais
peut-être me faire taper sur les doigts mais j'ai toujours été
sceptique sur les données "indoor" fournies par le cadastre. C'est
souvent fantaisiste ou ne correspond qu'à un seul étage. Ca n'est pas
vérifiable. Ca n'est pas taggué correctement si c'est des pièces
intérieures (room=*). Je parle bien sûr des polygones de même type et
de petite taille qui pourraient être facilement fusionnés pour qu'ils
correspondent mieux à un polygone par adresse (ou par parcelle
puisqu'on ne connait pas la couverture d'une adresse). Cela n'élimine
pas tous les problèmes (notamment les découpages de parcelles qui
passent au milieu des maisons) mais déjà on réduirait le nombre de
petits polygones qui font moins de 6 ou 7 mètres carré comme signalé
par pnorman dans son étude statistique (il ne dit pas que des
bêtises).

Pour finir, il faudrait lancer une réflexion sur le tag "source" et la
taille considérable qu'il prend dans la base de donnée. Ja'i pensé à
un tag spécial ("source_id" par ex.) qui utiliserait une valeur
réservée. La valeur réservée serait par exemple un chiffre qui serait
renseigné sur une page protégée du site osm.org
(http://www.openstreetmap.org/credits). Il serait utilisable pour
toutes les sources externes en général. L'ajout de nouvelles valeurs
devrait être relativement aisé et ouvert mais pas les modifications
sur des valeurs déjà utilisées. Par exemple source_id=22 où
22="cadastre blabla, année 2012". C'est une façon de faire un peu du
"foreign key" sans modifier la structure de la base de donnée mais qui
permettrait d'économiser des gigaoctets en disque et bande passante
chez beaucoup de monde. Bien-sûr, on ne pourrait empêcher l'altération
du tag ou sa suppression comme tous les autres tags mais il serait
dans l'historique, ce qui nous fait respecter la clause de la dgfip.
Bon, cette idée nécessiterait une discussion à une autre échelle que
la notre mais vous en pensez quoi ?

Pieren




Plus d'informations sur la liste de diffusion Talk-fr