Skip to Content

Nous adressons toutes nos pensées à la famille de notre ami Jérôme !

http://www.forumsig.org/showthread.php/43488-Disparition-de-Phoenix

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) :

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


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

Commentaires

Le problème des softs proprio

Le problème des softs proprio est toujours le même, voulez vous devenir fort en arcgis et changer de methode de travail à chaque release ou augmenter vos connaissances?
Postgis est pérenne et basé sur des normes Iso, donc on peut y aller :)
Tout utilisateur Esri peut dire merci au libre, la compétition est saine.

juste en complément,

pour signaler un article en accès intégral de Géomatique Expert n°41/42 de février/mars 2005 et dédié aux géodatabases esri, en termes plus théoriques que d'implémentation et qui apporte un angle d'attaque aux historiens du sig intérressés par le concept de geodatabase

 

Pirot F., Saint-gérand Th., 2005, La géodatabase sous ArcGis, des fondements conceptuels à l’implémentation logicielle, Revue de Géomatique Expert N° 41/42, Février/Mars 2005 p.62-66

http://www.geomag.fr/rev/pdf/41_16.pdf

 

et

Du concept HBDS à la geodatabase topologique : 25 ans les séparent

http://www.esrifrance.fr/sig2004/communications/pirot/pirot.htm

 

 

Je confirme !

l'organisation interne de GRASS où tout est accessible en clair en passant par un simple navigateur de fichiers ou en lignes de commande offre un moyen simple et automatisable d'accès aux données que je ne pense pas pourvoir retrouver ailleurs.
Cette organisation impose (enfin ça vaut mieux ...) une bonne maitrise des paramètres de projection et c'est, à mon avis, une excellente chose

Si je ne me trompe pas, la

Si je ne me trompe pas, la topologie, les réseaux, les mnt sont également inclus dans la geodatabase de GRASS, pour le reste je n'en sais rien

avec un titre pareil

fallait s'attendre à ce que je commente!

Plus sérieusement, le concept de géodatabase esri ne se résume pas à un stockage avec projection définie de couches (vecteurs et rasters)ou à la définition standard (http://en.wikipedia.org/wiki/Geodatabase). La puissance de leur vision de la géodatabase est d'y avoir inclus un mécanisme de sous-répertoire (feature-dataset) mais surtout les bonus: topologie, réseaux, surface (mnt), sous-types et domaines... ce qui aide à garantir cohérence et qualité des données et, à ma connaissance, n'est poussé aussi loin chez aucun concurrent (libre ou non).

Oui et non ...

La géodatabase que tu cites n'est vraiment valable qu'avec ArcEditor au minimum, avec ArcView, pas de Topologie, le stockage Raster est même déconseillé pour les géodatabases personnelles et fichiers (en gros, essayes ArcSDE ou passes ton chemin) ... Bref Grass ou QGIS ont l'avantage d'apporter la topologie et le traitements de données raster au sein ou non d'une géodatabase sans avoir à investir dans des licences abominablement couteuses.

Je parle en tant qu'utilisateur ArcView très souvent frustré de devoir passer souvant par le libre faute de pouvoir s'offrir 3 ArcEditor pour exploiter l'ensemble des fonctionnalités cités sur le géodatabase.

Enfin, la rigueur d'un véritable SGBD couplée à une cartouche spatiale apporte selon moi des fonctionnalités très proche des géodatabases ESRI et même au delà.

L'usage d'un véritable SGBD

L'usage d'un véritable SGBD permet bien plus que les geodatabases ESRI, ayant à utiliser des bases de données relationnelles complexes, on arrive rapidement à une usine à gaz sous arcgis lorsqu'on veut faire des requêtes complexes (et pourtant j'ai à ma disposition toutes les versions que je veux) alors qu'avec une requête SQL je peux avoir mon résultat dans un SGBDR classique ...

Après ce n'est pas forcément le boulot d'ArcGIS de faire ça par contre la non prise en compte ou tout du moins la difficulté d'utiliser des sgbd à partir d'arcgis pose un réel problème et contraint souvent l'utilisateur à utiliser les geodatabes esri, là où le libre et d'autres logiciels proprios ne posent pas ces contraintes.

pourquoi faut-il qu'un

pourquoi faut-il qu'un utilisateur des systêmes ESRI,se "vexe" chaque fois que quelqu'un "ôse" parler d'un SIG qui n'est pas d'ESRI ? Il est vrai que ce sont "les plus beaux, les plus forts,les meilleurs,..." et qu'ils "savent donc tout faire", si on veut y mettre le prix....
Mais il y a aussi d'autres choses et on a encore le choix, heureusement...

La puissance des bases de

Ou je me suis mal exprimé, ou vous n'avez pas bien lu, car disséminé dans le texte, mais

La puissance de leur vision de la géodatabase est d'y avoir inclus un mécanisme de sous-répertoire (feature-dataset) mais surtout les bonus: topologie, réseaux, surface (mnt), sous-types et domaines...

est aussi dans la puissance des bases de données GRASS, (qui n'a rien à voir avec celle de ArcGIS)

  • sous-répertoire (feature-dataset): c'est quoi, à votre avis les sous répertoires dans un mapset ?
  • les bonus: topologie, réseaux, surface (mnt): aussi présents dans les bases de données GRASS, les MNT étant une de ses spécialités
  • sous-types et domaines: c'est vrai mais présents d'une autre manière

 avec, en plus, la gestion des volumes 3D. Ce sera l'objet d'un autre article.

Poster un nouveau commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.