Le portail francophone de la géomatique

bravo !!

bonjour PY,

je trouve l'initiative vraiment remarquable et ce doit être l'un des seuls documents techniques qui existe sur le net abordant la numérisation des docus d'urba de A à Z.

C'est un grand pas qui servira à beaucoup de monde, je pense.

En plus c'est très bien illustré. Il y a un diagramme très clair.

Histoire de participer un peu au sujet et de recueillir également des avis.

La piste qui a été commencée est particulièrement intéressante car elle fait la part belle aux outils opensource. Tu t'es lancé dans une description fine de la méthode que l'on pourrait qualifier aussi d'opensource en cela qu'elle fournit gratuitement à n'importe qui la procédure opérationnelle alors que la prestation qui en résulte sera paradoxalement bien souvent payante.

Malgré la forte composante opensource, tu mentionnes un logiciel propriétaire appelé FME pour convertir un EDIGEO en SHP. Cela est peut-être possible de convertir avec OGR?

Par contre, je n'ai pas trouvé de méthode utilisant un outil opensource pour transformer un fichier DWG en SHP. Les logiciels existent mais je n'ai jamais réussi à en faire fonctionner. La méthode consiste d'abord à transformer le DWG en DXF puis de transformer avec OGR/QGIS le DXF en SHP. A voir. C'est top si FME le fait. Ce dernier est un très bon outil, de toute façon.

La vérification de la projection peut sans doute se faire sur la base du fichier ESRI obtenu et en ajoutant les couches de la commune concernée sous différents systèmes de projection afin de voir avec laquelle de ces dernières la couche shape se superpose.

Aussi, tu parles de prendre une photo du plan. Si on a un scanner A0, on peut le scanner. Certes, les scanners A0 sont chers mais j'en recommande fortement l'achat. L'image sera alors très peu déformée et pourra être géoréférencée, ce qui exclut le modèle externe.

Tu n'as pas mentionné la méthode employée pour le géoréférencement. Laquelle t'a semblée la plus appropriée? Polynomiale de quel niveau?

Concernant la structure de la table et la sémiologie, est-elle le fruit d'une réflexion interne? Il existe un guide de la numérisation produit par le CNIG (Conseil National de l'IG) avec un certain nombre de préconisations, que chacun est libre de suivre ou pas, mais cela a le mérite de pouvoir échanger avec les services de l'Etat qui appliquent ce cahier des charges. Le guide est dispo sur le net.

Perso, dans la table, en plus du code INSEE, je rajouterais également le nom de la commune afin d'éviter à l'utilisateur le report à une table externe de correspondance.

baobazz > merci pour ta participation.

Effectivement, j'ai utilisé FME car j'en avais la possibilité au travail. Et outre le fait qu'il est très puissant en matière de reprojection, il excelle aussi en transformation de formats de fichier. Et pour bien d'autres opérations, mais je n'en suis pas là niveau utilisation et maîtrise de la bête.
En tout cas, je n'ai pas connaissance d'un outil opensource qui puisse effectuer les transfos EDIGEO > SHP ou DWG > SHP en reprojetant si besoin en L93.

J'avais testé DraftSight comme clone d'AutoCAD, mais je ne me rappelle pas avoir la possibilité d'exporter en .shp ou autre format d'export répandu.

S'il est possible de convertir avec OGR, ce serait vraiment chouette cela dit. (Si Yves est dans le coin, peut-être aura-t-il plus d'infos à ce sujet).


Concernant la photo du plan, il est clair qu'avoir un scanner A0 à disposition est fort utile. Ce n'était pas mon cas, mais j'ai tout de même pu géoréférencer une photo de Carte Communale avec cette méthode un peu cavalière.

Pour préciser d'ailleurs ma méthode de calage, j'ai utilisé la transformation "Helmert" (testée est approuvée sur Star-APIC quelques temps auparavant), et la méthode de ré-échantillonage de "Plus proche voisin". Je n'ai pas souhaité poussé plus avant les tests en géoréférencement, car elle dévore suffisamment de temps pour ne pas trop s'y attarder.
(pour info, le géoréférecement d'une commune moyenne me prend un bon après-midi) Et il est primordial d'avoir un PDF d'une seule page (il est assez courant que les BE vous envoie un PDF en 2 pages, voire plus...et c'est juste impossible à géoréférencer correctement...). J'avais tenté de recoller les 2 pages d'un PDF, mais le rendu du GéoTIFF résultant était bien pourri, déformé....

Concernant la structure de la table, je comptais la mettre prochainement à disposition en .shp, J'avais repris le travail proposé par la DDTM 29 qui se basait sur le cahier des charges du CNIG.
Elle contient bien un champs COMMUNE d'ailleurs.

La liste des champs :

[img]http://uppix.net/7/0/8/24c6355089a47bd36b9f4c559e432.png[/img]

(voir sur le site de la DDTM 29 pour le PDF explicatif des différents champs)



Et merci encore pour ta proposition de traitement sur GRASS, baobazz, je testerai ça à mon retour de congé.

Dernière modification par PY.map (Fri 14 October 2011 09:37)

Bonjour,

On peut ouvrir de l'EDIGEO directement dans Qgis mais il faut la version 1.9 en développement de Gdal... Compilation de Gdal et Qgis sans doute nécessaire...

Voir ce message : http://georezo.net/forum/viewtopic.php?id=71750

Yohan

Du beau boulot, et c'est surtout super de le partager. Un wiki aiderait à le faire progresser ensemble.
---
Sur Edigeo vers shp, le logiciel de Michel Wurtz s'appelle edi2mif (par ex surhttp://adullact.net/projects/edi2mif/ ) : il fait du mif/mid qu'on peut ensuite convertir en shp facilement.
---
Sur la méthode : elle ne mentionne que l'utilisation des couches parcelles et bâti du cadastre. Il est pourtant très souhaitable d'utiliser aussi la couche des subdivisions de parcelles, car des limites de zones qui paraissent passer "en plein champ" sur la seule couche parcelles suivent en fait ces limites de subdivisions (par exemple dans le Finistère on a en gros 1 subdivision pour 7 parcelles : ce n'est pas négligeable)
---
La DDTM29 est mentionnée comme source pour la structure, mais nous avons maintenant adopté le standard Covadis (intégralement mais avec des champs complémentaires en interne). cf http://www.cnig.gouv.fr/Front/index.php?RID=120
---
Sur le calage des images, je suis surpris des 100 à 400 points de calage préconisés. Quand nous travaillons avec des PLU sur plusieurs planches (une centaine de communes ont été traitées ainsi), nous les mosaïquons avec seulement une vingtaine de points de calage par planche, et en prendre le double ou le triple ne nous a pas donné l'impression d'améliorer le résultat. Mais notre logiciel n'a pas la transformation d'Helmert, seulement du polynomial cubique (>10GCP), c'est peut-être ça. Quand l'original est déformé (certains BE semblent tasser les données pour que ça tienne dans les A0 !), c'est irrattrapable, quand c'est ok, on a des résidus < 5m à partir de scan, parfois <2m à partir de pdf.

le lien vers le document du premier message est mort...je serai très intéressé de pouvoir le récupérer s'il est encore disponible.

Je vous remercie.

bonjour,

le serveur répond :
Your PHP installation appears to be missing the MySQL extension which is required by WordPress.

quelqu'un aurait-il un lien valide vers le document ?