Le portail francophone de la géomatique

Salut,

Il m'arrive parfois de faire cette opération pour deux ou trois sections, par contre je travail sur Arcgis qui à l'avantage de bien gérer les reprojection tordues.

En gros la procédure:
-un peu de nettoyage avec GIMP
-calage avec l'aide de Geoportail
-rectification (en choisissant l'algo cubic c'est plus propre)
-reclassification pour rendre le fond blanc transparent
-création d'une mosaïque

Je ne connais pas bien QGIS mais je sais qu'ouvrir des rasters non rectifiés donne parfois des résultats foireux. Je pense que l'idéal serait de pouvoir déjà remettre le nord dans le bon sens avec GIMP ou autre. Si ta planche possède les accroches d'un quadrillage ça peut te donner une idée de l'angle à appliquer sinon en partant du postulat qu'il s'agit d'un nombre entier il y a peut être moyen de le déduire de façon empirique.

A mon avis laisse tomber l'assemblage manuellement c'est trop foireux.

Pour le système de projection, s'il y en a un c'est forcément du Lambert Zone, le mieux est donc de travailler dans ce système quitte à faire une reprojection par la suite. Quand toute les dalles seront calées tu pourras envisager la mosaïque avec GDAL par exemple.

Pour ce qui est de la vectorisation auto, tu peux t'orienter vers cette excellent soft pour avoir un aperçu du résultat. Il existe effectivement des outils pour géoréférencer des données vectorielles, j'imagine que QGIS a un petit plugin pour ça, mais je craint (surtout avec ces veilles planches) que le travail de correction/nettoyage soit pratiquement aussi important que de tout vectoriser manuellement.

C'est une méthode bien adaptée quand on ne recherche pas la précision. Par exemple, je le fais pour me donner une idée du morcellement parcellaire d'un territoire mais si je veux un beau cadastre topologiquement correct et avec une table attributaire alors j'utilise plutôt ma mimine.

Est-il possible d'avoir le nom de la commune pour se faire une idée?

En effet, je pense que ça pourrait être un premier flux opératoire à tester.

La rectification, c'est un peu comme la reprojection. Quand on reprojete on transforme un raster de son système de projection initial vers un autre, ce qui revient grosso modo à recalculer la nouvelle position de chaque pixel dans l'image.

Ce que j'appelle la rectification c'est quand le fichier de calage d'un raster indique qu'une rotation sera nécessaire et/ou que les résolutions en x et y sont différentes. Comme pour la reprojection, il faut  recalculer la position des pixels pour obtenir une image droite et fixer la résolution, mais cette fois il n'y a pas de changement de projection.

Il y plusieurs algorithmes applicables pour ces opérations par défaut il s'agit généralement du "plus proche voisin". Le problème est que cette algo donne des effets de décrochage pas très beau d'où l'intérêt d'utiliser le cubic. On en parle un peu ici et ici.

Le reclassification c'est le fait par exemple de regrouper des intervalles de valeur pixel en leur attribuant une nouvelle radiomètrie. Dans notre cas, il faudrait indiquer que la valeur 255 (blanc) sera NoData (transparent). Je crois que GRASS permet de faire de la reclassification raster mais tu auras aussi vite fait avec GIMP --> menu calque/transparence/couleur vers alpha.

Ce que je ne sais pas, c'est si GDAL prendra bien en compte la transparence pour créer la mosaïque. C'est primordiale car tes images ne seront pas parfaitement jointives et donc, comme il y aura des recouvrements, la transparence permettra d'éviter que le fond blanc de l'image du dessus recouvre celle du dessous.

La version pro non plus je pense. Quel que soit l'outil utilisé tu obtiendras forcement des polylignes dans un premier temps. Recréer les polygones c'est une tout autre histoire et il y a du fil à retordre.

Au passage, ce qui est bien pratique avec Wintopo c'est que si le raster est géoréférencé alors on peut directement sortir un shapefile aux bonnes coordonnées.

Mais, le problème de la vectorisation auto c'est qu'on se retrouve avec une topologie en spaghettis : il n'y a pas forcement un nœud à chaque intersection, des régions qui semblent en apparence fermées ne le sont pas, certains objets seront de longueur nulle... Sans compter les portions où la détection des lignes est incorrecte (si le trait est trop fin on a une coupure, s'il est trop épais le vecteur prend une mauvaise orientation, au niveau d'un angle aigu l'amas de pixels en nuance de gris est nuisible...)

C'est ce nettoyage là qui prend beaucoup de temps, surtout qu'il n'y a pas de recette miracle, seulement de la bidouille :
-le thinning pour réduire les traits épais
-l'outil seuil dans GIMP qui permet d'éliminer une partie des nuance de gris pour affiner un peu les pâtés de pixel
-scinder les polylignes à chaque intersection
-snaper les nœuds libres...

Il y a beaucoup d'axes à explorer et tester, à toi de déterminer l'enchainement le plus adapté à ce que tu attends. Tu peux t'orienter vers les outils de correction topologique et de nettoyage de GRASS. Pour la création des polygones j'avais eu de bons résulats avec QGIS+GRASS (module v.type.lb) et OpenJump.

Mais saches qu'à la fin on se retrouve souvent à devoir corriger la couche à la main...

Tiens nous au courant de l'avancée de tes travaux !

Dernière modification par dominique.lys (Mon 26 April 2010 10:36)

Comme le sujet m'intéresse j'ai fait quelques tests avec QGIS et GDAL. Je joins un petit topo en annexe.

En espérant que ça aide.

Dernière modification par dominique.lys (Mon 26 April 2010 23:49)

pour info un outil a été développé sous TopoCad pour réaliser ce genre de manipulation (avec fichiers de géoréférencement ou à partir des orthophotos) cf http://www.youtube.com/user/TopoCadFrance#p/u

Merci beaucoup, sympa le petit tuto illustré...

Par contre, je rencontre quelques divergances avec mes TIF : il n'y a aucun calque transparent sous GIMP, le fond est déjà "blanc".

Sinon je rencontre quelques problèmes avec FwTools

Traceback <most recent call last>:
   File "C:\PROGRA1\FWTOOL1.7\bin\gdal_merge.py", line 463, in ? sys.exit<main<>>
   File "C:\PROGRA1\FWTOOL1.7\bin\gdal_merge.py", line 433, in main if quiet == 0 and verbose == 0;
UnboundLocalError: local variable 'quiet' referenced before assignment

-> un petit tour rapide sur le web et voici ce qui est proposé pour résoudre ces problèmes :
     - "You can workaround this by specifying the -q or -v flags. " : je connais pas !?!
     - mettre à jour gdal_merge.py avec un nouveau fichier (<a href="http://trac.osgeo.org/gdal/browser/branches/1.7/gdal/swig/python/scripts/gdal_merge.py?format=raw">Ici</a>) : lorsque je lance ma commande un 0 apparaît, FwTools semble bloqué...

Le résultat pour l'instant : un TIF d'environ 515mo entièrement blanc (ou noir avec la seconde manip).

Je suis sur windows, peut être est un problème de configuration ? Je parcours Osgeo4w mais rien ne semble manquer...

Effectivement, certainement un problème de compatibilité de versions.. Demain on teste gdal_merge sous ubuntu !

Pour revenir à l'assemblage avec gdal_merge : mes TIFF initiaux pèsent en moyenne 1mo (pour 12000 / 8000 pixels) ; 5 sections sont à assembler pour obtenir la mosaïque finale ; lorsque je lance l'opération le poids du fichier crée augmente encore et encore (il a atteint 60go au bout de 45 minutes et semblait vouloir encore augmenter, mais plus de place dans l'ordi !!) C'est embêtant ! J'ai donc aussi testé d'assembler seulement 2 sections mais même problème le fichier crée atteint le même volume. Et pis d'abord, comment ca fonctionne gdal_merge ?

Je me demande si digitaliser une section une par une pour rassembler le tout sous une même couche vecteur ne serait pas une solution échappatoire (les tif sont désormais caler, mon travail final consistera de toute façon à vectoriser les parcelles d'intérêts), mais, étant grand débutant, je n'ai jamais réaliser ce genre de manipulation (difficultés, temps, moyen techniquement avec les sig libre...). Je reste donc ouvert à toutes propositions et tout apport d'informations à ce sujet !

Merci à tous (et à Thomas !) pour vos réponses !

Voilà la méthode finalement employée : d'abord un gdalbuildvrt avec -srcdata 0 (0 étant mon blanc à "gommer")... puis un gdal_translate pour réassembler le tout avec un -op "compress=lzw" pour comprimer l'assemblage (environ 25mo au lieu d'1go). Puis découpe automatique de l'assemblage avec création d'un shapefile "tuile" avec gdal_retile (possible de garder la compression en lzw).