Blog SIG & Territoires

Dans l’article précédent (Cohabitation ArcGis-QGis: les données vecteur ) nous avons vu comment utiliser les données d’ArcGis (shapefile, geodabase personnelle et geodatabase fichier) dans QGis. Dans cet article nous allons voir l’étape suivante, c’est à dire la migration de ces formats vers des formats plus en accord avec l’architecture autour de QGis.

Nous allons essayer de répondre à deux questions:

• vers quel format migrer vos données?
• avec quel(s) outil(s) effectuer cette migration?

Nous prendrons en compte les trois formats mentionnés:

• shapefile,
• geodabase personnelle et
• geodatabase fichier

Nous avons laissé de côté deux sujets, qu’il faudra bien aborder lors d’une migration complète: les données raster et, si c’est le cas, les geodatabase entreprise.

Migration des shapefiles

Vous pouvez vous demander si cette question est pertinente,car le format shapefile est presque le format le plus courant pour QGis. Toutes les commandes et outils de QGis travaillent avec ce format.

Ce qu’il faut savoir c’est que, si bien il n’est pas indispensable de changer de format si vos données sont sous la forme de shapefiles, le changement de logiciel est une bonne opportunité pour changer ses vieilles habitudes.

Voici le répertoire d’un projet assez simple où on a 18 couches sous formes de shapefiles:

Et voici le même projet mais en utilisant le format Geopackage:

Et comment on voit ce format dans le panneau Explorateur de QGis:

Geopackage est un format de données vecteur et raster basé sur SQLite. C’est un format de base de données mais qui est transparent pour l’utilisateur. SQLite est installé par défaut par les logiciels qui l’utilisent.

Dans QGis, vous pouvez travailler directement à partir des outils classiques. Vous pouvez sauvegarder avec ce format simplement en le choisissant dans la fenêtre d’export de données:

Mais vous pouvez aussi le gérer à partir du Gestionnaire de bases de données (DB Manager):

Avec ce gestionnaire vous pouvez travailler directement en SQL sur vos tables ainsi que sur vos géométries. La version utilisée par QGis est Spatialite ce qui correspond à la base de données SQLite et l’extension spatiale, tout comme PostgreSQL et Postgis.

Ceci vous permet, par exemple, de valider de manière complète les géométries de vos couches:

Pour plus de détails sur la validation des géométries avec Spatialite, référez-vous à l’article Les outils SIG de validation des géométries(2) : Spatialite et PostGis.

Nous verrons dans la deuxième partie de cette article comment effectuer cette migration, mais sachez déjà qu’une ligne de commande suffit à transformer votre répertoire de shapefiles en fichier geopackage.

Migration des geodatabases personnelles (.mdb) ou fichier (.gdb)

Si vous travaillez avec des geodatabases (personnelles ou fichier) vous avez déjà franchi le pas du chapitre précédent et passé d’une gestion de couches individuelles à une gestion de couches de base de données.

Il se peut que vous ayez franchi ce pas pour simplifier la gestion des fichiers et ne pas avoir de multiples fichiers pour chaque projet. Ou il se peut que vous soyez vraiment passé à une gestion de base de données relationnelle en exploitant la puissance de celles-ci.

Par exemple, vous pouvez avoir mis en place des procédures qui accèdent directement à la base de données Access, sans passer par ArcGis., ou des traitements de validation multi-tables.

Dans l’architecture autour de QGis, il y a deux options les plus courantes: les fichiers geopackage et les bases de données Postgis.

La première option est une option légère. Pas d’apprentissage, pas d’installation ni configuration, bref c’est vraiment l’équivalent de la geodatabase personnelle d’ArcGis. Excepté en ce qui concerne les limites de taille: tandis que la geodatabase personnelle est limitée à 2 Go, les base SQLite (format utilisé par geopackage) sont limitées à 140 To. Une autre différence que nous verrons dans l’article consacré à la migration des donnée raster est que les rasters sont vraiment inclus dans la base SQLite. En ce qui concerne la geodabase personnelle les rasters sont en réalité stockés dans des fichiers cachés, en dehors de la base Access.

Mais si la base Access d’ArcGis commençait à vous faire sentir à l’étroit, la deuxième option (PostgreSQL/Postgis) mérite peut être votre attention. Les bases PostgreSQL sont l’équivalent des bases de données entreprise d’ArcGis. Bien sûr, la mise en place nécessite le développement de compétences, mais les possibilités qui s’ouvrent sont énormes.

L’avantage par rapport à ArcGis Server ou Enterprise, c’est que vous pouvez installer le logiciel et commencer à travailler en quelques minutes. Vous pouvez l’installer sur votre PC et apprendre à l’utiliser, avant de passer à l’installation de production sur un serveur. Pour plus de détails sur la mise en place de PostgreSQL/Postgis, référez-vous à l’article Débuter avec Postgres/Postgis .

Un autre avantage des bases PostgreSQL avec QGis est que, à la différence d’ArcGis, QGis utilise la base de données native, sans surcouche (ArcSDE) et donc rendant beaucoup plus simple le travail.

L’outil de migration GDAL-ogr

Malgré notre habitude et notre préférence pour les interfaces graphiques, il reste encore des domaines où la vieille ligne de commande nous permet de gagner du temps et des efforts.

Le changement de format pour les données spatiales avec QGis en est un. Bien sûr, vous pourrez faire (presque) tout à partir des outils de QGis, mais vous verrez avec quelques exemple que c’est plus pratique de se lancer dans la ligne de commande.

Tout d’abord, rappelons que QGis s’appuie pour la lecture et écriture des fichiers de données sur la bibliothèque GDAL. Nous allons donc utiliser la même bibliothèque, mais en ligne de commande.

La commande GDAL qui fait une transformation d’un format en un autre est ogr2ogr. Vous trouverez la documentation complète de cette commande à l’adresse https://gdal.org/programs/ogr2ogr.html

Mais sa structure est très simple, à la base:

ogr2ogr -f Format_de_sortie Fichier_de_sortie Fichier_en_entrée

Pour travailler en ligne de commande il vous faut ouvrir une fenêtre de Shell à partir de la barre de tâches QGis:

Migration de shapefiles vers Geopackage

Pour passer du format shapefile vers le format gpkg une couche shapefile il suffit de rentrer la ligne de commande

ogr2ogr -f GPKG c:/ArcGis/migrer/test.gpkg c:/ArcGis/migrer/surface_eau.shp

Cette commande crée ou écrase le fichier en sortie test.gpkg et intègre les données du fichier surface_eau.shp en tant que table nommée surface_eau dans le fichier gpkg.

Si le fichier gpkg existe déjà et que nous voulons rajouter des données sans écraser le contenu existant, il suffit de rajouter l’option -append

ogr2ogr -f GPKG c:/ArcGis/migrer/test.gpkg c:/ArcGis/migrer/surface_eau.shp -append

Et si nous voulons intégrer tous les shapefiles présent dans le répertoire avec une seule instruction, il suffit de mettre seulement le chemin du répertoire

ogr2ogr -f GPKG c:/ArcGis/migrer/test.gpkg c:/ArcGis/migrer/

Migration vers Postgresql/Postgis

Il est tout aussi simple de migrer des données vers une base de données Postgresql/Postgis.

La seule contrainte est que la base de données doit exister (la commande ne peut pas créer la base) et, si vous souhaitez créer les tables dans un autre schéma que le schéma par défaut, le schéma doit avoir été créé auparavant.

A partir d’une geodatabase fichier, la commande de base est

ogr2ogr -f « PostgreSQL » PG: »host=servername port=5432 user=’username‘ password=’password‘ dbname=’PostGISDBName‘ » fichier.gdb

PG: »… » est la chaîne de connexion à votre base de données Postgresql

Toutes les tables vecteur de votre geodatabase fichier seront copiées vers le schéma par défaut(public) de votre base Postgresql. Les tables raster de la geodatabase seront ignorées.

Si vous souhaitez que la destination des tables soit un autre schéma de votre base, il faut rajouter le paramètre -lco SCHEMA=nom_du_schéma:

ogr2ogr -f « PostgreSQL » PG: »host=servername port=5432 user=’username‘ password=’password‘ dbname=’PostGISDBName‘ » -lco SCHEMA=nom_du_schéma fichier.gdb

A cette commande de base on peut ajouter une série d’options. Vous trouverez une description détaillée sur ce lien: https://gdal.org/drivers/vector/pg.html.

Vous remarquerez que la commande charge le dernier élément (fichier.gdb). Vous n’avez pas besoin d’indiquer le format des données que vous voulez charger, GDAL identifiant le format en fonction de l’extension.

Pour charger un shapefile, alors, il suffit de modifier ce dernier élément:

ogr2ogr -f « PostgreSQL » PG: »host=servername port=5432 user=’username‘ password=’password‘ dbname=’PostGISDBName‘ » -lco SCHEMA=nom_du_schéma fichier.shp

Ou bien pour charger tous les shapefiles d’un répertoire, comme on l’a vu plus haut, il suffit de renter le chemin du répertoire:

ogr2ogr -f « PostgreSQL » PG: »host=servername port=5432 user=’username‘ password=’password‘ dbname=’PostGISDBName‘ » -lco SCHEMA=nom_du_schéma c:/chemin/

Pour une geodatabase personnelle (.mdb)

ogr2ogr -f « PostgreSQL » PG: »host=servername port=5432 user=’username‘ password=’password‘ dbname=’PostGISDBName‘ » -lco SCHEMA=nom_du_schéma fichier.mdb

Ce qu’il faut savoir sur la migration d’une geodabase ESRi vers une base de données Postgresql c’est que la notion de jeu de classes d’entités (Feature Dataset) n’existe pas. Toutes les tables de la geodatabase ,les classes d’entités (Feature Class), seront copiées dans le même schéma.

La migration de la geodatabase suivante:

Donnera la base de données Postgresql suivante:

Les tables se retrouvent toutes au même niveau et les rasters ont été ignorés.

N’oubliez pas les tests de validité des géométries. Vous serez surpris du nombre d’erreurs que l’on trouve lors de la migration.

Si cet article vous a intéressé et que vous pensez qu'il pourrait bénéficier à d'autres personnes, n'hésitez pas à le partager sur vos réseaux sociaux en utilisant les boutons ci-dessous. Votre partage est apprécié !

Atilio Francois