# Les logiciels libres au service de la géomatique

Didier Betored

► To cite this version:

Didier Betored. Les logiciels libres au service de la géomatique. Cahier des Techniques de l'INRA, 2006, 59, pp.5-26. hal-02669201

HAL Id: hal-02669201

https://hal.inrae.fr/hal-02669201v1

Submitted on 4 Sep 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Les logiciels libres au service de la géomatique

Didier Bétored<fnref n="1" />

**Résumé** : Cet article fait un survol relativement exhaustif de l'offre géomatique<fnref n="2" /> libre à ce jour, il présente la globalité d'une démarche et il recense les liens pour se constituer une documentation plus complète dans ce domaine. Il est illustré de captures d'écran réalisées lors de nos travaux.

**Mots clés** : SIG, GRASS, SGBDR, Base de Données, PostgreSQL, logiciels libres

## Introduction

Plus « état de l'art » que véritable application complète, cet article a pour objectif d'ouvrir des perspectives à différents publics d'utilisateurs potentiels même s'ils ne disposent d'aucune base en géomatique. Aux géomaticiens, munis de logiciels commerciaux, je souhaite montrer qu'il existe une autre approche, évolutive et adaptée au contexte « recherche », très sûre et moins onéreuse même si elle est plus « chronophage » au démarrage.

Après avoir décrit l'environnement professionnel et le logiciel, je vais illustrer avec deux exemples dans leur contexte, une autre façon de gérer, d'appréhender et d'exploiter des données dotées de coordonnées.

## 1. Contexte et définitions

### 1.1. Les recherches à l'Unité de Recherches Forestières Méditerranéennes (URFM)<fnref n="3" />

L'objectif général des recherches de l'unité est d'analyser et de modéliser la dynamique des écosystèmes forestiers méditerranéens dans un contexte de changement global.

Six axes de recherche structurent ces travaux :

* Structure, dynamique et fonctionnement écophysiologique des forêts méditerranéennes hétérogènes,

* Evolution de la diversité dans les peuplements forestiers hétérogènes en expansion, impact des processus démographiques et génétiques à différentes échelles spatiales,

* Adaptation et évolution adaptative des espèces forestières face aux contraintes du climat méditerranéen et dans la perspective du changement global,

* Dynamique des populations d'insectes forestiers: insectes séminiphages et leur impact sur les processus de régénération, insectes défoliateurs,

* Modélisation physique du feu, simulations numériques et expérimentales, modélisation du combustible forestier,

* Impact du feu sur la dynamique écologique.

Chaque axe utilise les outils de l'information géographique (analyse de photo aérienne, création ou gestion de données via le SIG ou la Base de Données...).

<footnote n="1">¹ Inra Unité de Recherches Forestières Méditerranéennes URFM- Domaine St Paul 84914 Avignon Cedex 09
04 32 72 29 57 - betored@avignon.inra.fr</footnote>

<footnote n="2">² Géomatique est un néologisme créé à partir des mots géographie et informatique ; c'est l'ensemble des techniques traitant de l'Information Géographique.</footnote>

<footnote n="3">³ http://www.avignon.inra.fr/internet/unites/rfm/version_index_html</footnote>
## 1.2 La cellule SIG-BD<fnref n="4" />

### 1.2.a Ses missions

Depuis juin 2002, l'Unité a consenti un important effort humain, pour le développement d'une cellule SIG - BD dans ses recherches effectuées sur les écosystèmes forestiers.

Celle-ci est un outil de gestion et d'analyse des données géo référencées issues des travaux de l'Unité ou produites par d'autres partenaires, IGN<fnref n="5" />, ONF<fnref n="6" />... Elle permet une intégration cohérente (à diverses échelles) d'informations jusqu'à présent dispersées voire non géoréférencées, elle doit également assurer un rôle d'archivage des données de « références».

Elle apporte une vision à long terme des objectifs poursuivis ainsi que des moyens à mettre en œuvre pour y parvenir.

### 1.2.b Quelques travaux

Au cours de ces dernières années, nous avons travaillé sur différents thèmes :

* la simulation, en vue d'une réalisation sur le terrain, d'éclaircies dans du taillis de chênes verts à Lagnes dans le Vaucluse,

* la colonisation du Luberon par le cèdre (GPS, terrain et photo aérienne),

* la dynamique de différentes espèces (sapin et hêtre) sur le mont Ventoux,

* le suivi d'essais de germination (graines de sapin) en conditions contrôlées (travail à l'échelle de la boîte de Pétri : photographie numérique, import dans GRASS<fnref n="7" /> et rectification ...)

* en tâche de fonds, intégration de couches fournies par d'autres organismes (IGN, ONF, DIREN<fnref n="8" />, IFN<fnref n="9" />...)

### 1.2.c Description (Matériels et logiciels)

L'investissement financier direct pour l'unité a été faible jusqu'ici, en raison du choix des logiciels libres et de la prise en charge des frais pédagogiques par le service de formation permanente nationale. Le contexte budgétaire de l'Unité n'aurait pas permis la mise en place d'un SIG commercial. Le choix de ce type de logiciels ne se limite pas à l'aspect économique, il offre, outre des possibilités techniques importantes, une totale indépendance vis à vis des éditeurs et une plus grande ouverture en direction de l'offre concurrente.

Du coté matériel, nous disposons d'un serveur DELL doté d'un biprocesseur (Intel(R) Xeon(TM) CPU 3.20GHz), d'un scanner et d'une imprimante A3 couleur.

Il est important de disposer d'une bonne carte graphique, de disques durs de grande capacité (au moins 200 Go) pour les fonds rasters et de mémoire vive en abondance (2 Go) afin de travailler dans de bonnes conditions.

Depuis fin 2004, grâce à deux GPS de précision centimétrique (pro XR et Pathfinder power de marque Trimble) capables de travailler couplés en différentiel temps réel nous géo référençons les nouvelles données au fur et à mesure de leur récolte. La mise à jour des anciennes données se fait ponctuellement.

<footnote n="4">⁴ SIG BD : Système d'Information Géographique de Base de Données</footnote>

<footnote n="5">⁵ IGN : Institut Géographique National</footnote>

<footnote n="6">⁶ ONF : Office National des Forêts</footnote>

<footnote n="7">⁷ GRASS : Geographic Resources Analysis Support System</footnote>

<footnote n="8">⁸ DIREN : Directions Régionales de l'Environnement</footnote>

<footnote n="9">⁹ IFN : Inventaire Forestier National</footnote>
Comme le symbolise la **figure 1**, les données constituent le cœur de la cellule SIG-BD.
Quelle que soit l'échelle (de l'arbre au peuplement, sans oublier les fonds de référence) et
quelle que soit l'action, toute l'activité vise à gérer et à exploiter au mieux ces précieuses
données.

<figure><img src="image_2.png" /><figcaption>**Figure 1 :** *objectifs de la cellule SIG – BD*</figcaption></figure>

**1.3 Quelques définitions**

**SIG** (Système d'Information Géographique) : un système informatique pour saisir, stocker, vérifier, intégrer, manipuler, analyser et afficher des données positionnées à la surface de la Terre. Un SIG peut être utilisé pour traiter différents formats de cartes. Celles-ci peuvent prendre la forme de plusieurs couches où chacune contient des données pour un type d'entité particulier. Chacune des entités est liée à une position sur l'image d'une carte et les couches de données sont organisées de façon à en permettre l'étude et l'analyse statistique.

J'ai gardé la définition américaine du comité fédéral de coordination inter agences pour la cartographie numérique (FICCDC, 1988) alors qu'il y en a de plus récentes car elle est très appliquée et parle mieux aux non-spécialistes. En fait, un SIG sous-entend plus que cela ; en plus de ces outils spécialisés dans la gestion de données spatiales, la mise en place d'un SIG doit s'accompagner d'une réflexion, d'une organisation nouvelle quant à la mise à disposition et l'exploitation des données.

Le serveur éducatif dédié à l'information géographique de l'école nationale de sciences géographiques (ENSG) offre définitions et exemples.

http://seig.ensg.ign.fr/fichchap.php3

**SGBDR** (Système de Gestion de Bases de Données Relationnelles) : technologie logicielle évitant la prolifération des fichiers, assurant l'unicité de l'information de référence, facilitant et sécurisant les mises à jour.

**Logiciels libres** ou Open Source : selon la Free Software Foundation, le logiciel libre est un logiciel fourni avec l'autorisation pour quiconque de l'utiliser, de le copier et de le distribuer, soit sous une forme conforme à l'original, soit avec des modifications, ou encore gratuitement ou contre un certain montant.

Pour être libre, un logiciel doit respecter quatre libertés fondamentales : exécution, étude, redistribution des copies et amélioration.

http://www.france.fsfeurope.org/index.fr.html
**Serveur cartographique** : c'est un guichet automatique auquel l'utilisateur fait appel pour afficher des cartes sur son poste informatique. Par le protocole de communication Internet, TCP/IP, des ordinateurs branchés en réseau peuvent échanger de l'information via un navigateur Web ou transférer des fichiers grâce au protocole FTP. L'architecture est de type client/serveur, c'est-à-dire qu'un ordinateur dit serveur répond aux requêtes d'une série d'ordinateurs dits clients.

## 1.4 Les logiciels

Plus que de communication, on peut parler d'imbrication des différentes composantes de l'information géographique, autant du point de vue matériel (et donc logiciels) que de l'approche conceptuelle (figure 2).

<figure><img src="image_3.png" /><figcaption>Figure 2 : l'information géographique</figcaption></figure>

**GRASS** Geographic Resources Analysis Support System est un SIG généraliste destiné à la mise en œuvre, l'analyse et l'affichage de données graphiques en modes raster et vectoriel (les ponctuels étant gérés comme des vecteurs), ainsi qu'à la simulation et la visualisation géospatiale.

Il supporte de nombreux formats de données, notamment ceux de ses concurrents commerciaux les plus utilisés. Pour les vecteurs : Arc/Info, Shapefiles, DXF, ascii, MapInfo MIF, VRML, etc. Pour les données raster : Arc/Grid, E00, TIF, GIF, PNG, ASCII, etc.

En plus des fonctions de base pour un SIG, on peut noter :

* la possibilité de programmer des scripts ou fonctions supplémentaires,

* le lien avec des bases de données libres (MySQL, postgreSQL),

* la possibilité de faire des analyses statistiques avec R grâce à des modules de connexion.

http://grass.itc.it/gdp/index.php

**PostgreSQL** est un SGBDR complet, stable, performant, riche de nombreuses années de développement, en évolution constante, soutenu par une communauté active dont l'utilisation est encouragée par la Mission Informatique de l'Inra. Cet article ne décrira pas ce logiciel, référence dans son domaine qui justifierait d'un sujet d'article.

http://www.postgresql.org/

http://www.postgresqlfr.org/
PostGIS (contraction de PostgreSQL et de GIS) est le module gérant des objets (points, lignes, poly-lignes et polygones) et utilisant des fonctions (tampon, intersection, réunion, etc.). Ces objets et ces fonctions étant Géographiques, PostGIS confère à PostgreSQL le statut de SGDBR spatial.

http://www.postgis.org/

http://www.postgis.fr/

R est un langage et un environnement pour les calculs statistiques et graphiques. Il s'agit d'un projet GNU semblable au langage et environnement S. R peut être considéré comme une implémentation différente de S.

R procure une large gamme de techniques graphiques et statistiques (modèles linéaires et non linéaires, tests statistiques classiques, analyse de séries temporelles, classification...).

http://www.sas.stat.ucl.ac.be/R.html

Qgis (Quantum GIS) est un SIG libre, qui dispose d'une interface graphique accessible.

Au départ, QGIS était destiné à la seule visualisation de données SIG. Il supporte des formats aussi bien pour les données et les vecteurs (Arc/Info, ESRI Shapefile, Mapinfo File, ODBC, PostgreSQL, ...) que pour les rasters (Arc/Info ASCII Grid, GRASS Rasters, TIFF/GeoTIFF, USGS SDTS DEM, ...). Outre la visualisation de données, QGIS permet actuellement de modifier, de créer et d'ajouter des metadonnées aux couches vectorielles. Il est aussi possible de géo référencer des rasters grâce à un plugin. QGIS permet de créer des cartes mises en page. En outre, et cela représente un atout essentiel, QGIS comprend un plugin permettant l'intégration d'une partie des fonctions de GRASS et de ses outils.

Les SIG libres très ergonomiques sont peu nombreux. QGIS paraît intéressant car son interface simple permet de s'initier aux SIG, et il intègre dans ses menus les fonctionnalités de GRASS, logiciel moins accessible.

http://www.qgis.org/

http://www.gdf-hannover.de/lit_html/grass60_v1.2_fr/node83.html

Mapserver est un environnement de développement Open Source permettant de construire des applications Internet à référence spatiale. MapServer n'est pas un SIG complet, et n'aspire pas à le devenir. MapServer excelle à afficher des données spatiales, de type ou de géo référencement hétérogènes, sur le web (cartes, images et données vectorielles).

En plus de pouvoir parcourir des données géographiques, MapServer permet de créer des "cartes interactives", c'est-à-dire, des cartes qui peuvent guider l'utilisateur vers un contenu.

http://mappemonde.mgm.fr/num8/internet/int05401.html

http://mapserver.gis.umn.edu/index_html-fr?set_language=fr

Bibliothèques annexes

GDAL (Geo Data Abstraction Library) : traducteur pour des formats de données rasters.

http://www.gdal.org/

OGR: sous projet de GDAL pour la lecture de fichier vecteur. OGR est une bibliothèque Open Source en C++ fournissant la lecture (et parfois l'écriture) d'une variété de formats de fichiers vecteur comme ESRI Shapefiles, S-57, SDTS, PostGIS, oracle spatial, et Mapinfo mid/mif et TAB.

PROJ4 : permet de réaliser des changements de système de coordonnées/projection, action fréquemment requise lorsque l'on travaille avec des images satellites, par exemple.
En clair, ces bibliothèques permettent de lire, d'intégrer et de reprojeter les fichiers (raster ou vecteur) de différents formats.

http://proj.maptools.org/

## 2. Zoom sur GRASS

Même si GRASS n'est qu'une des pierres de l'édifice, il en constitue, allié à postgresSQL, la clef de voûte. Donc, il mérite de lui consacrer une présentation rapide.

Le logiciel GRASS a été développé, dès 1982, par l'armée américaine par l'USACERL (United States Army Construction Engineering Research Laboratory) dans l'Illinois. Il a été conçu pour réaliser des études environnementales et aider à résoudre des problèmes liés à l'aménagement du territoire. C'est donc un outil orienté à l'origine vers le traitement d'images (satellites notamment). Depuis 1995 (version 4.1), l'armée a arrêté le financement de son développement. C'est ainsi que le projet a été repris en 1997 par un autre laboratoire : le Center for Advanced Geography and Spatial Research at Baylor University (Waco, USA).

Depuis, il est devenu un logiciel libre distribué sous la licence GNU GPL (General Public Licence). En d'autres termes, le code source est accessible et on a alors le droit de le modifier.

Plusieurs programmeurs de différents pays contribuent d'bénévolement à l'enrichissement de GRASS. Il existe deux principaux pôles de développement : l'université de Baylor aux Etats-Unis (http://www.baylor.edu/grass/) et l'université de Trente en Italie (http://grass.itc.it/index2.html). Il est possible d'exécuter GRASS sur diverses plate-formes :

Unix, Linux, MacOS X et bien sûr, Windows pour toucher un large public.

Je tiens à insister sur la spécialisation passée de GRASS en direction des rasters ; si il a gardé toutes ses performances sur ce type de fichiers, il s'est formidablement développé vers le traitement des vecteurs lors du passage à la version 6.

Si, comme tout bon logiciel libre, l'évolution de GRASS se poursuit, il est notable qu'elle a tendance à s'accélérer ; en quelques mois, nous sommes passés à une version 6.0 que nous attendions impatiemment pour sa gestion vectorielle, la 6.1 avait amélioré son interface, la 6.2 est déjà « fixée » alors que nous ne l'avons pas téléchargée, faisant de la 6.3 la version en développement accessible à court terme alors qu'une version 7 est annoncée. La finalité n'étant pas d'installer la dernière version du logiciel, on peut faire l'impasse des versions intermédiaires. Cependant, les changement principaux sont incontournables (toutes les versions depuis l'origine sont encore disponibles mais seules les ramifications stables (en cours) et prospectives évoluent.

Nous gérons les données attributaires avec postgresSQL. Cette gestion peut aussi être réalisée en interne au format .dbf (esperanto de la base de données relationnelle sur micro) ou en externe avec d'autre SGBDR.

Ce logiciel, référence du monde des SIG a déjà été très bien présenté par Markus Neteler, spécialiste de GRASS en Europe depuis plusieurs années. Je conseille au lecteur intéressé le document, en français, sur le site

http://www.gdf-hannover.de/lit_html/nutshell_v10_fr/index.html

Plus concrètement, il y a plusieurs façons d'utiliser GRASS. On peut en définir trois :

* pour les débutants ou les utilisateurs de base venant des logiciels commerciaux, la manière la plus facile (il n'est pas ici question de l'installation) consiste à se servir de QGIS en interface de GRASS ; les fonctionnalités restent ainsi présentes mais l'accueil est du niveau des logiciels commerciaux considérés comme des références en matière de simplicité (Arcview ou MapInfo).
* La grande majorité des anciens utilisateurs, conscients des grandes améliorations apportées à l'interface de la version 5, trouvera que les apports au niveau des données vectorielles se sont accompagnés d'une amélioration de l'ergonomie. Le poste de travail de la Cellule SIG étant équipé de GRASS 6.1 CVS (c'est à dire en phase de mise au point), la majorité des captures d'écran viennent de cette version.

* Enfin, la ligne de commande : **outil précieux pour 'automatiser des procédures répétitives et, un raccourci pratique pour retenir une syntaxe plutôt que le chemin pour que l'interface graphique envoie un module donné.** Ces lignes de commande peuvent être envoyées une à une dans la console où GRASS est ouvert, elles peuvent être réunies dans un script shell (interpréteur de lignes de commande) qui, allié à un langage de programmation, peut, rendre réalisable une opération à peu près infaisable autrement. Dans la démarche qualité, on peut aussi copier-coller dans un fichier la ligne utilisée, que le module soit appelé par l'interface graphique ou en ligne. La possibilité est aussi offerte de créer des scripts en dynamique.

Dans une fenêtre console ou terminal selon les appellations, on tape `grass61` (pour une version 6.1) et on obtient cette page (figure 3) où l'on renseigne trois champs :

**Location** : nom de la région géographique où va s'effectuer le travail. Notons, car c'est une différence par rapport aux autres logiciels, que dans une location, les paramètres de projection, datum et ellipsoïde sont homogènes pour toutes les cartes.

**Mapset** : répertoire, sous location, où sont stockés les jeux de données.

**Database** : répertoire contenant les locations.

Le dernier paramétrage utilisé est gardé en mémoire et proposé la fois suivante.

Ceci lance GRASS (figure 3).

<figure><img src="image_4.png" /><figcaption>**Figure 3** : démarrer GRASS</figcaption></figure>
En ligne dans cette fenêtre, ou via l'interface graphique, si on a tapé auparavant d.m &, on peut lancer les modules de GRASS (figure 4). Ces modules ont des noms assez explicites (en anglais quand même...) que je développerai pour les premiers rencontrés : d.m --> display monitor

<figure><img src="image_5.png" /><figcaption>Figure 4 : lancer l'interface ou travailler en ligne de commande</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Figure 5 : interface graphique de la version 6.1</figcaption></figure>
La figure 6 représente un des modules de GRASS. Celui-ci sert à associer une carte vectorielle à une table postgresSQL (v pour vector, db pour database et connect pour connecter ... simple !).

Chaque module peut donc être lancé via une interface qui propose des champs à remplir, pour `v.db.connect` :

* `map` : nom de la carte vectorielle

* `driver` : nom du SGBD (pg pour postgresSQL)

* `database` : nom de la base de données

* `table` : nom de la table

* `key` : nom du champ servant de clef afin qu'à un objet géographique corresponde une valeur contenue dans la base

* ...

Notons que dans chaque interface ouverte (aussi bien la générale que celle de chaque module) se trouve une petite fenêtre en bas où s'affichent les commentaires sur la réalisation de ce qui a été demandé ainsi que la si précieuse ligne de commande (figure 6).

<figure><img src="image_7.png" /><figcaption>Figure 6 : connecter une table à une carte</figcaption></figure>

# 3. Applications

## 3.1 Utilisation de GRASS et PostgreSQL pour simuler des scénarios d'éclaircie

### 3.1.a Objectifs

- Réaliser sur le terrain deux modalités de traitements de la végétation, pour réduire le combustible dans un but de défense contre l'incendie à l'interface forêt - urbanisme.

- Décrire ces placettes : hauteur, recouvrement (%), agrégation

- Modéliser la propagation du feu :

* comportement du feu

* effets sur les maisons, pompiers, ou habitants

* impacts sur la végétation
### 3.1.b Méthode

* **Etape 1** : sur le terrain, cartographie manuelle des contours des cépées car les GPS n'étaient pas achetés à l'époque.

* **Etape 2** : numérisation des limites de cépées (bouquets d'arbres)

- Scan des cartographies de terrain,

- Dessin des cépées sous Sketch (logiciel de dessin vectoriel),

- Colori différent à chaque intersection ou superposition de cépées,

* **Etape 3** : intégration dans GRASS

- Import des limites de cépées ou intersections sous forme de raster,

- Transformation automatique en limites vectorielles grâce aux couleurs différentes,

- Création par digitalisation des brins (arbres individuels) constituant chaque cépée.

* **Etape 4** : constitution de la base de données

Le but ici est de renseigner la géométrie (les limites vectorielles) obtenue par les opérations précédentes.

Le script, en partie reproduit ci-dessous, permet de définir de façon interactive l'essence de chaque cépée, le code propre à l'équipe qui a effectué la mesure, ... afin que ces nouveaux éléments, appelés information attributaire, soient stockés automatiquement dans PostgreSQL.

On peut voir dans le zoom de la **figure 7**, sur une partie de la parcelle étudiée, le résultat des opérations précédentes (les commandes des figures 5 et 6 ont donné la figure 7). Le dessin papier d'origine est devenue une carte vectorielle et une carte raster. En simplifiant à l'extrême, on peut dire que dans une carte vectorielle, l'information est attachée à un centroïde et à des limites alors qu'en carte raster, cette même information est associée à chaque pixel constitutif de l'image.

<figure><img src="image_8.png" /><figcaption>**Figure 7** : vue de deux couches (un raster et un vecteur) et d'un identifiant<fnref n="10" /></figcaption></figure>

<footnote n="10">¹⁰ Nb : pour une meilleure lisibilité de l'image, consulter l'article sur le site du cahier http://www.inra.fr/intranet/Produits/cahiers-des-techniques</footnote>
```bash
#!/bin/sh
echo ""
echo "************************ Nouvel attribut ************************"'
echo " affectation (manuelle) de nouveaux attributs à des aires existantes "
echo "************************ Nouvel attribut ************************"'
echo "desc|from v.newlabel" >>
$GISDBASE"/"$LOCATION_NAME"/"$MAPSET"/"site_lists"/"ftemp
echo "input $vectorfile" >> $GISDBASE"/"$LOCATION_NAME"/"$MAPSET"/"site_lists"/"ftemp
g.region vect=$vectorfile ewres=1 nsres=1
zoom=n
while [ $zoom != 0 ]
do
d.erase
d.vect map=$vectorfile
echo "définir la zone de travail (1/4) (zoom)"
d.zoom
echo " zoom ok ? (o/n)"
read zoom
done
d.vect map=$vectorfile color=white
d.vect.labels attr=cat map=$vectorfile color=white
d.vect.pg key=id_policy tab=polygones where=cepee=$i map=Lagnes1_brin color=red
echo "code croissance :"
read codecroissance
echo $i $codecroissance >> sortiecepee
echo "choisir le poly a assigner"
d.wbat.vect -1 map=$vectorfile >ftemp
sed -e '1d' -e '3,$d' -e 's/\.*/'' ftemp > ftemp2
read est < bidon2
sed -e '1d' -e '3,$d' -e 's/^\.*) //'' -e 's/\.*/'' ftemp > ftemp2
read nord < ftemp2
limn=`expr $nord + $zoneNS`
lims=`expr $nord - $zoneNS`
lime=`expr $est + $zoneOE`
limw=`expr $est - $zoneOE`
...
i=`expr $i + 1` done
```

<caption>**Figure 8 : exemple de script partiel**</caption>

Ces lignes montrent la structure d'un script. On remarque le mélange de langage shell et de lignes de commande GRASS ; la coloration syntaxique apporte aussi une aide.
Ces travaux de description une fois intégrés dans le SIG, nous disposons d'un nouveau type d'information : l'Information Géographique. C'est à dire que nous connaissons la surface de chaque cépée ou de chaque brin. Si nous associons un modèle numérique de terrain (MNT), il devient possible, en croisant les couches d'informations, d'obtenir la pente et l'exposition pour chaque point de la placette.

La partie base de données ne sera pas développée ici. Cependant la **figure 9** visualise l'organisation et les relations des cinq tables de la base de données appelées Lagnes grâce à l'interface pgaccess.

La table pbc est constituée de clefs qui mettent à disposition de GRASS les informations contenues dans postgresSQL.

Voici des exemples de requêtes : la première nous affiche tout ce qui n'est pas du chêne vert et la seconde tout ce qui a une surface de plus de 20m².

**Requête 1 :** tri sur critère « espèce »

```
d.vect.pg -f key=id Tus poly tab=pbc where="cepeec.id cepeec=pbc.id cepeec and
espece.id espece=cepeec.id espece and espece.id espece!=1" map=Lagnes1_brin
color=blue
```

**Requête 2 :** tri sur critère de surface

```
d.vect.pg -f key=id Tus poly tab=pbc where=" surfcepee.surf.cepee>20 and
surfcepee.id.cepee=pbc.id.cepee" map=Lagnes1_brin color=blue
```

<figure><img src="image_9.png" /><figcaption>**Figure 9 :** schéma conceptuel des données de la base Lagnes</figcaption></figure>

Revenons au but final : réaliser « virtuellement » des éclaircies pour quantifier et de visualiser
au mieux leur effet.

Le logiciel donne aussi des résultats chiffrés pour faire des calculs. Voici les sorties sous
forme de cartes bien plus parlantes lorsque l'on échange avec les professionnels de terrain
chargés de réaliser les travaux.
<figure><img src="image_10.png" /><figcaption>**Figure 10 : comparaison entre les deux scénarios**</figcaption></figure>

On note que, pour un taux de recouvrement quasi identique, nous avons sur le terrain des peuplements de structures contrastées dans lesquels la dynamique du feu sera différente.

## 3.2 La régénération du Sapin pectiné au mont Ventoux

3.2.a Contexte et objectifs : Il a été observé une apparition de semis (jeunes arbres issus de graine, régénération naturelle) sur une grande partie de la face nord du mont Ventoux, notamment assez loin des semenciers (arbres producteurs de graines).

<figure><img src="image_11.png" /><figcaption>**Figure 11 : de la nature aux mathématiques**</figcaption></figure>
Afin d'expliquer la régénération, voire d'inclure dans des modèles prédictifs l'adaptation de ces espèces aux changements climatiques, il est apparu pertinent de mettre ce phénomène naturel en équation.

### 3.2.b Méthode

Compter les semis sur des placettes géoréférencées et dispersées dans le massif afin de mettre ce nombre en relation avec :

* les conditions physiques du milieu (altitude, pente, exposition) → source IGN,

* les caractéristiques des peuplements (densité, espèce, age) → source ONF,

* la végétation basse, taux de pierre → source URFM.

Le schéma de la "dispersion" des semis (figure 12) illustre notre démarche : quantifier en quoi une puissance émissive variable fait varier une régénération observée.

Le SIG permet d'intégrer les facteurs du milieu dans cette étude.

<figure><img src="image_12.png" /><figcaption>**Figure 12 :** *dispersion des semis*</figcaption></figure>

Dans les UAs (surfaces forestières homogènes), chaque pixel a une valeur de présence de sapin (6, 11, 20, 52 ou 91 pourcents), en dehors cette valeur vaut 0.

Dans les placettes de régénération, on a mesuré un nombre de semis au m² (7 ou 12 par exemple).

A chaque pixel à l'intérieur d'une UA contenant du sapin est affecté un arbre virtuel dont la capacité à produire des graines est proportionnelle au taux de sapin dans cette UA. De cette multitude de points aux coordonnées données par le SIG et des placettes de régénération aux coordonnées mesurées, sont déduits, croisées aux autres couches du SIG, différentes valeurs (distance, pente, exposition, ...) qui servent à alimenter le modèle de dispersion. La figure 13 permet de visualiser le détail de cette démarche.
<figure><img src="image_13.png" /><figcaption>Figure 13 : zoom sur la démarche raster</figcaption></figure>

### 3.2.c Données de base

<figure><img src="image_14.png" /><figcaption>Figure 14 : carte vectorielle des Unités d'Analyse (Mont Ventoux)</figcaption></figure>

<figure><img src="image_15.png" /><figcaption>Figure 15 : module GRASS commandant l'affichage de la carte vectorielle</figcaption></figure>

Il faut maintenant extraire l'information et l'agréger essence par essence.

Le module v.reclass.pg (figure 16) crée donc une nouvelle carte vectorielle contenant le taux de sapin de chaque unité d'analyse (UA). Cette information ayant été extraite d'une table de la base de données (pg : postgres)
<figure><img src="image_16.png" /><figcaption>**Figure 16** : module d'extraction de données attributaires affectées à une carte vectorielle</figcaption></figure>

Comme ensuite nous voulons travailler sur des matrices de données (arbres virtuels : **figures 12 et 13**), nous transformons ce vecteur en raster : v.to.rast est fait pour nous.

<figure><img src="image_17.png" /><figcaption>**Figure 17** : transformation d'un vecteur en raster et affichage de celui-ci</figcaption></figure>

Sur le même principe qu'un d.vect affichait la carte vectorielle, un d.rast envoie le raster à l'écran (figure 18).

<figure><img src="image_18.png" /><figcaption>**Figure 18** : le raster des UAs contenant du sapin avec un dégradé de bleu selon sa densité</figcaption></figure>
Ces captures sont issues de la version 5, ces modules ne sont donc plus appelés directement par l'utilisateur. Je les ai inclus dans cette présentation car, si l'interface générale a bien pris le relais (figure 3 ovale bleu), ce sont toujours ces modules qui sont appelés et on peut toujours les utiliser en lignes de commandes.

Vérifier que les ovales sont à leur place (sous openOffice, n'est pas fiable)

Le relief obtenu à partir d'un modèle numérique de terrain (MNT) est un raster, une matrice donc où, pour chaque point, on connaît l'altitude. GRASS possède un énorme module, NVIZ, qui gère la troisième dimension.

Dans la **figure 19**, l'altitude est doublement représentée, en relief et sous forme d'une variation de couleurs.

<figure><img src="image_19.png" /><figcaption>**Figure 19 :** le relief, en 3D, via NVIZ et en couleur</figcaption></figure>

Visualisons les peuplements semenciers et les semis. Dans la **figure 20**, au lieu de remettre l'altitude sur le relief, nous avons mis la couche raster du taux de sapin (déjà vue en 2D figure 18) et deux couches vectorielles. Ces deux couches contiennent des objets géographiques de types différents : aires pour les UAs et ponctuels pour les centres de placettes où la régénération est observée. Nous retrouvons donc sur le relief le taux de sapin (en gris : pas de sapin et dégradé de bleu pour un taux augmentant avec l'intensité de couleur), les limites vectorielles (les UAs) en bleu pâle et les placettes de mesures de la régénération (aires symbolisées par leur centroïde) sous la forme de pyramides rouges.

<figure><img src="image_20.png" /><figcaption>**Figure 20 :** visualisation d'un raster et de deux vecteurs en 3D</figcaption></figure>
### 3.2.d Complément d'information à courte distance

Dans la nature, rien n'est aussi simple, il a donc fallu un complément d'information. En effet, en dehors des peuplements, sources de graines, connus, nous avons trouvé des semenciers isolés, proches des placettes de régénération. Les graines donnant des semis ne provenant donc pas toutes des massifs référencés, nous avons localisé ces semenciers isolés dans une zone tampon de 50 m autour des placettes.

Sur le terrain, grâce aux GPS couplés à des télémètres laser équipés d'une boussole et en positionnant ces nouvelles sources, nous avons rajouté autour de nos placettes les demies sphères vertes (figure 21).

<figure><img src="image_21.png" /><figcaption>Figure 21 : zoom sur les semenciers proches (NVIZ)</figcaption></figure>

Pour une meilleure efficacité et bien que GRASS possède en interne des modules statistiques, les résultats ont été transférés sous R. Ceci se fait facilement, tous ces logiciels disposants d'interfaces de communication.

Contrairement aux logiciels commerciaux où la logique est de garder captif un client par des barrières techniques, ici, quand un logiciel est une référence dans un domaine où on veut travailler, au lieu de bloquer la migration des données grâce à des formats propriétaires, on développe une interface pour favoriser cette migration.
### 3.2.e Transfert vers le logiciel d'analyse : R (figure22)

Une fois sous R, quelques lignes suffisent à mettre en communication les deux logiciels ...

```r
library(GRASS)
gmeta() -> G
rast.get(G, "taux_sapin4") -> tauxsapinua1010
tauxsapinua1010$taux.sapin4[tauxsapinua1010$taux.sapin4==0] <- NA
tauxsapinua1010$taux.sapin4[tauxsapinua1010$taux.sapin4==0] <- NA
tauxsapinua1010$taux.sapin4[tauxsapinua1010$taux.sapin4==0] <- NA
plot(G, tauxsapinua1010$taux.sapin4)
```

<figure><img src="image_22.png" /><figcaption>**Figure 22** : visualisation du résultat de l'importation du raster (GRASS) dans R</figcaption></figure>

## 4. Mapserver, postgresSQL, qgis et les autres

Sans pousser plus loin la comparaison avec le célèbre film de C. Sautet (1974 quand même !), ces logiciels occupent une place importante dans la grande famille des « logiciels libres au service de l'Information Géographique » et à ce titre, ils ne devraient pas être privés complètement d'illustration.

Certains le seront pourtant pour plusieurs raisons : tout d'abord la place. Il serait illusoire de prétendre à l'exhaustivité sans avoir quelques milliers de pages devant soi (il paraît qu'on ne les a pas) ensuite, QGIS est en service dans l'Unité sur plusieurs postes et souvent sous Windows et enfin PostGIS n'est encore opérationnel sur aucun poste de travail de l'Unité.

Pour ces deux derniers exemples, il ne me semble pas pertinent de les inclure dans une présentation de travaux réels mais ils forment un tout cohérent, ils devaient être cités ici.

Pour leur importance présente et surtout à venir, j'ajouterais dans ce dernier chapitre deux captures de navigateur Internet utilisant mapserver d'une part et postgresSQL via une interface phpPgAdmin d'autre part.

Il est toujours surprenant de voir que malgré tous nos moyens de communication modernes, nous ne soyons pas totalement au courant de ce que fait notre voisin de bureau...

Dans l'Unité, Mapserver est utilisé dans ce que nous avons appelé le « serveur de cartes ».

Doté d'une interface de communication en PHP, cet outil est destiné à mettre à disposition ou
tout au moins à informer chacun dans l'Unité, de l'existence d'une donnée géographique qu'elle soit en accès libre (fonds de cartes IGN comme le scan 25 ou la BDOrtho, fichiers GPS de repérage d'un dispositif géré par d'autres...) ou la propriété non encore partageable (situation et mesures d'arbres ou d'insectes en cours d'exploitation...) d'une autre équipe. Ce n'est pourtant pas notre réalisation qui illustrera ce logiciel car nous n'avons utilisé que peu des outils proposés et notre serveur de carte, bien que fonctionnel, demande à être enrichi. Comme Mapserver est utilisé par un grand nombre de sites Internet, c'est vers un des leaders de la cartographie Web que je me suis tourné pour une capture d'écran (figure 23).

<figure><img src="image_23.png" /><figcaption>Figure 23 : serveur de carte de camptocamp (mapserver)</figcaption></figure>

Quant à postgresSQL, la quasi totalité des données entrant dans l'Unité a vocation à être intégrée dans une base de données. Le bénéfice collectif attendu serait immense : sauvegarde simplifiée, partage possible, accessibilité aux partenaires sans pareille, connexion au SIG porteuse de nouveaux traitements, etc. Pour cela il faudrait proposer une permanence dans le service offert et exposer les bons arguments pour faire évoluer les pratiques.
<figure><img src="image_24.png" /><figcaption>Figure 24 : interface web (phpPgAdmin) d'administration de postgresSQL</figcaption></figure>

Conclusion

Dans de nombreux domaines de recherche à l'Inra, de l'échelle centimétrique au paysage, de la création de données à la gestion du patrimoine, l'information géographique est devenue incontournable.

Si, dans l'Unité de Recherches Forestières Méditerranéennes, les méthodes sont relativement conventionnelles, les outils permettant d'utiliser cette information sont originaux. L'expérience acquise ces dernières années, en accord avec les communautés d'utilisateurs, nous permet d'affirmer que ces outils sont parfaitement matures, évolutifs et aptes à satisfaire les plus exigeants.

Cet article se voulait aussi exhaustif que possible, il est donc superficiel. Servez vos des liens pour en savoir plus. Les forums du Web, en l'absence de formations structurelles, sont un bon soutien.

Que tous ceux dont l'objet d'étude est dans « l'espace » et qui n'ont pas encore tenté ce mode d'approche, puissent y trouver intérêt.