Réponse courte

Une file geodatabase (.gdb) est le conteneur propriétaire d'Esri — en réalité un dossier de fichiers binaires — conçu pour ArcGIS et riche en capacités propres à Esri : topologie de géodatabase, domaines d'attributs et sous-types, classes de relations, réseaux et archivage. Un GeoPackage (.gpkg) est une norme ouverte de l'OGC : un unique fichier de base de données SQLite pouvant contenir de nombreuses couches vectorielles, des tuiles raster, des attributs et des métadonnées, que pratiquement tous les SIG modernes lisent et écrivent nativement.

La règle pratique : si votre projet vit au sein de l'écosystème Esri et a besoin de la topologie, des domaines ou des réseaux de la géodatabase, utilisez une file geodatabase. Pour tout le reste — échange entre logiciels, projet multicouche portable, livraison client, archive à long terme — le GeoPackage est le choix par défaut le plus sûr car c'est un seul fichier ouvert, sans SDK propriétaire entre vous et vos données.

Ce que chaque format est réellement

File geodatabase — un dossier, pas un fichier

Une .gdb est un répertoire contenant des dizaines de fichiers binaires .gdbtable, .gdbtablx, .atx et d'index. Vous n'y touchez jamais individuellement ; ArcGIS traite le dossier comme une seule base de données. À l'intérieur, vous pouvez stocker des classes d'entités, des jeux de classes d'entités (groupes partageant un SCR, utilisés pour la topologie et les réseaux), des jeux de données raster et des jeux mosaïque, des tables, des domaines d'attributs (contraintes de valeurs codées/par plages), des sous-types et des classes de relations (liens formels un-à-plusieurs entre tables). Elle prend en charge les règles de topologie de géodatabase appliquées entre classes d'entités — précieuses pour la cartographie géologique où les polygones d'unités ne doivent ni présenter de lacunes ni se chevaucher, et où les contacts doivent coïncider avec les limites de polygones.

Le format est propriétaire. Esri publie une File Geodatabase API ouverte, et le pilote OpenFileGDB de GDAL offre une large prise en charge ouverte en lecture (et de plus en plus en écriture), mais les comportements les plus riches — validation de topologie, application des domaines, réseaux — se concrétisent dans ArcGIS. L'ancienne personal geodatabase (.mdb, basée sur Access) est obsolète ; aujourd'hui « geodatabase » signifie file ou enterprise.

GeoPackage — un fichier SQLite, entièrement spécifié

Un .gpkg est un unique fichier SQLite 3 conforme à la norme GeoPackage de l'OGC. La spécification définit des tables système requises : gpkg_spatial_ref_sys (définitions de SCR), gpkg_contents (le catalogue des couches) et gpkg_geometry_columns, ainsi que l'encodage des géométries (un petit en-tête binaire suivi de WKB). Comme la norme est publique, les logiciels l'implémentent directement — aucun SDK Esri requis. Un seul .gpkg peut porter plusieurs couches vectorielles, des pyramides de tuiles/raster, des tables d'attributs uniquement et des métadonnées, le tout dans ce fichier unique. Les géométries sont stockées avec un identifiant SRS explicite par couche, et l'indexation spatiale utilise le R-tree de SQLite.

Deux conséquences de SQLite comptent sur le plan opérationnel : un GeoPackage est une véritable base de données interrogeable en SQL, mais il est en écriture unique — SQLite verrouille tout le fichier pendant une écriture, ce n'est donc pas un substitut à une base de données serveur multi-utilisateurs comme PostGIS.

Face à face sur ce qui pose problème

  • Ouverture : GeoPackage est une norme de l'OGC, entièrement documentée ; la file geodatabase est propriétaire avec un outillage ouvert partiel.
  • Fichier unique vs dossier : .gpkg est un seul fichier (facile à envoyer par e-mail, copier, nommer par version) ; .gdb est un dossier qu'il faut compresser pour transférer et qui se casse s'il est copié partiellement.
  • Prise en charge multi-logiciels : GeoPackage se lit/s'écrit partout (QGIS, GDAL, ArcGIS, R, Python) ; la file geodatabase s'écrit au mieux dans ArcGIS et se lit largement via GDAL.
  • Limites de taille : une file geodatabase passe à l'échelle de très grands jeux de données (téraoctets ; 1 To par jeu de données par défaut, relevable) et a historiquement surpassé nettement les shapefiles. GeoPackage (SQLite) prend aussi en charge de très gros fichiers (la limite théorique de SQLite est d'environ 281 To), mais les performances pratiques en écriture unique et l'absence de fonctionnalités d'entreprise natives plafonnent les usages lourdement concurrents.
  • Modèle de données avancé : topologie, domaines, sous-types, classes de relations, réseaux — la file geodatabase les possède nativement ; GeoPackage les modélise avec de simples tables/contraintes, ou vous les portez vers PostGIS.
  • Limites de nom/longueur de champ : ni l'un ni l'autre ne souffre des limites du shapefile (noms de champs à 10 caractères et texte à 254 caractères), tous deux sont donc des progrès majeurs par rapport au shapefile pour une géologie riche en attributs.

Raster, performances et la réalité SQLite

Les deux formats contiennent du raster comme du vectoriel. Une file geodatabase stocke des jeux de données raster et des jeux mosaïque qu'ArcGIS gère efficacement à grande échelle. GeoPackage stocke le raster sous forme de pyramides de tuiles (gpkg_tile_matrix), bien adaptées aux tuiles de carte pré-rendues et aux aperçus, mais il n'est pas un conteneur raster analytique généraliste — pour l'analyse raster lourde, la plupart conservent l'altitude et l'imagerie en GeoTIFF/COG et y font référence, ne mettant que les données vectorielles et de tuiles dans le .gpkg.

Sur les performances, le résumé honnête est que les deux surpassent largement les shapefiles et conviennent aux tailles de projet typiques (de dizaines de milliers à quelques millions d'entités). La file geodatabase a un long historique sur de très grands jeux de données dans ArcGIS, avec une indexation spatiale mature. Les performances de GeoPackage dépendent de SQLite : un index spatial R-tree (gpkg_rtree_index) rend les requêtes spatiales rapides, mais le verrou en écriture unique l'empêche de passer à l'échelle de l'édition concurrente. Un modèle mental utile : GeoPackage est un brillant conteneur de transport et de travail mono-utilisateur ; pour un véritable travail multi-utilisateurs, transactionnel et côté serveur, vous passez à PostGIS, qui partage une grande partie du même vocabulaire SQL (ST_Transform, ST_Intersects), de sorte que le saut conceptuel est faible.

Exemple concret : conversion et conditionnement

Vous recevez un project.gdb avec trois classes d'entités (unités, failles, stations) et devez en faire un livrable portable, mono-fichier.

Inspectez-le d'abord :

ogrinfo project.gdb           # liste les classes d'entités (couches)
ogrinfo -al -so project.gdb units   # schéma + SCR d'une couche

Convertissez toutes les couches dans un seul GeoPackage :

ogr2ogr -f GPKG project.gpkg project.gdb        # copie chaque couche
# ou couche par couche pour contrôler noms/SCR :
ogr2ogr -f GPKG project.gpkg project.gdb units -nln geo_units -t_srs EPSG:32632
ogr2ogr -f GPKG -append project.gpkg project.gdb faults -nln geo_faults
ogr2ogr -f GPKG -append project.gpkg project.gdb stations -nln field_stations

Le sens inverse (GeoPackage vers file geodatabase) est mieux réalisé dans ArcGIS (Classe d'entités vers classe d'entités / Export), car le chemin d'écriture riche y réside. Après toute conversion, vérifiez le résultat :

ogrinfo -al -so project.gpkg   # confirmez nombre de couches, types de géométrie, SCR, noms de champs

Dans QGIS, vous pouvez faire de même via Exporter → Enregistrer les entités sous → GeoPackage, mais pour une livraison reproductible, la ligne ogr2ogr est auditable et ré-exécutable.

Pièges courants et pourquoi ils surviennent

  • Copier une .gdb comme si c'était un fichier. Ne copier qu'une partie des fichiers internes corrompt la géodatabase ; elle doit être déplacée/compressée comme un dossier entier. Compressez le répertoire.
  • S'attendre à ce que topologie/domaines survivent à l'export. Convertir .gdb → .gpkg conserve géométrie et attributs mais abandonne les règles de topologie, domaines, sous-types et classes de relations propres à Esri ; ils sont appliqués par ArcGIS, pas par les octets. Documentez ou recréez les contraintes dans le système cible.
  • Traiter GeoPackage comme une base multi-utilisateurs. Le verrou d'écriture sur tout le fichier de SQLite fait que les éditeurs concurrents entrent en collision. Pour un travail multi-éditeurs, utilisez PostGIS, pas un .gpkg partagé.
  • Dérive de nom de champ / d'encodage à la conversion. Les noms réservés, la casse ou un texte non-UTF-8 peuvent changer pendant la conversion. Vérifiez schéma et encodage après ogr2ogr.
  • Supposer que « l'export a réussi » signifie « les données sont propres ». Une écriture réussie ne valide ni la géométrie ni le SCR. Exécutez ensuite ogrinfo / des contrôles de géométrie.

AQ avant de faire confiance au résultat

  • Confirmez que le nombre de couches, les types de géométrie et le SCR correspondent à la source (ogrinfo -al -so).
  • Validez la géométrie (pas d'auto-intersections, orientation correcte) et le schéma d'attributs (noms de champs, types, encodage) après conversion.
  • Vérifiez que l'ordre des coordonnées et le SCR sont corrects en contrôlant une entité connue par rapport à une couche de référence.
  • Pour les livrables, incluez un court README/métadonnées notant source, SCR, schéma, date et toute contrainte non transférée.
  • Vérifiez que le logiciel du destinataire peut à la fois ouvrir et maintenir le format, pas seulement le prévisualiser.

Le point de vue de Bathyl

Nous choisissons GeoPackage par défaut pour la livraison et l'archivage, car un unique fichier SQLite ouvert survit au transfert entre QGIS, ArcGIS, Python et l'archive d'un client sans dépendance propriétaire. Nous ne conservons une file geodatabase que lorsqu'une fonctionnalité propre à Esri — topologie de géodatabase, domaines ou réseaux — est réellement requise, et nous notons dans les notes de livraison exactement quelles contraintes vivent dans le format et lesquelles sont appliquées par le logiciel.

Lectures complémentaires

Sources