13.3. Découvrir les formats de données et de champs

13.3.1. Données Raster

Les données SIG raster sont des matrices de cellules discrètes qui représentent des caractéristiques / phénomènes sur, au-dessus ou au-dessous de la surface de la Terre. Chaque cellule de la grille raster a la même taille et les cellules sont généralement carré (dans QGIS, elles seront toujours carré). Les jeux de données raster typiques incluent les données de télédétection, telles que la photographie aérienne ou l’imagerie satellite et les données modélisées, telles que l’altitude ou la température.

Contrairement aux données vecteur, les données raster n’ont généralement pas d’enregistrement de base de données associé pour chaque cellule. Elles sont géocodées par la résolution en pixels et les coordonnées X / Y d’un pixel d’angle de la couche raster. Cela permet à QGIS de positionner correctement les données sur le canevas de carte.

Le format GeoPackage est pratique pour stocker des données raster lorsque vous travaillez avec QGIS. Le format GeoTiff populaire et puissant est une bonne alternative.

QGIS utilise des informations de géoréférencement à l’intérieur de la couche raster (par exemple GeoTiff) ou un fichier world associé pour afficher correctement les données.

13.3.2. Données Vecteur

De nombreuses fonctionnalités et outils disponibles dans QGIS fonctionnent de la même manière, quelle que soit la source de données vecteur. Cependant, en raison des différences de spécifications de format (GeoPackage, ESRI Shapefile, formats de fichiers MapInfo et MicroStation, AutoCAD DXF, bases de données PostGIS, SpatiaLite, DB2, Oracle Spatial, MSSQL Spatial, et bien d’autres), QGIS peut gérer différemment certaines de leurs propriétés. La prise en charge est assurée grâce à la bibliothèque de fonctionnalités simples OGR. Cette section décrit comment travailler avec ces spécificités.

Note

QGIS prend en charge les types d’entités (multi) points, (multi) lignes, (multi) polygones, CircularString, CompoundCurve, CurvePolygon, MultiCurve, MultiSurface, tous éventuellement avec des valeurs Z et / ou M.

Vous devez également noter que certains pilotes ne prennent pas en charge certains de ces types d’entités, comme CircularString, CompoundCurve, CurvePolygon, MultiCurve, MultiSurface. QGIS les convertira.

13.3.2.1. GeoPackage

Le format GeoPackage <https://www.geopackage.org/> _ (GPKG) est indépendant de la plate-forme et est implémenté en tant que conteneur de base de données SQLite et peut être utilisé pour stocker des données vecteur et raster. Le format a été défini par l’Open Geospatial Consortium (OGC) et a été publié en 2014.

GeoPackage peut être utilisé pour stocker les éléments suivants dans une base de données SQLite:

  • entités vecteur

  • ensembles d’images raster tuilées et cartes raster

  • attributs (données non spatiales)

  • extensions

Depuis la version 3.8 de QGIS, GeoPackage peut également stocker des projets QGIS. Les couches GeoPackage peuvent avoir des champs JSON.

GeoPackage est le format par défaut pour les données vecteur dans QGIS.

13.3.2.2. format ESRI Shapefile

Le format ESRI Shapefile est toujours l’un des formats de fichiers vecteur le plus utilisé, même s’il présente certaines limites par rapport à GeoPackage et SpatiaLite, par exemple.

Un ensemble de données au format ESRI Shapefile est constitué de plusieurs fichiers. Les trois suivants sont nécessaires :

  1. .shp fichier contenant la géométrie des entités;

  2. .dbf fichier contenant les attributs au format dBase;

  3. .shx fichier d’index.

Un ensemble de données au format ESRI Shapefile peut également inclure un fichier avec un suffixe .prj, qui contient des informations sur la projection. Bien qu’il soit très utile d’avoir un fichier de projection, ce n’est pas obligatoire. Un ensemble de données au format Shapefile peut contenir des fichiers supplémentaires. Pour plus de détails, voir la spécification technique d’ESRI à l’adresse https://www.esri.com/library/whitepapers/pdfs/shapefile.pdf.

GDAL 3.1 supporte en lecture-écriture le format ESRI Shapefile compressé (shz et shp.zip).

Amélioration des performances des ensembles de données au format Shapefile d’ESRI

Pour améliorer les performances de dessin d’un ensemble de données au format ESRI Shapefile, vous pouvez créer un index spatial. Un index spatial améliorera la vitesse des zooms et des panoramiques. Les index spatiaux utilisés par QGIS ont une extension .qix.

Voici les étapes de création d’un index spatial :

  1. Charger un ensemble de données au format ESRI Shapefile (voir Le panneau Explorateur)

  2. Ouvrez la boîte de dialogue Propriétés de la couche en double-cliquant sur le nom de la couche dans la légende ou en cliquant avec le bouton droit et en choisissant Propriétés … dans le menu contextuel

  3. Dans l’onglet Source, cliquez sur le bouton Créer un index spatial

Problème de chargement de fichier .prj

Si vous chargez un ensemble de données au format ESRI Shapefile avec un fichier .prj et que QGIS n’est pas capable de lire le système de référence de coordonnées à partir de ce fichier, vous devrez définir la projection correcte manuellement dans l’onglet Propriétés de la couche ► Source de la couche en cliquant sur le bouton setProjection Choisir le CRS. Ceci est dû au fait que les fichiers .prj ne fournissent souvent pas les paramètres de projection complets tels qu’utilisés dans QGIS et listés dans le dialogue CRS.

Pour la même raison, si vous créez un nouvel ensemble de données au format ESRI Shapefile avec QGIS, deux fichiers de projection différents sont créés : un fichier .prj avec des paramètres de projection limités, compatible avec le logiciel ESRI, et un fichier .qpj, fournissant tous les paramètres du CRS. Chaque fois que QGIS trouve un fichier .qpj, il sera utilisé à la place du fichier .prj.

13.3.2.3. Fichiers de Texte Délimité

Les fichiers texte délimités sont très courants et largement utilisés en raison de leur simplicité et de leur lisibilité - les données peuvent être visualisées et modifiées dans un éditeur de texte brut. Un fichier texte délimité est constitué de données tabulaires avec des colonnes séparées par un caractère défini et des lignes séparées par des sauts de ligne. La première ligne contient généralement les noms des colonnes. Un type courant de fichier texte délimité est un CSV (Comma Separated Values), avec des colonnes séparées par des virgules. Les fichiers texte délimités peuvent également contenir des informations de position (voir Stockage des informations de géométrie dans des fichiers texte délimités).

QGIS vous permet de charger un fichier texte délimité sous forme de couche ou de table ordinaire (voir Le panneau Explorateur ou Importation d’un fichier texte délimité). Vérifiez d’abord que le fichier répond aux exigences suivantes:

  1. Le fichier doit avoir une ligne d’en-tête délimitée de noms de champs. Il doit s’agir de la première ligne des données (idéalement la première ligne du fichier texte).

  2. Si la géométrie doit être activée, le fichier doit contenir des champs qui définissent la géométrie. Ces champs peuvent avoir n’importe quel nom.

  3. Les champs de coordonnées X et Y (si la géométrie est définie par des coordonnées) doivent être spécifiés sous forme de nombre. Le système de coordonnées n’est pas important.

  4. Si vous avez un fichier CSV avec des colonnes qu ne sont pas de type texte, vous devez avoir un fichier CSVT d’accompagnement (voir la section Utilisation du fichier CSVT pour contrôler la mise en forme des champs).

Le fichier de données de point d’élévation elevp.csv dans l’exemple de jeu de données QGIS (voir la section Téléchargement de données test) est un exemple de fichier texte valide:

X;Y;ELEV
-300120;7689960;13
-654360;7562040;52
1640;7512840;3
[...]

Quelques points à noter sur le fichier texte:

  1. L’exemple de fichier texte utilise ; (point-virgule) comme délimiteur (n’importe quel caractère peut être utilisé pour délimiter les champs).

  2. La première ligne est la ligne d’en-tête. Elle contient les champs X, Y et ELEV.

  3. Aucun guillemet (") n’est utilisé pour délimiter les champs de texte

  4. Les coordonnées X sont contenues dans le champ X

  5. Les coordonnées Y sont contenues dans le champ Y

Stockage des informations de géométrie dans des fichiers texte délimités

Les fichiers texte délimités peuvent contenir des informations de géométrie sous deux formes principales:

  • Comme coordonnées dans des colonnes séparées (par exemple, Xcol, Ycol …), pour les données de géométrie ponctuelle;

  • Représentationwell-known text (WKT) de la géométrie dans une seule colonne, pour tout type de géométrie.

Les entités avec des géométries courbes (CircularString, CurvePolygon et CompoundCurve) sont prises en charge. Voici quelques exemples de types de géométrie dans un fichier texte délimité avec des géométries codées WKT

Label;WKT_geom
LineString;LINESTRING(10.0 20.0, 11.0 21.0, 13.0 25.5)
CircularString;CIRCULARSTRING(268 415,227 505,227 406)
CurvePolygon;CURVEPOLYGON(CIRCULARSTRING(1 3, 3 5, 4 7, 7 3, 1 3))
CompoundCurve;COMPOUNDCURVE((5 3, 5 13), CIRCULARSTRING(5 13, 7 15,
  9 13), (9 13, 9 3), CIRCULARSTRING(9 3, 7 1, 5 3))

Les fichiers texte délimités prennent également en charge les coordonnées Z et M dans les géométries

LINESTRINGZ(10.0 20.0 30.0, 11.0 21.0 31.0, 11.0 22.0 30.0)

Utilisation du fichier CSVT pour contrôler la mise en forme des champs

Lors du chargement de fichiers CSV, le pilote OGR suppose que tous les champs sont des chaînes (c’est-à-dire du texte) sauf indication contraire. Vous pouvez créer un fichier CSVT pour indiquer à OGR (et QGIS) le type de données des différentes colonnes:

Type

Nom

Exemple

Nombre entier

Entier

4

Nombre décimal

Réel

3.456

Date

Date (YYYY-MM-DD)

2016-07-28

Temps

Temps (HH:MM:SS+nn)

18:33:12+00

Date & Heure

DateTime (YYYY-MM-DD HH:MM:SS+nn)

2016-07-28 18:33:12+00

Le fichier CSVT est un fichier texte brut d”UNE ligne avec les types de données entre guillemets et séparés par des virgules, par exemple:

"Integer","Real","String"

Vous pouvez même spécifier la largeur et la précision de chaque colonne, par exemple:

"Integer(6)","Real(5.5)","String(22)"

Ce fichier est sauvegardé dans le même dossier que le fichier .csv, avec le même nom, mais en tant qu’extension .csvt

Vous trouverez plus d’informations dans la documentation du pilote CSV de GDAL.

13.3.2.4. Couches PostGIS

Les couches PostGIS sont stockées dans une base de données PostgreSQL. Les avantages de PostGIS sont les capacités d’indexation spatiale, de filtrage et d’interrogation. Avec l’aide de PostGIS, les fonctions vecteur telles que la sélection et l’identification sont plus précises qu’elles ne le font avec les couches OGR dans QGIS.

Astuce

Couches PostGIS

Normalement, une couche PostGIS est identifiée par une entrée dans la table geometry_columns. QGIS peut charger des couches qui n’ont pas d’entrée dans la table geometry_columns. Cela inclut à la fois les tables et les vues. Reportez-vous à votre manuel PostgreSQL pour plus d’informations sur la création de vues.

Cette section contient quelques détails sur la façon dont QGIS accède aux couches PostgreSQL. La plupart du temps, QGIS devrait simplement vous fournir une liste des tables de base de données qui peuvent être chargées, et il les chargera sur demande. Cependant, si vous rencontrez des difficultés pour charger une table PostgreSQL dans QGIS, les informations ci-dessous peuvent vous aider à comprendre les messages QGIS et vous donner des instructions pour modifier la table PostgreSQL ou afficher la définition pour permettre à QGIS de la charger.

Clé primaire

QGIS demande que les couches PostgreSQL aient un champ pouvant être utilisé comme clé unique pour la couche. Pour les tables, cela signifie qu’elles doivent avoir une clé primaire ou un champ ayant une contrainte d’unicité. De plus, QGIS impose que cette colonne soit de type int4 (un entier de 4 octets). Alternativement, la colonne ctid peut être utilisée comme clé primaire. Si une table ne respecte pas ces conditions, le champ oid sera utilisé à la place. Les performances seront améliorées si le champ est indexé (notez que les clés primaires sont automatiquement indexées dans PostgreSQL).

QGIS propose une case à cocher Sélectionner à l’id qui est activée par défaut. Cette option obtient les identifiants sans les attributs, ce qui est plus rapide dans la plupart des cas.

Vue

Si la couche PostgreSQL est une vue, les mêmes conditions s’appliquent, mais elles n’ont pas toujours de clé primaire ou de champ ayant une contrainte d’unicité. Dans ce cas, vous devez définir une clé primaire (de type entier) avant de charger la vue. Si aucun champ ne convient, QGIS ne chargera pas la vue. Si cela arrive, la solution est de modifier la vue de sorte qu’elle inclue un champ qui convient (de type entier et qui soit une clé primaire ou ayant une contrainte d’unicité, de préférence indexé).

Comme pour les tables, une case à cocher Sélectionner par identifiant est activée par défaut (voir ci-dessus pour la signification de la case à cocher). Ça peut avoir du sens de désactiver cette option lorsque vous utilisez des vues coûteuses.

Table QGIS layer_style et sauvegarde en base de données

Si vous voulez faire une sauvegarde de votre base de données PostGIS en utilisant les commandes pg_dump et pg_restore et que les styles par défaut des couches sauvés par QGIS ne sont pas restaurés, vous devez définir l’option XML à DOCUMENT et la restauration fonctionnera.

SET XML OPTION DOCUMENT;

Filtrer côté base de données

QGIS permet de filtrer les entités déjà côté serveur. Vérifier Paramètres ► Options ► Sources de données ► checkbox Exécuter les expressions côté serveur si possible pour le faire. Seules les expressions prises en charge par le serveur seront envoyées à la base de données. Les expressions utilisant des opérateurs ou des fonctions non pris en charge seront évaluées en local.

Types de données supportés par PostgreSQL

Les types de données pris en charge par le fournisseur PostgreSQL incluent: entier, flottant, booléen, objet binaire, varchar, géométrie, horodatage, tableau, hstore et json.

13.3.2.5. Importer des données dans PostgreSQL

Différents outils, notamment le Gestionnaire de bases de données (plugin DB Manager) ou les outils en ligne de commande comme sh2pgsql ou ogr2ogr, permettent d’importer les données dans une base de données PostgreSQL/PostGIS.

DB Manager

QGIS est livré avec un plugin nommé dbManager DB Manager. Il peut être utilisé pour charger des données et inclut la prise en charge des schémas. Voir la section Extension DB Manager pour plus d’informations.

shp2pgsql

PostGIS comprend un utilitaire appelé shp2pgsql, qui peut être utilisé pour importer des jeux de données au format Shapefile dans une base de données PostGIS. Par exemple, pour importer un jeu de données au format Shapefile nommé lacs.shp dans une base de données PostgreSQL nommée gis_data, utilisez la commande suivante

shp2pgsql -s 2964 lakes.shp lakes_new | psql gis_data

Cela crée une nouvelle couche nommée lacs_new dans la base de données gis_data. La nouvelle couche aura un identifiant de référence spatiale (SRID) de 2964. Voir la section Utiliser les projections pour plus d’informations sur les systèmes de référence spatiale et les projections.

Astuce

Exporter des jeux de données depuis PostGIS

Il existe également un outil pour exporter les jeux de données PostGIS au format Shapefile: pgsql2shp. Il est dans votre distribution PostGIS.

ogr2ogr

En plus de shp2pgsql et DB Manager, il existe un autre outil pour alimenter les données géographiques dans PostGIS: ogr2ogr. Il fait partie de votre installation GDAL.

Pour importer un jeu de données au format Shapefile dans PostGIS, procédez comme suit:

ogr2ogr -f "PostgreSQL" PG:"dbname=postgis host=myhost.de user=postgres
password=topsecret" alaska.shp

Cela importera le jeu de données au format Shapefile alaska.shp dans la base de données PostGIS postgis en utilisant l’utilisateur postgres avec le mot de passe topsecret sur le serveur hôte myhost.de.

Notez que OGR doit être construit avec PostgreSQL pour prendre en charge PostGIS. Vous pouvez le vérifier en tapant (dans nix)

ogrinfo --formats | grep -i post

Si vous préférez utiliser la commande COPY de PostgreSQL au lieu de la méthode INSERT INTO par défaut, vous pouvez exporter la variable d’environnement suivante (au moins disponible sur nix et osx)

export PG_USE_COPY=YES

ogr2ogr ne crée pas d’index spatial comme le fait shp2pgsl. Vous devez les créer manuellement, en utilisant la commande SQL normale CREATE INDEX par la suite, comme étape supplémentaire (comme décrit dans la section suivante Améliorer les performances).

Améliorer les performances

La récupération des entités d’une base de données PostgreSQL peut prendre beaucoup de temps, en particulier sur un réseau. Vous pouvez améliorer les performances de dessin des couches PostgreSQL en vous assurant qu’un index spatial PostGIS existe sur chaque couche de la base de données. PostGIS prend en charge la création d’un index GiST (Generalized Search Tree) pour accélérer la recherche spatiale (les informations d’index GiST sont extraites de la documentation PostGIS disponible sur https://postgis.net).

Astuce

Vous pouvez utiliser DBManager pour créer un index pour votre couche. Vous devez d’abord sélectionner la couche et cliquer sur Table ► Modifier la table, puis allez dans l’onglet Index et cliquez sur Ajouter un index spatial.

La syntaxe pour créer un index GiST est

CREATE INDEX [indexname] ON [tablename]
  USING GIST ( [geometryfield] GIST_GEOMETRY_OPS );

Notez que pour les grandes tables, la création de l’index peut prendre du temps. Une fois l’index créé, vous devez effectuer une commande VACCUM ANALYSE. Voir la documentation PostGIS (POSTGIS-PROJECT dans Bibliographie) pour plus d’informations.

L’exemple suivant crée un index GiST

gsherman@madison:~/current$ psql gis_data
Welcome to psql 8.3.0, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

gis_data=# CREATE INDEX sidx_alaska_lakes ON alaska_lakes
gis_data-# USING GIST (the_geom GIST_GEOMETRY_OPS);
CREATE INDEX
gis_data=# VACUUM ANALYZE alaska_lakes;
VACUUM
gis_data=# \q
gsherman@madison:~/current$

13.3.2.6. Couches vecteur franchissant la ligne des 180° de longitude

De nombreux progiciels SIG n’intègrent pas les cartes vecteur avec un système de référence géographique (lat/lon) qui traverse la ligne de 180 degrés de longitude (http://postgis.refractions.net/documentation/manual-2.0/ST_Shift_Longitude.html). Par conséquent, si nous ouvrons une telle carte dans un QGIS, nous pourrions voir deux endroits très éloignés l’un de l’autre, qui devraient apparaître à proximité l’un de l’autre. Dans Fig. 13.23, le point minuscule à l’extrême gauche du canevas de la carte (îles Chatham) devrait se trouver à l’intérieur du quadrillage, à droite des îles principales de la Nouvelle-Zélande.

../../../_images/vectorNotWrapping.png

Fig. 13.23 Carte en lat/lon de part et d’autre de la ligne des 180° longitude

Une solution est de transformer les valeurs longitudinales en utilisant PostGIS et la fonction ST_Shift_Longitude. Cette fonction lit chaque point/sommet de chacune des entités dans une géométrie et si la coordonnée de longitude est inférieure à 0°, elle lui ajoute 360°. Le résultat est une version 0° - 360° des données sur une carte centrée à 180°.

../../../_images/vectorWrapping.png

Fig. 13.24 Traversée de la longitude 180° en utilisant la fonction ST_Shift_Longitude

Usage

  • Importer des données dans PostGIS (Importer des données dans PostgreSQL) en utilisant, par exemple, l’extension DB Manager.

  • Utiliser l’interface en ligne de commande PostGIS pour exécuter la commande suivante (dans cet exemple, « TABLE » est bien le nom de votre table PostGIS): gis_data=# update TABLE set the_geom=ST_Shift_Longitude(the_geom);

  • Si tout s’est bien passé, vous devriez recevoir une confirmation sur le nombre d’entités qui ont été mises à jour. Ensuite, vous pouvez charger la carte et voir la différence (Figure_vector_crossing_map).

13.3.2.7. Couches SpatiaLite

Si vous souhaitez enregistrer une couche vecteur en utilisant le format SpatiaLite, vous pouvez le faire en suivant les instructions sur Création de nouvelles couches à partir d’une couche existante. Vous sélectionnez SpatiaLite comme Format et entrez les deux Nom de fichier et Nom de coouche.

Vous pouvez également sélectionner SQLite comme format, puis ajouter SPATIALITE=YES dans le Options personnalisées -> Source de données. Cela indique à GDAL de créer une base de données SpatiaLite. Voir également https://gdal.org/drivers/vector/sqlite.html.

QGIS prend également en charge les vues modifiables dans SpatiaLite. Pour la gestion des données SpatiaLite, vous pouvez également utiliser le plugin principal Gestionnaire de bases de données.

Si vous souhaitez créer une nouvelle couche SpatiaLite, référez-vous à la section Créer une nouvelle couche SpatiaLite.

13.3.2.8. Paramètres spécifiques à GeoJSON

Quand vous exportez des couches vers GeoJSON, vous sont proposées des Options de couche spécifiques. Ces options proviennent de GDAL qui est responsable de l’écriture du fichier:

  • COORDINATE_PRECISION le nombre maximum de chiffres après le séparateur décimal pour écrire en coordonnées. La valeur par défaut est 15 (remarque: pour les coordonnées de Lat Lon, 6 est considéré comme suffisant). Une troncature se produira pour supprimer les zéros de fin.

  • RFC7946 par défaut GeoJSON 2008 sera utilisé. S’il est défini sur OUI, la norme RFC 7946 mise à jour sera utilisée. La valeur par défaut est NO (donc GeoJSON 2008). Voir https://gdal.org/drivers/vector/geojson.html#rfc-7946-write-support pour les principales différences, en bref : seul EPSG: 4326 est autorisé, les autres SCR seront transformés, les polygones seront écrits comme pour suivre la règle de droite pour l’orientation, les valeurs d’un tableau « bbox » sont [ouest, sud, est, nord], pas [minx, miny, maxx, maxy]. Certains noms d’extension sont interdits dans les objets FeatureCollection, Feature et Geometry, la précision des coordonnées par défaut est de 7 chiffres décimaux

  • WRITE_BBOX défini sur YES pour inclure la boîte englobante des géométries au niveau de l’entité et de la collection d’entités

Outre GeoJSON, il existe également une option d’exportation vers « GeoJSON - Newline Delimited » (voir https://gdal.org/drivers/vector/geojsonseq.html). Au lieu d’une FeatureCollection avec des Features, vous pouvez diffuser un type (probablement uniquement Features) séparés séquentiellement avec des retours à la ligne.

GeoJSON - Newline Delimited propose également des options de couche spécifiques:

  • COORDINATE_PRECISION voir ci-dessus (comme pour GeoJSON)

  • RS s’il faut commencer les enregistrements avec le caractère RS = 0x1E. La différence réside dans la façon dont les entités sont séparées: uniquement par un caractère de nouvelle ligne (LF) (JSON délimité par une nouvelle ligne, geojsonl) ou en ajoutant également un caractère séparateur d’enregistrement (RS) (donnant des séquences de texte GeoJSON, geojsons). Par défaut à NO. Les fichiers reçoivent l’extension .json si l’extension n’est pas fournie.

13.3.2.9. Couches DB2 Spatial

Les produits IBM DB2 pour Linux, Unix et Windows (DB2 LUW), IBM DB2 pour z / OS (mainframe) et IBM DashDB permettent aux utilisateurs de stocker et d’analyser des données spatiales dans des colonnes de table relationnelle. Le fournisseur DB2 pour QGIS prend en charge la gamme complète de visualisation, d’analyse et de manipulation des données spatiales dans ces bases de données.

La documentation utilisateur sur ces fonctionnalités se trouve dans le DB2 z/OS KnowledgeCenter, DB2 LUW KnowledgeCenter et DB2 DashDB KnowledgeCenter.

Pour plus d’informations sur l’utilisation des capacités spatiales DB2, consultez le DB2 Spatial Tutorial sur IBM DeveloperWorks.

Le fournisseur DB2 ne prend actuellement en charge que l’environnement Windows via le pilote ODBC Windows.

Le client exécutant QGIS doit avoir l’un des éléments suivants installé:

  • DB2 LUW

  • IBM Data Server Driver Package

  • IBM Data Server Client

Pour ouvrir une donnée DB2 dans QGIS, consultez la section Le panneau Explorateur ou Chargement d’une couche de base de données.

Si vous accédez à une base de données DB2 LUW sur la même machine ou utilisez DB2 LUW en tant que client, les exécutables DB2 et les fichiers de prise en charge doivent être inclus dans le chemin Windows. Cela peut être fait en créant un fichier batch comme le suivant avec le nom db2.bat et en l’incluant dans le répertoire % OSGEO4W_ROOT%/etc/ini

@echo off
REM Point the following to where DB2 is installed
SET db2path=C:\Program Files (x86)\sqllib
REM This should usually be ok - modify if necessary
SET gskpath=C:\Program Files (x86)\ibm\gsk8
SET Path=%db2path%\BIN;%db2path%\FUNCTION;%gskpath%\lib64;%gskpath%\lib;%path%