[FWTools 1.2] Vue d'ensemble

[Grob]

Une partie des infos est traduite depuis la page officielle des FWTools du site de Maptools, qui recense des outils gratuits open source notamment.

FWTools: Kit SIG Open source pour Windows et Linux

FWTools est un set d'outils Open source pour les systems windows (Win32) et Linux(x86 32bit) créé par Frank Warmerdam (d'où la mention FW...).
C'est un kit très simple sans code source à bidouiller ni rien à compiler. Le package Linux est agnostique, c'est à dire qu'il ne tourne pas sous un system en particulier.

Installation sous Windows très simple :
* On télécharge le package ici On double clique et l'install se lance.
* Il va créer un répertoire avec notamment un fichier appellé openev.bat. C'est celui là qui va lancer le logiciel OpenEV qui gère les autres composants.

Voici à quoi ca doit ressembler quand on double clique sur openev.bat :



FWTools contient les outils (=tools) suivants :

# MapServer : soft de cartographie web.

# GDAL/OGR: une librairie et un utilitaire de lignes de commandes pour lire et écrire des formats raster (gdal) et vecteur (ogr).

# PROJ.4 : une librairie de projections internationales avec un utilitaire de lignes de commandes. C'est le même package qu'on peut retrouver dans GRASS par exemple.

# OGDI: un utilitaire de lecture de nombreux formats raster et vecteurs, notamment sur les formats militaires. Par exemple : VPF (ie. VMAP, VITD), RPF (ie. CADRG, CIB), et ADRG.

# Python: un langage de scripts, qui permet de lancer des batch, (commandes répétitives)

et quelques composants supplémentaires.

A suivre...

[Le Docteur]

Grob pour ce topic

[HotShot]

Ajoutons que :
- on peut utiliser chaque composant isolément, sans passer par OpenEV. Pratique quand on a juste un fichier à convertir.
- des bindings sont fournis pour divers langages de programmation (python, C...) donc facile de programmer "par dessus".

[Grob]

GDAL (dans le pack FWTools) Option PCT2RGB/RGB2PCT : un exemple d'utilisation
(inspiré de la réponse de HotShot dans ce topic)

Problème : lors de l'assemblage de TIFF (dalles de SCAN25 IGN) avec gdal_merge on obtient un résultat aux couleurs incertaines et floues.

Explication : certaines dalles n'ont pas la même palette, par exemple le noir est affublé du code "0" dans une dalle, il a le code "42" dans une autre, alors qu'elles semblent avoir exactement les mêmes couleurs. Dire à gdal_merge d'utiliser la palette de la première image (le "- pct") pour toutes les autres, ça donne des pixels avec la mauvaise couleur, sur certaines dalles.

Solution :

1. Utilisation de PCT2RGB

Convertir toutes les dalles en couleurs "non-palette", donc codées en valeurs de RougeVertBleu, donc 3*8=24 bits avec l'outil "pct2rgb" de FWTools. On récupère autant de dalles, mais en mode "millions de couleurs", et chacune trois fois plus lourde. Ensuite, on utilise gdal_merge (sans l'option "-pct" cette fois, bien sûr), et on récupèrera un assemblage -lourd- en millions de couleurs.

2. Utilisation de RGB2PCT

On peut ramene à un assemblage plus léger en mode "palette" grace à l'utilitaire inverse, "rgb2pct".
En quelques lignes de commandes, il y a moyen d'automatiser l'opération.

Attention :

Là où ça coince, c'est que si l'opération pct2rgb se fait sans perte (les couleurs ne changent pas), l'opération inverse rgb2pct devra probablement "faire des choix" pas toujours parfaits, pour ramener tout ça à une palette de 256 couleurs maxi. Et il y a donc un risque que les couleurs finales ne soient pas exactement identiques à celles des dalles d'origine fournies par l'IGN. Donc à chacun de voir si cette dégradation éventuelle est gênante.

-> Une autre option est d'attribuer dès le départ une "même" palette (= mêmes couleurs avec les mêmes codes dans le même ordre) à toutes les dalles IGN ; par exemple sous Photoshop ou tout autre logiciel de traitement d'images.

Ensuite, et pour peu qu'on ait pris soin de sauver les infos de géoréférencement (génération des .tfw avant de retoucher l'image) pas de souci pour assembler.

[HotShot]

Perso, je suis sous Windows et n'utilise pas OpenEV - l'interface est pas géniale, et n'a pas vraiment d'utilité si on souhaite juste manipuler des données (assembler, reprojeter, modifier des métadonnées...)

Petit topo vite fait sur les divers outils disponibles dans FWTools...

● gdal_translate :

- convertir entre formats : jpg vers tif, png vers ecw, etc.
- ajouter des informations à un fichier : projection, référencement, métadonnées...
- extraire une petite partie d'un fichier

Tout ça peut être combiné en une seule et même opération.


● gdalwarp :

- reprojeter un raster : Lambert II vers Lambert 93, p.ex.
- redimensionner un raster : passer de 2.5m/px à 1m/px en interpolation bilinéaire etc.
- assembler des fichiers : par exemple regrouper plusieurs petites dalles en une grosse.

Tout ça peut être combiné en une seule et même opération.


● gdal_merge :

- assembler des fichiers : tout comme gdalwarp, plus rapide mais moins d'options

Commode si on est dans un cas de figure "idéal" : par exemple 50 dalles déjà correctement référencées, toutes à la même résolution, avec une même palette de couleurs. Ou encore, 7 bandes spectrales Landsat séparées à réunir dans un même fichier.


● rgb2pct et rgb2pct :

- transformer un raster 256 couleurs en 24 bits... et réciproquement.

Sachant que l'opération rgb2pct peut induire une perte de qualité ("chausse-pied" un peu bourrin pour ramener des millions de couleurs à seulement 256...)


● gdalinfo :

- obtenir des infos sur GDAL : version, formats disponibles...
- obtenir des infos sur un format : options possibles, écriture et/ou lecture seulement...
- obtenir des infos sur un fichier : caractéristiques du raster, géoréférencement, métadonnées...

Autres choses à savoir :

- en interne, gdal utilise souvent le format GeoTiff, en raison de sa puissance et de sa versatilité pour tout ce qui touche aux SIG. Il est souple et gère bien les métadonnées géographiques ou non.
Si on ne précise pas, celui-ci sera utilisé par défaut. Cela impose quelques limitations inhérentes au format tiff : pas plus de 4 Go de données etc. Heureusement il est possible de ruser ou employer un autre format non limité en taille, tel que le hfa d'Erdas Imagine, ou bil+hdr de chez ENVI

- certains formats ne peuvent pas être écrits directement, pour des raisons spécifiques d'accès lecture/écriture. Notamment les formats compressés.
Ainsi pour reprojeter des dalles et les enregistrer en ecw, il faudra générer un GeoTiff (gdalwarp) avant de le convertir en ecw (gdal_translate).

- l'accès aux données se fait en mode "direct" donc on peut traiter des fichiers énormes de plusieurs dizaines de Go (ou plusieurs milliers de fichiers) en une seule opération, même avec peu de RAM, et très rapidement.

- on est parfois limité par le fonctionnement en ligne de commandes "MS-DOS" : il est bon de savoir un minimum se débrouiller, se déplacer dans les répertoires, penser à indiquer les noms de fichiers longs entre guillemets, etc.
Par ailleurs il y a une limite au nombre d'options et/ou de noms de fichiers qu'on peut entrer en une seule fois (~100, de mémoire) - ça peut être gênant pour mosaïquer 5000 fichiers... D'autant que la plupart des utilitaires gdal ne supportent pas les caractères génériques du style "*.tif"
Heureusement il y a diverses astuces possibles... =)


Quelques exemples de commandes :

● Reprojeter une vieille orthophoto dans le nouveau système Lambert 93:

gdalwarp -s_srs EPSG:27572 -t_srs EPSG:2154 -tps -rc -tr 0.5 0.5 -of GTiff -co COMPRESS=DEFLATE "E:\Mes vieilles orthophotos\OrthoLambert2.ecw" "C:\Bureau\OrthoLambert93.tif"

Options dans l'ordre :
-s_srs projection d'origine (code epsg du Lambert II étendu) ;
-t_srs nouvelle projection désirée (ici, Lambert 93) ;
-tps algorithme de reprojection Thin Plate Spline ;
-rc rééchantillonnage Bicubique des pixels ;
-tr 0.5 0.5 résolution de destination 0.5m/px et 0.5m/px (en x et en y) ;
-of Gtiff générer un nouveau fichier au format GeoTiff ;
-co COMPRESS=DEFLATE le générer avec une compression sans perte 'Deflate' ;
"E:\..." fichier d'origine (une dalle ecw) ;
"C:\..." nouveau fichier reprojeté qui sera créé

● Reconvertir cette orthophoto en ECW correctement géoréférencé :

gdal_translate -of ECW -co TARGET=90 "C:\Bureau\OrthoLambert93.tif" "C:\Bureau\OrthoLambert93Compressée.ecw"

Options dans l'ordre (voir l'exemple précédent...)
- générer un fichier ecw ;
- compresser à 10:1 (perte de 90% de son poids, merci Slim-Fast) ;
- fichier source ;
- fichier de destination qui sera créé
Dans cet exemple, le géoréférencement étant déjà inscrit dans le fichier .tif (suite à l'étape Gdalwarp), le programme va transmettre automatiquement le géoréférencement au fichier ECW.

● Géoréférencer un fichier quelconque :
Bien sûr il vaut mieux utiliser un format capable de stocker ce géoréférencement ! geotiff, ecw, jpeg2000, ...


1er cas, avec un worldfile existant

gdal_translate -of GTiff -a_srs EPSG:4326 Source.jpg Destination.tif

Ici, on part d'un .jpg et d'un .wld pour réclamer la création d'un fichier geotiff en WGS84 (le code epsg).
GDAL se charge tout seul comme un grand d'utiliser le worldfile, pas besoin de le lui dire.

2eme cas, en précisant l'extension géographique, c-à-d. les latitudes et longitudes min/max

gdal_translate -a_srs ESPG:4326 -a_ullr "-5.0" 50.0 5.0 40.0 Source.jpg Destination.tif

On indique grâce à l'option -a_ullr les coordonnées x et y des deux coins haut-gauche et bas-droit (upper left, lower right) de notre fichier.
L'unité n'a pas à être mentionnée, elle dépend de la projection qu'on peut préciser via -a_srs. J'ai omis le -of GTiff car c'est le format par défaut.
Habitude à prendre : mentionner les nombres négatifs entre guillemets, indiquant qu'il s'agit d'une valeur et non d'une option destinée au programme.

3eme cas en entrant des points de contrôle/d'amer (GCPs)

gdal_translate -gcp 5 100 "-4.3245" 45.50 -gcp 900 555 1.33 44.05 -gcp 201 300 0.00 44.98 Source.jpg SourceAvecGCPs.tif

Via la répétition de l'option -gcp x y X Y on a inclus trois points de contrôle (GCPs) dans notre fichier tiff résultant.
Chacun est défini par la position du pixel dans l'image (colonne, ligne) suivi de la position géographique correspondante (longitude, latitude). Pour autant notre image n'est pas vraiment référencée ! on a oublié d'indiquer la projection, et l'échelle des pixels n'est pas encore calculée

gcps2wld SourceAvecGCPs.tif >SourceAvecGCPs.tfw

Maintenant on dit à GDAL de créer un worldfile dérivé des GCPs de notre tiff

gdal_translate -of GTiff -a_srs EPSG:4326 SourceAvecGCPs.tif DestinationRéférencée.tif

... et pour finir on réintègre (automatiquement) les infos du worldfile dans un nouveau geotiff... en n'oubliant pas d'indiquer la projection de notre fichier, cette fois.

N.B. Il est également possible de nourrir gdalwarp avec notre "geotiff+gcps", si on souhaite redimensionner/reprojeter dans la foulée...

[HotShot]

D'autres outils disponibles dans FWTools

● gdaladdo :

- ajouter des 'overviews' à un fichier

Ce sont des sortes de vignettes de dimensions réduites, incluses dans le fichier (si son format l'autorise, p.ex. GeoTiff) ou externes (extension .ovr ou .rrd)
Pour les tiff uniquement, l'utilitaire addtiffo (librairie libtiff) est également utile.


● gdal_rasterize :

- rasteriser un fichier vectoriel et l'ajouter à un raster existant

Par exemple, on peut ajouter le contour d'une commune (format .shp) à une orthophoto, et masquer en blanc toutes les communes alentour.
Attention cet outil ne fonctionne qu'en mode "surimposition" sur un raster existant.


● gdaltindex :

- créer un catalogue (format shapefile) de rasters

Commode pour gérer ses dalles, et les importer par la suite sous son SIG (attribut 'location' du shp).
Le catalogue peut être complété en plusieurs fois.


● gdal_contour :

- à partir d'un MNT, créer des lignes de niveau en format vectoriel

● listgeo :

- afficher le référencement d'un GeoTiff
- extraire le Worldfile .tfw d'un GeoTiff
- extraire le header geotiff d'un GeoTiff

● testepsg :

- convertir un code EPSG en .prj, .wkt ou paramètres 'proj4'
- transformer des coordonnées d'une projection vers une autre

Pour consulter vite fait ce à quoi correspond précisément un code, ses paramètres etc.


● autres scripts à lancer via python (inclus) :

- gcps2wld, pour calculer un worldfile à partir de points d'amer ('GCPs')
- gdal_vrtmerge, mosaïquer des rasters au sein d'un raster virtuel (vrt) ; très très pratique... mais pas inclus par défaut dans FWTools.

--


Outils vectoriels (librairie OGR)

● ogrinfo :

- afficher des informations sur un fichier vecteur (projection etc.)
- afficher des infos sur certains de ses éléments, via requête type sql
- afficher la liste des formats supportés

C'est un peu l'équivalent de gdalinfo pour tout ce qui est vectoriel


● ogr2ogr :

- convertir entre formats vectoriels
- reprojeter des fichiers vectoriels
- extraire des éléments d'un fichier vectoriel, via requêtes sql

Le cousin vectoriel de gdal_translate et gdalwarp, en somme.


● sortshp :

- trier un fichier shape d'après un attribut du dbf correspondant
(D'autres outils de la librairie shapelib et de mapserver sont disponibles.)

● autres scripts à lancer via python (inclus) :

- gcps2vec, pour convertir des points d'amer en fichier vectoriel

--


Les projections avec GDAL/FWTools

GDAL gère les projections (en attribuer, reprojeter...) grâce à plusieurs systèmes - chacun ayant ses forces et ses faiblesses.
Certains formats ont leur propre façon de faire, et seront plus ou moins bien interprétés par GDAL/OGR, p.ex. les projections des .tab de MapInfo.
Il peut traduire de façon plus ou moins fiable entre les diverses mises en forme...


● Codes EPSG
Le plus simple à utiliser, si on a besoin de projections courantes.

Il suffit de taper "EPSG:" suivi du code. On peut personnaliser *en local* la liste de projections, des plages de codes sont réservées pour ça. Cette liste est juste une grosse bdd.

Avantage ou inconvénient: l'EPSG met régulièrement à jour sa liste de codes, en ajoute, corrige certains paramètres, etc. Penser donc à vérifier la version de la bdd epsg qu'on utilise (aujourd'hui la 6.12) et les éventuelles remarques ou corrections apportées à une projection dont on veut utiliser le code (p.ex. 27582 -> 27572).

Défaut ? certaines projections usuelles mais "non standard" sont absentes (p.ex. le "NTF / Lambert II étendu" avec origine Greenwich).
Pas dramatique non plus.

● Projections Proj4

Une simple suite de paramètres obscurs, entre guillemets. Cela veut dire qu'on peut définir soi-même sa propre projection perso, ajuster certains paramètres etc.

Supporte également les transformations par grille (p.ex. NTF-RGF93...). Hélas, pas (encore) pour les rasters.

Très puissant mais gare aux erreurs, mieux vaut être sûr de son coup...

● OGC Well-Known-Text (WKT)
C'est une façon assez puissante d'écrire les projections "lisiblement".

Un simple assemblage de paramètres plus ou moins imbriqués, dont on renseigne les valeurs... ça ressemble vaguement à du XML. Eventuellement, on peut préciser l'équivalence en code EPSG de chaque paramètre.

Sous GDAL on peut entrer ce style de projection directement en ligne de commandes, ou l'écrire dans un bête fichier texte qu'on appellera par la suite. Très flexible, personnalisable, c'est le style de représentation utilisé dans les rouages de GDAL

● Fichiers ESRI .prj

En fait, c'est tout simplement une version allégée (ou "dégénérée") de WKT ! avec quelques différences mineures au niveau des abréviations employées.

GDAL sait lire dans une certaine mesure les fichiers .prj (par exemple associés aux .shp ou rasters .bil). Il sait également les créer - mais le résultat n'est pas vraiment garanti, pour une utilisation avec les logiciels ESRI...

● Projections style ERMapper

Les logiciels de Earth Resource Inc. utilisent une simple suite de caractères ("LM2FRANC", "NTFPARIS").
GDAL parvient tant bien que mal à faire l'équivalence entre ces "codes" et les divers paramètres dont il a besoin, mais c'est loin d'être parfait !

Il est possible - et souhaitable - de créer sous GDAL les rasters ECW en spécifiant "à la main" les codes ermapper à inclure (pour le Jp2 y a un bug...).

Tout ce qui suit est équivalent (assigne "Lambert-93/RGF93" à un raster)

code EPSG:

-a_srs EPSG:2154

params Proj4:

-a_srs "+proj=lcc +lat_1=49 +lat_2=44 +lat_0=46.5 +lon_0=3 +x_0=700000 +y_0=6600000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"

fichier WKT (-a_srs "C:\MonLambert93.wkt"):

PROJCS["RGF93 / Lambert-93",
    GEOGCS["RGF93",
        DATUM["Reseau_Geodesique_Francais_1993",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6171"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.01745329251994328,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4171"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",49],
    PARAMETER["standard_parallel_2",44],
    PARAMETER["latitude_of_origin",46.5],
    PARAMETER["central_meridian",3],
    PARAMETER["false_easting",700000],
    PARAMETER["false_northing",6600000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","2154"]]

fichier ESRI .PRJ accompagnant un .shp ou .bil:

PROJCS["RGF93_Lambert_93",GEOGCS["GCS_RGF_1993",DATUM["D_RGF_1993",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["standard_parallel_1",49],PARAMETER["standard_parallel_2",44],PARAMETER["latitude_of_origin",46.5],PARAMETER["central_meridian",3],PARAMETER["false_easting",700000],PARAMETER["false_northing",6600000],UNIT["Meter",1]]

options forcées pour la création d'un ECW:

-co PROJ=LMFRAN93 -co DATUM=RGF93

[yjacolin]

Bonjour,

Pour info, une doc sur gdal est en cours de traduction et sera (normalement) disponible prochainement ...

Désolé pour la pub ;-)

Y.

[Grob]

Tant que c'est gratuit...

[HotShot]

Dispo où ? traduite depuis où ?

[yjacolin]

Bonjour,

Sur mon ordi au format OOo. Bientot sur un site ... À suivre (traduc en cours)

Y.

[Grob]

up.. Yves ?

[yjacolin]

bientot, bientot.

Désolé que ca prenne autant de temps ...

Y.

[HotShot]

(signalons la sortie de GDAL 1.4.1 et de Fwtools basé sur le trunk 1.5.0) :o

[Grob]

Merci T'en fais pas Yves, c'était juste un ptit up de derrière les fagots...
Infos sur la release gdal 1.4.1

[yjacolin]

Bonjour,

Envoyé par HotShot

(signalons la sortie de GDAL 1.4.1 et de Fwtools basé sur le trunk 1.5.0) :o

Euh je ne sais pas si FWtool est basé sur le trunk 1.5.0, par contre il y a eut une erreur dans la sortie de la release et si vous avez 1.5.0 qui sort lors d'un gdalinfo -v, vous pouvez retélécherger le paquet et le réinstaller.

Y.