Les « geodatabases » de GRASS GIS, structure générale (LOCATION, MAPSET) et conséquences pratiques (changement de système de projection, etc.)

Non, non, ce titre n'est pas une blague. Alors que cet anglicisme semble avoir été « vampirisé » par ESRI (une simple recherche sur le Net suffit pour s'en convaincre...) et malgré la définition restrictive d'ESRI (www.esrifrance.fr/geodatabase.asp),

La géodatabase est la plate-forme commune de stockage et de gestion des données d'ArcGIS

il existe d'autres systèmes structurés, non ESRI, permettant le stockage de grandes quantités de données géographiques et leur exploitation (ajout, mise à jour, recherche de données, etc.). Ceux-ci peuvent aussi être assimilés à des geodatabases.

Ainsi, depuis le début de son histoire (dans les années 1980), GRASS GIS, développé sur Unix, stocke toutes ses données, entités spatiales (vecteurs, rasters divers, surfaces, MNT, et volumes 3D), tables attributaires ou modélisation des relations spatiales entre les données (topologie, réseaux) dans un système structuré et hiérarchisé de répertoires. N'est-ce pas là, la définition d'une geodatabase fichier, bien antérieure à celle d'ESRI ?

Mais arrêtons cette digression et laissons le terme geodatabase à ESRI car dans GRASS GIS, cette base ne s'appelle pas comme ça (on devrait parler d'« ESRI geodatabase »). La structuration de cette GISDBASE est importante à comprendre, notamment pour les changements de systèmes de projections de vecteurs ou de rasters, question récurrente sur le ForumSIG.

 La (ou les) bases de données géographiques

Il s'agit, au départ, d'un simple répertoire que la coutume suggère d'appeler « grassdata », mais qui pourrait tout aussi bien s'appeler « Portail SIG » ou tout autre nom puisque GRASS permet de choisir le répertoire au démarrage. C'est la variable GISDBASE dans l'application. Il est donc possible d'avoir plusieurs GISDBASES (plusieurs répertoires). Sur ma machine, le contenu d'un de ces répertoires se présente de la manière suivante :

LOCATION (Secteur)

Tous ces sous-répertoires constituent ce que GRASS nomme les LOCATIONS (secteurs). Chaque secteur est défini par un et un seul système de projection. Celui-ci est choisi lors de sa création.

MAPSET (Jeu de données)

Chaque secteur est constitué de nouveaux sous-répertoires qui sont les MAPSETS (Jeux de données).

Chacun d'entre eux est un sous-ensemble géographique particulier. Il n'y a aucune limite quant à leur nombre ou leur taille. Leur seul point commun est d'être dans le même système de projection, défini dans le secteur.

Jeu de données PERMANENT (Source)

Dans chaque secteur, il y un jeu de données PERMANENT qui est créé par défaut lors de la genèse d'un secteur.

1. il contient les définitions de la projection du secteur (PROJ_INFO et PROJ_UNITS),  la région par défaut (DEFAULT_WIND)  et le nom du secteur (MYNAME) (la signification de WIND sera vue par après);
2. c'est généralement un jeu de données référence où sont placés tous les géodocuments destinées à être utilisés par tous les autres jeux de données (fonds topographiques, MNT, etc.). Si le souhait est de les garder  « intacts » (consultables en lecture seule) il est possible de lui donner des autorisations de lecture seule (voir point suivant) ;
3. en pratique, il peut toujours être utilisé comme un jeu de données parmi d'autres.

Jeux de données (MAPSETS)

principes

GRASS est un système multiutilisateur avec des règles. Il peut en effet y avoir des administrateurs et des utilisateurs, avec des permissions d'accès à certains jeux de données (lecture et / ou d'écriture). Suivant les cas, les utilisateurs peuvent se voir interdire l'accès à un jeu de données, pouvoir le consulter en lecture ou le modifier.

En pratique, comme on est généralement le seul à travailler sur son secteur personnel, ils sont utilisés pour subdiviser l'ensemble en zones ou sous-zones de travail suivant les intérêts (chez moi, par exemple, j'ai un jeu de données avec les DEMS STRM et ASTER, un autre avec les cartes de références et plusieurs jeux de données suivant la zone de travail ou le thème traité).

régions

Chaque jeu de donnée possède une ou des régions de travail (pour rappel, une région est une fenêtre de traitement avec une certaine résolution). Elle peut être spécifiée au départ, mais peut être modifiée à volonté (voir partie « conséquences »). Si le jeu de données PERMANENT est utilisé sa région peut aussi être modifiée.

Les principaux fichiers présents sont:

• WIND, propriétés de la dernière région utilisée (dans le cas de PERMANENT, il y aura donc un fichier WIND en plus de DEFAULT_WIND) ;
• VAR qui indique le type de bases de données utilisé (dbf, SQLite, PostGIS, etc.), avec les variables DB_DRIVER (dbf, par exemple) et DB_DATABASE (qui pointe vers le dossier dbf, idem pour SQLite) ;
• SEARCH_PATH qui indique les autres jeux de données accessibles (voir dans la partie « conséquences ») ;
• éventuellement un fichier HISTORY qui récapitule l'historique des traitements effectués et un dossier hist qui stocke un historique individuel de chaque objet qui a fait l'objet d'un traitement.

le reste...

Les sous-répertoires présents dans un jeu de données relèvent de la cuisine interne de GRASS GIS pour stocker les vecteurs, les divers types de raster, les volumes 3D et toutes les tables associées à ces vecteurs, mais aussi à ces rasters (GRASS peut en effet associer des variables aux pixels d'un raster, considéré comme une matrice, comme z pour les MNT, les catégories pour r.resample et énormément de choses avec r.mapcalc...). Il est important de comprendre qu'un même objet peut être  « splitté » dans plusieurs de ces dossiers en fonction de ses propriétes (voir partie « conséquences »).

Synthèse

La synthèse de la structure d'une base de données fichier de GRASS GIS est schématisé dans la figure suivante qui reprend tous les éléments examinés :

Elle facilite la compréhension du diagramme « Structure of the GRASS data hierarchy» de la page du wiki de GRASS, « GRASS 6 Terminology ».

Conséquences pratiques

Quelles sont les conséquences pratiques d'une telle structure ?

Déplacement de données d'une GISDBASE à une autre

• l'examen de la figure montre qu'il suffit de déplacer un dossier secteur d'une base à une autre pour pouvoir l'utiliser directement. Un secteur est complet, il n'y a aucun lien vers d'éventuels fichiers extérieurs (sauf cas très particulier). C'est de cette manière que sont distribuées les LOCATIONS de démonstration comme Spearfish ;
• si l'on veut déplacer un jeu de données, il est nécessaire de créer auparavant un secteur de même projection dans la base qui va le réceptionner.

À l'intérieur d'une même GISDBASE

Changement de système de coordonnées (reprojection)

• au vu des caractéristiques d'un projet, c'est évident:

• r.proj (rasters) ou v.proj (vecteurs) vont reprojeter l'objet spatial situé dans le premier secteur, dans le système de projection A, vers le deuxième secteur, dans le système de projection B. En me plaçant dans le Secteur2 / Jeu de données, la commande suivante va copier monraster, reprojeté dans le système de projection B :

r.proj input=monraster location=secteur1 mapset=mapset 1

• j'importe toujours les données dans leur projection originale. En cas de besoin, je les reprojette vers mon mapset de travail (ex. les DEMS Aster ou SRTM, sont dans des secteurs avec leur projection originale, EPSG 4326, alors que je travaille en EPSG 31370. Grâce aux régions et aux MASKs, je ne reprojette que des petits fragments).

Passage d'un secteur à l'autre:

• Avec le menu Settings (ou Config) / Grass working environment / Change location and mapset, il est possible,  de changer de secteur et de jeu de données, au cours d'une même session de GRASS.

À l'intérieur d'un même secteur (LOCATION)

Déplacement de données d'un jeu de données à l'autre

Je n'ai pas l'autorisation de modifier les données présentes dans le jeu de données PERMANENT mais j'ai tout de même besoin de le faire pour mon travail ou, plus simplement, je veux garder les données présentes comme couches de références « intouchables ».

• il faut alors utiliser la commande g.copy avec les rasters et / ou les vecteurs. Comme le système de projection est le même, il n'est nécessaire de ne jouer qu'avec les régions (le @Mapset n'est souvent pas nécessaire, GRASS cherchant le raster nommé rasterbase dans tous les jeux de données d'un secteur. Il n'est utile que s'il y a plusieurs éléments du même nom) :

g.copy rast='rasterbase@PERMANENT,monraster vect=routes@PERMANENT,mesroutes

Passage d'un jeu données à l'autre

• avec le menu Settings (ou Config) / Grass working environment / Change Mapset, il est possible,  de changer de jeu de données au cours d'une même session de GRASS.

 

Partage de jeux de données

• depuis le jeu de données où je travaille, je peux accéder aux autres jeux de données suivant les règles établies. Ce sont les commandes g.mapsets (utilisation simple) et g.access (contrôle d'accès aux jeux de données) ou par le menu Settings (ou Config) / Grass working environment / Mapset access ou User access :

À l'intérieur d'un même jeu de données (MAPSET)

modification d'une région

• dans un même secteur, chaque jeu de donnée possède une région qui peut être différente de la région par défaut :

• une région peut être créée / modifiée à tout moment en fonction des besoins, suivant divers critères (commande g.region ou menu Settings (ou Config) / Grass working environment / Set region) :

 

• une région définie peut être nommée (« named region ») afin de pouvoir être réutilisée plus facilement ou être partagée (lors d'un partage de jeu de données) :

• les spécificités des régions ont été illustrées dans www.portailsig.org/content/grass-gis-region-resolution-resolution-3d-drapage-ou-l-apparente-quadrature-du-cercle

Au niveau d'un objet individuel (vecteur, raster, raster 3D, volume 3D)

Un objet spatial dépend donc du système de projection du secteur et de la région du jeu de données. Sa représentation dans la base GRASS est découpée en plusieurs éléments comme sa géométrie, sa topologie, sa table attributaire, ses catégories, le type d'encodage des rasters etc. Chacun de ces élément est placé dans un des dossiers d'un jeu de données. 

changement de projection et copie à l'intérieur d'un secteur et/ou d'un jeu de données

• ces points ont déjà été abordés.

importation

• un élément est toujours importé dans un jeu de données, qui a une région définie, et dans un secteur, qui a un système de projection défini. C'est pourquoi les dialogues d'importation ont toujours une option « Override projection (use location's projection) » :

• lors de l'importation, GRASS essayera de préserver le système de projection original et s'il y a une incompatibilité, il signalera une erreur « Projection of dataset does not appear to match current location ». Si l'utilisateur est sûr de son fait et veut ignorer cette alerte, il cochera l'option ;
• pour changer la projection de l'objet importé, il est nécessaire d'utiliser la possibilité de créer un nouveau secteur basé sur son extension géographique et son système de projection. La suite a déjà été expliquée ;
• dans le cas des vecteurs, il y a moyen de restreindre l'importation à la région utilisée en spécifiant le drapeau -r (flag). Seuls les éléments partiellement ou complètement situés dans l'extension géographique de la région seront importés ;
• la région peut toujours être ajustée en fonction de l'extension géographique (et la résolution) de l'objet (drapeau -e) ;
• illustration des concepts avec r.in.gdal :

 

exportation

• à moins de très bien connaitre à quoi correspondent les fichiers dans chaque dossier, il n'est possible d'exporter un objet qu'à partir de l'application elle-même. Il sera exporté par défaut avec le système de projection du secteur et, pous les rasters, avec l'extension géographique de la région du jeu de données.

Conclusions

J'espère avoir clarifié la structure de la base de données fichier de GRASS GIS et ses conséquences. Ceci permet de voir directement où se situe un problème particulier.

Elle permet aussi de comprendre comment exporter un secteur et / ou d'un jeu de données spécifiques d'une base de données à une autre (et d'un ordinateur à l'autre). Même plus, utilisant Dropbox (www.dropbox.com/), j'ai placé une de ces bases dans un dossier partagé de Dropbox, directement synchronisée lorsque je travaille sur n'importe quel autre ordinateur.

Encore une fois, j'ai essayé de l'expliquer comme j'aurais voulu qu'on me l'explique (ce qui n'est pas le cas, malheureusement, avec toute la documentation de GRASS GIS, trop générale ou trop spécialisée). La caractéristique qui me gêne le plus est le processus de reprojection d'un objet, qui n'est pas « à la volée » comme dans Quantum GIS, par exemple. Mais la démarche est logique en fonction de la structure de la base de données fichier et on s'y habitue vite. Une autre solution, moins directe, serait de les exporter, de les transformer avec les outils en ligne de commande de GDAL/OGR, puis de les réimporter...

Alors, les « geodatabases » de GRASS GIS ?

Tous les traitements ont été effectués sur Mac OS X avec GRASS GIS 6.4.1 RC1 et Inkscape pour les figures.

Site officiel : GRASS 6 Terminology
Site officiel : GRASS GIS: Understanding the GRASS Database

licence Creative Commons Paternité-Pas d'Utilisation Commerciale-Partage des Conditions Initiales à l'Identique Commerciale 2.0 France