GRASS GIS pas à pas pour les débutants: 12 - les tables attributaires (DBF, SQLite, PostGIS, MySQL, ODBC)

Pour le Sigiste lambda qui aborde GRASS GIS, le moins que l'on puisse dire est que la gestion des tables attributaires paraît encore assez éloignée du confort des logiciels SIG auxquels il est habitué (jusqu'il y a peu, elles ne se manipulaient qu'en ligne de commande ou avec de multiples fenêtres graphiques...). Mais la version 6.4 a amené une interface relativement plus classique avec l'utilisation de wxPython en lieu et place de Tcl/Tk et la future version 7 a une interface plus aboutie. À l'inverse, passer d'un système de base de données à un autre est d'une facilité déconcertante (DBF vers SQLite, PostgreSQL, etc.) grâce au DBMI (DataBase Management Interface), utilisé par GRASS GIS).

Ces tables permettent d'obtenir toutes les fonctionnalités d'un SIG:

Le sujet sera abordé de la manière suivante:

• Principes: le DBMI et les manières de s'en passer avec les liens vers des données externes (v.external);
• Les divers types de bases de données qui peuvent être utilisés;
  • caractéristiques dans GRASS GIS;
  • les commandes disponibles.
• Les interfaces graphiques;
• En ligne de commande pour aller plus loin;
  • définition de la base par défaut d'un secteur (LOCATION) ou d'un jeu de données (MAPSET) en lieu et place des fichiers dbf;
  • connexion d'une couche vectorielle à une table attributaire spécifique;
  • changement de SGBD, migration des tables attributaires;
  • traitements (requêtes, etc.).
• Changements avec la version 7 de GRASS GIS
  • conversion des couches vectorielles au format de la version 6 vers celui de la version 7;
  • conversion des couches vectorielles au format de la version 7 vers celui de la version 6.
• Conclusions

Principes

Le format de stockage actuel par défaut de ces tables attributaires est le DBF (reliquat du passé, ce n'est plus le cas avec la future version 7 où c'est SQLite).

GRASS GIS peut aussi utiliser d'autres bases de données, plus puissantes. Quel que soit le format, les traitements restent les mêmes, car toutes les procédures ont été formalisées dans une couche d'abstraction unique nommée DBMI (DataBase Management Interface).

Le schéma suivant constitue une synthèse de toutes les possibilités:

Il peut paraître un peu compliqué de prime abord, mais nous allons en détailler quelques principes dans la suite.
Mais avant de les examiner,  remarquons tout de suite qu'il y a moyen de s'en passer si l'on veux simplement examiner une couche, sans l'importer. C'est le but de la commande v.external (qui va vous expliquer le pourquoi des flèches PostGIS vers OGR et vers PostgreSQL, par exemple).

• en ligne de commande:

• à partir du menu Link external formats (v.external ou r.external)

• dans le cas des couches vectorielles, elle permet de visualiser dans GRASS GIS des fichiers shapefiles, des tables PostGIS ou SpatiaLite, en lecture seule et avec/sans topologie (pas une topologie GRASS, mais celle de la source, si elle en dispose, comme dans les dernières versions de PostGIS ou de SpatiaLite, par exemple).  Cela vous permet néanmoins:
  • de consulter les données sans les importer;
  • d'effectuer rapidement des transformations avec tous les modules de GRASS (comme la transformation d'un fichier shapefile en KML, GML, etc. ou avec les rasters, un fichier GeoTIFF  en coordonnées x,y, z avec la commande r.out.xyz, par exemple);
• v.external avec une couche PostGIS et une couche SpatiaLite:

• si l'on veut modifier les géométries et créer de nouveaux objets et/ou une topologie GRASS, tout en gardant les attributs dans les fichiers dbf, ou les tables PostGIS ou SpatiaLite, il est alors nécessaire de passer par la manière classique pour importer la couche et la reconstruire selon les principes de GRASS (géométries/topologies dans GRASS, beaucoup plus strictes que celles de PostGIS ou de SpatiaLite, attributs dans PostGIS ou SpatiaLite);

Les divers types de bases de données qui peuvent être utilisés

Ceux-ci sont résumés dans la figure suivante :

Leurs caractéristiques générales sont reprises dans le tableau suivant (repris de « SQL support in GRASS GIS ») :

dbf	fichiers dbf	http://shapelib.maptools.org/dbf_api.html
sqlite	fichier et tables SQLite	http://sqlite.org/
pg	tables PostgreSQL	http://postgresql.org/
mysql	tables MySQL	http://mysql.org/
mesql	tables MySQL intégrées	http://mysql.org/
odbc	UnixODBC. (PostgreSQL, Oracle, etc.)	http://www.unixodbc.org/

(le format spécifique mesql qui permet d'utiliser des tables MySQL sans serveur ne sera pas abordé ici)

Caractéristiques dans GRASS GIS

Les formats DBF et SQLite sont matérialisés par des fichiers (voir « SQLite - SpatiaLite: le pourquoi du comment »), les autres non. Hormis le format DBF, tous les autres concernent des SGBD. Les possibilités de traitement SQL avec DBF sont très limitées, voire inexistantes (en plus des nombreuses contraintes comme les noms de champs limités à 10 caractères). La connexion ODBC permet théoriquement d'utiliser d'autres SGBD comme Oracle, Microsoft Access, FileMaker Pro, etc. Pratiquement, ce n'est pas aussi évident que ça ...

• au format DBF (n fichiers dbf):

• au format SQLite (n tables dans un fichier) :

• il ne faut pas confondre les bases SQLite de GRASS GIS, qui ne contiennent que les attributs des couches vectorielles, avec les bases SQLite/SpatiaLite.

Les commandes disponibles

Elles sont dissociées en deux séries de commandes, la création et la gestion d'une table et l'utilisation de celle-ci une fois qu'elle est associée à une couche vectorielle. Notons que tout cela est effectué automatiquement dans le format défini par défaut (DBF, SQLite, etc.) lors d'une importation avec v.in.ogr ou lors de la numérisation d'une nouvelle couche:

création automatique d'une table lors de la numérisation

C'est cependant très utile car il est possible d'associer plusieurs tables dans des formats différents à une couche vecteur:

• db.*   permet de créer une base de données et de la gérer. C'est la démarche effectuée en cochant Create attribute table dans le dialogue précédent. Les commandes disponibles sont db.columns (liste des colonnes), db.copy, db.drivers, db.login, db.tables (liste des tables), db.connect, db.describe, db.execute (requêtes SQL), db.select (requêtes SQL), db.test. db.in.ogr et db.out.ogr permettent d'importer ou d'exporter les tables non spatiales 
• avec GRASS 6.4.x:

• v.db.*   permet d'associer une table à une couche vectorielle et de l'utiliser avec celle-ci (ajout/suppression d'enregistrements, modification, etc.). C'est ce qu'on utilise, par exemple, pour modifier la table créée précédemment. Les commandes sont v.db.addcol, v.db.droptable, v.db.update, v.db.addtable, v.db.reconnect.all,  v.db.connect, v.db.select 
• avec GRASS 6.4.x:

• avec GRASS 7.0

• les couches vectorielles d'un même jeu de données peuvent parfaitement avoir des attributs placés dans des SGBD différents. Une même couche vectorielle peut avoir différentes tables attributaires (notion de layer, déjà vue).
• par exemple, si  db.connect spécifie la base par défaut d'un jeu de données,  il est tout à fait possible de spécifier une autre base pour une couche vectorielle spécifique à l'aide de la commande v.db.connect.

 Les interfaces graphiques

GRASS, depuis les versions 6.4.x, offre une interface graphique centralisée qui permet d'effectuer la plupart des traitements.

• cette interface est accessible depuis le « Layer Manager »:

 

• gestion des enregistrements:

• gestion des champs:

• gestion de la base utilisée pour une table: format DBF

• gestion de la base utilisée pour une table: format SQLite:

• tous les traitements se font sous forme de requêtes SQL qu'il est possible de construire à partir d'un « Constructeur SQL » : attention, db.query permet de traiter n'importe quelle table alors que v.db.query est réservé aux traitements sur les tables attributaires d'une couche vectorielle (liens avec la géométrie/topologie):
• avec GRASS 6.4.x:

• avec GRASS 7:

En ligne de commande pour aller plus loin

Malgré ces belles interfaces, il est utile d'expliquer les procédures en ligne de commande. Cela permet de comprendre réellement ce que l'on fait et sur quoi sont basées ces interfaces graphiques.

Définition de la base par défaut d'un secteur (LOCATION) ou d'un jeu de données (MAPSET) en lieu et place des fichiers dbf.

• On utilise la commande  db.connect du menu Database/Manage databases/Connect:

 

• dans le cas de SQLite, le fichier mabase.db sera créé dans le répertoire par défaut (il y a moyen de spécifier un répertoire spécifique). Toutes les tables attributaires des nouvelles couches vectorielles seront placées dans ce fichier/base de données ;
• dans les autres cas, la même opération sera effectuée au sein des bases de données spécifiées ;
• il y a toujours moyen de connaître le type de base de données utilisé par défaut avec la commande db.connect -p et de tester la connection avec db.test.

Connexion d'une couche vectorielle à une table attributaire spécifique

• pour connecter une couche vectorielle à une table attributaire spécifique dans une base de données, il faut utiliser la commande v.db.connect du menu Database/Vector database connection/Set vector map_database connection (rappelons que cette procédure est réalisée automatiquement lors d'une importation avec v.in.ogr ou lors de la numérisation d'une nouvelle couche).
• les commandes:

• la clé de jonction est spécifiée par la variable key (de type numérique entier) et le type de base utilisé pour une couche par la variable layer. Il est tout à fait possible d'avoir une table dbf dans la couche 0, une autre d'un autre type dans la couche 1 et ainsi de suite (voir Les « geodatabases » de GRASS GIS, structure générale (LOCATION, MAPSET) et conséquences pratiques (changement de système de projection, etc.) );
• la vérification du type de table se fait avec la commande v.db.connect -p.

Changement de SGBD, migration des tables attributaires

Comme déjà soulignée, une des grandes forces de GRASS GIS est la possibilité de passer d'un format de table à un autre de manière presque transparente grâce au DBMI (DataBase Management Interface). En pratique, cela se fait avec la commande db.copy du menu Database/Manage databases/Copy table suivie de la commande v.db.connect pour reconnecter la couche vectorielle:

• db.copy permet, en général, de copier les tables (attributaires ou non) de n'importe quel système de base vers un autre.

traitements

avec db.*

Tous les traitements se font avec les requêtes SQL, sous forme de chaîne de caractères ou de fichier SQL:

avec v.db.*

Tous les traitements se font avec des requêtes SQL, variables suivant les modules utilisés:

Changements avec la version 7 de GRASS GIS

Il est déjà possible d'utiliser des versions beta de cette version en cours de développement:

• en la compilant;
• en installant une version  compilée (mise à jour régulièrement, voir journellement):
  • pour Mac OS X, chez Michael Barton à www.public.asu.edu/~cmbarton/files/grass_mac/OSX10.6-snowleopard/ qui utilise les mêmes bases que les versions 6.4.x de www.kyngchaos.com/software/grass;
  • pour Windows à grass.osgeo.org/grass70/binary/mswindows/native/;
  • pour Linux à grass.osgeo.org/grass70/binary/linux/snapshot/.

Dans cette version:

• le format des couches vectorielles a été profondément modifié (d'où le v.build, nécessaire);
• le format de base de données par défaut est SQLite ( et plus DBF);
• les algorithmes de traitement ont été significativement améliorés au niveau de la vitesse de traitement et des ressources mémoires de calcul, ce qui offre la possibilité d'analyser des ensembles de données énormes (là où la plupart des autres échouent).

Conversion des couches vectorielles au format de la version 6 vers celui de la version 7:

Voir grasswiki.osgeo.org/wiki/Convert_all_GRASS_6_vector_maps_to_GRASS_7 pour toutes les couches vectorielles d'un jeu de données (MAPSET):

Mais, il est tout à fait possible de continuer à utiliser le format DBF si on le désire, le seul v.build suffit.

Conversion des couches vectorielles au format de la version 7 vers celui de la version 6.x:

Comme GRASS GIS version 6.4.x peut utiliser des bases SQLite, il n'y a que la topologie à changer:

Conclusions

J'espère que la gestion des tables attributaires vous paraîtra maintenant un peu plus claire. Cela reste cependant encore éloigné des possibilités offertes par Quantum GIS ou ESRI ArcGIS  mais cela évolue (personnellement travailler en ligne de commande me parait plus rapide et plus formateur que de pousser sur des boutons, surtout que tout peut être fait en Python).

Tous les traitements ont été effectués sur Mac OS X avec diverses versions de GRASS GIS, 6.4.2, 7.0 et Inkscape pour les figures. 

Site officiel : Database management in GRASS GIS
Site officiel : SQL support in GRASS GIS
Autres Liens : Les « geodatabases » de GRASS GIS, structure générale (LOCATION, MAPSET) et conséquences pratiques (changement de système de projection, etc.)
Autres Liens : GRASS GIS : géométries, topologies et conséquences pratiques (vecteurs, rasters, volumes)
Autres Liens : SQLite - SpatiaLite: le pourquoi du comment