GeoPackage ou Shapefile : le match des formats SIG

GeoPackage ou Shapefile: le match des formats SIG

Ce sont des contraintes qui déforment les données, fragilisent les échanges et ralentissent les traitements SIG dès qu’un levé GNSS, un cadastre technique ou un inventaire patrimonial prend de l’ampleur.

Le GeoPackage ne rend pas le Shapefile inutilisable. Il rend ses compromis difficiles à justifier pour la production courante. Le premier est un standard OGC fondé sur SQLite, conçu comme un conteneur spatial moderne. Le second est un héritage des années 1990, encore très présent dans les chaînes d’échange. Le choix du format de données SIG GeoPackage ou Shapefile se joue donc sur des limites mesurables: structure, attributs, indexation, intégrité et compatibilité réelle avec le parc logiciel.

Le Shapefile: une architecture historique qui contraint la donnée

Le Shapefile a été développé par Esri au début des années 1990. Il reste lisible par une quantité considérable de logiciels SIG, de logiciels de DAO et d’applications métier. C’est sa force. Mais son architecture n’a pas été pensée pour les flux actuels de données géographiques.

Un Shapefile valide n’est pas un fichier. C’est au minimum un triplet indissociable:

• le fichier .shp, qui stocke les géométries;
• le fichier .shx, qui contient l’index des géométries;
• le fichier .dbf, qui porte les attributs.

Dans une livraison terrain, ce triplet est souvent accompagné d’un fichier de projection, d’informations d’encodage et parfois de fichiers complémentaires générés par le logiciel. Le problème n’est pas esthétique. Il est opérationnel: un .dbf oublié, un .shx écrasé ou un fichier déplacé hors de son répertoire rompt la couche.

Pour une équipe de topographie, cette fragilité apparaît vite. Une couche de points implantés part vers le bureau d’études. Les géométries arrivent, mais pas les attributs. Ou la projection est absente. Ou deux versions du même jeu de fichiers circulent dans des dossiers différents. Le logiciel ouvre quelque chose; il n’ouvre pas nécessairement la bonne donnée, ni dans le bon système de coordonnées.

Le Shapefile impose aussi une logique de couche unique. Un fichier porte des points, ou des lignes, ou des polygones. Pas les trois dans un même conteneur. Un projet de récolement avec points de contrôle, axes, emprises, surfaces calculées et tables de codification doit donc être fragmenté en plusieurs jeux de fichiers.

Cette fragmentation ne gêne pas un échange ponctuel et simple. Elle devient un défaut structurel pour la gestion de données géospatiales.

Le Shapefile transporte encore des données. Il ne protège pas suffisamment leur contexte.

Les limites du DBF ne sont pas théoriques

La table attributaire d’un Shapefile repose sur le format dBASE. C’est là que les pertes les plus discrètes se produisent.

Les noms de champs sont limités à dix caractères. Un attribut comme DATE_RECEPTION, ALTITUDE_ORTHO ou STATUT_IMPLANTATION doit être raccourci. Le résultat est rarement propre: DATE_RECEP, ALT_ORTHO, STAT_IMPL. Après deux exports et une reprise dans une application métier, la lisibilité du modèle de données se dégrade.

La limite de 255 champs est tout aussi concrète. Une base de relevés de réseaux, un inventaire d’ouvrages ou une couche de mobilier urbain peut atteindre ce seuil sans excès. Les équipes contournent alors le problème en séparant les thèmes ou en créant des tables annexes. Cela multiplie les jointures, les identifiants et les risques de désalignement.

Le traitement des valeurs absentes est plus critique encore. Le Shapefile ne gère pas les vraies valeurs nulles dans les champs numériques. Un champ vide peut être converti en zéro. Or zéro n’est pas une absence de mesure.

Dans un levé, la différence est nette:

• une cote égale à 0,00 m peut correspondre à une valeur mesurée dans le référentiel du projet;
• une cote non renseignée signifie qu’aucune mesure exploitable n’est disponible;
• une précision horizontale nulle peut être interprétée comme une valeur parfaite, alors qu’elle résulte parfois d’un champ vide converti.

Confondre ces états fausse un filtrage, une requête ou un calcul de contrôle. Dans un logiciel SIG, une donnée incomplète n’est pas une donnée nulle. Le format doit préserver cette distinction.

GeoPackage: un conteneur spatial, pas un assemblage de fichiers

Le GeoPackage, identifié par l’extension .gpkg, est un standard ouvert publié par l’Open Geospatial Consortium en 2014. Il s’appuie sur SQLite. Sa logique est celle d’une base de données embarquée: un seul fichier, structuré, capable de contenir plusieurs objets géographiques et leurs métadonnées.

QGIS l’a adopté comme format vectoriel par défaut à partir de sa version 3. Ce choix n’est pas une préférence d’interface. Il répond aux limites du Shapefile dans les projets courants.

Un même GeoPackage peut contenir:

• plusieurs couches vectorielles de géométries différentes;
• des points de calage, des lignes de rupture, des polygones d’emprise et des couches de contrôle;
• des tables attributaires sans géométrie, utiles pour les nomenclatures, codifications ou correspondances;
• des tuiles raster;
• les systèmes de référence et la structure nécessaire à l’exploitation des tables.

Une mission peut donc être regroupée dans un conteneur unique. Le fichier ne remplace pas une politique d’archivage. Il réduit simplement les ruptures mécaniques entre géométrie, attributs et tables associées.

La différence Shapefile GeoPackage ne se résume donc pas au nombre de fichiers. Elle porte sur le modèle de stockage. Le Shapefile juxtapose géométrie, index et attributs. Le GeoPackage les organise dans une base relationnelle légère.

Le fichier unique réduit les erreurs de transfert, pas les exigences de méthode

Le conteneur unique est l’argument le plus visible du GeoPackage. Il est aussi le plus mal compris.

Un fichier .gpkg peut être copié, contrôlé par empreinte, archivé et transmis sans avoir à vérifier si les composants associés sont présents. Sur un chantier où les données passent d’une tablette de collecte à un poste SIG, puis à un logiciel de DAO, cette réduction du nombre d’objets est utile. Elle diminue les erreurs de manipulation ordinaires.

Mais un GeoPackage n’est pas invulnérable. Toute base SQLite reste un fichier qu’il faut fermer correctement, sauvegarder et versionner. Une synchronisation cloud exécutée pendant une écriture active peut créer un conflit ou une copie incomplète. Le format réduit les causes de rupture liées à la dispersion des fichiers; il ne compense pas une discipline de production absente.

La bonne pratique consiste à séparer clairement trois états:

1. Le fichier de production. Il est modifié par l’opérateur ou l’équipe SIG. Une seule instance doit être considérée comme référence à un instant donné.

2. Le fichier de diffusion. Il est figé, contrôlé, puis transmis à un donneur d’ordre, un bureau d’études ou une collectivité.

3. Le fichier d’archivage. Il est conservé avec son système de coordonnées, ses métadonnées de mission et, si nécessaire, les exports de compatibilité.

Cette méthode fonctionne également avec des Shapefiles, mais elle est plus robuste avec un GeoPackage parce que le jeu de données est matériellement regroupé.

Le gain de taille est secondaire mais réel. Selon les contenus, un GeoPackage peut être environ 1,1 à 1,3 fois plus léger qu’un ensemble Shapefile équivalent. Ce ratio ne doit pas servir de promesse universelle: la nature des géométries, les index, les champs et les données raster modifient le résultat. En pratique, le bénéfice déterminant reste l’intégrité du paquet de données.

Un fichier unique ne garantit pas une donnée juste. Il garantit seulement qu’elle se perd moins facilement entre deux postes.

Attributs, encodage et indexation: là où le format décide de la fiabilité

Un logiciel SIG ne travaille pas seulement des formes. Il interroge des attributs, filtre des objets, calcule des surfaces, joint des tables et contrôle des incohérences. Les limites historiques du Shapefile affectent directement ces opérations.

Dix caractères ne suffisent pas à décrire une donnée métier

Le raccourcissement des noms de champs semble anodin tant que la couche ne contient que ID, TYPE et DATE. Il devient destructeur avec des modèles métiers plus riches.

Prenons une couche d’ouvrages relevés au GNSS. Elle peut nécessiter des champs comme:

• identifiant_ouvrage;
• classe_precision;
• mode_acquisition;
• date_dernier_controle;
• altitude_orthometrique;
• qualite_reception_gnss;
• commentaire_intervention.

En Shapefile, ces libellés doivent être tronqués. Il faut alors maintenir un dictionnaire de correspondance externe. Sans lui, l’interopérabilité des données géographiques devient superficielle: les fichiers s’ouvrent partout, mais leur sémantique ne suit plus.

Le GeoPackage conserve des noms de champs lisibles. L’opérateur voit ce qu’il renseigne. Le géomaticien comprend ce qu’il traite. Le destinataire peut importer sans reconstruire la signification des abréviations.

Unicode élimine une panne encore fréquente

Les erreurs d’encodage sont typiques des flux Shapefile. Accents, apostrophes, caractères régionaux ou signes techniques peuvent être altérés lors d’un export ou d’une ouverture dans un logiciel ancien. Un champ réseau électrique devient parfois un texte illisible. Le problème n’empêche pas toujours le chargement de la couche; il dégrade silencieusement les attributs.

Le GeoPackage prend en charge Unicode de manière native. Les chaînes de caractères sont donc mieux conservées entre les outils compatibles. Pour les bases contenant des libellés réglementaires, des noms de voies, des observations terrain ou des commentaires de contrôle, cet écart est concret.

L’index spatial doit rester cohérent avec la géométrie

Le GeoPackage intègre une indexation spatiale R-tree. Cette structure accélère la recherche d’objets par emprise et les opérations de sélection spatiale sur les couches volumineuses. Elle est intégrée au conteneur, ce qui simplifie sa gestion.

Le Shapefile s’appuie sur son fichier .shx séparé pour l’index. Si ce fichier manque ou devient incohérent, certains logiciels peuvent tenter une reconstruction. D’autres affichent une erreur ou ouvrent la couche avec des performances dégradées. Ce comportement dépend du logiciel. Il n’est pas prudent de le laisser au hasard.

Il ne faut pas inventer ici une hiérarchie absolue des vitesses. Les performances de lecture et d’écriture varient avec le poste, le volume, la complexité géométrique, le pilote de données et l’application utilisée. Un test sur une couche de parcelles simples ne prédit pas le comportement d’une base de réseaux avec géométries denses, jointures et orthophotographies.

En revanche, l’architecture est claire: le R-tree et les tables SQLite donnent au GeoPackage une base plus rationnelle pour les requêtes spatiales et la gestion multicouche.

Le Shapefile reste utile dans un rôle précis

Déclarer le Shapefile obsolète serait incorrect. Il reste l’un des formats d’échange les plus universellement reconnus. Des logiciels de DAO, des outils métiers anciens, des automates d’import et certains portails institutionnels l’exigent encore.

Le mauvais choix n’est pas d’utiliser un Shapefile. Le mauvais choix est d’en faire le format maître d’un projet qui nécessite une structure attributaire riche, plusieurs couches, une conservation stricte des valeurs absentes ou un historique de production propre.

Le partage vers un environnement ancien justifie un export Shapefile. La production, elle, peut rester dans un GeoPackage.

Cette distinction évite un problème récurrent: appauvrir la base source pour satisfaire la cible la moins capable. Il faut faire l’inverse. Conserver une donnée de référence complète, puis exporter une copie adaptée aux contraintes du destinataire.

Migrer sans casser les flux de production

La transition vers le GeoPackage ne demande pas une refonte totale du système SIG. Elle demande surtout de décider quel fichier fait foi.

Le scénario robuste est simple: les données sont créées et maintenues dans un GeoPackage. Les exports Shapefile sont générés uniquement pour les destinataires qui les demandent. Cette séparation protège la donnée source contre les pertes induites par le DBF.

La migration doit toutefois être contrôlée. Un export ne garantit pas que toutes les propriétés ont été conservées. Avant de basculer une chaîne de traitement, il faut vérifier les points suivants:

• Le système de coordonnées. Contrôler le système enregistré dans le GeoPackage et celui interprété à l’import dans chaque application. Une géométrie exacte dans le mauvais référentiel reste une erreur d’implantation.
• Les champs transformés. Comparer les types de données, les dates, les décimales et les valeurs nulles après conversion.
• Les noms de colonnes. Les noms longs du GeoPackage seront tronqués lors d’un export Shapefile. Le mapping doit être documenté si le fichier revient ensuite vers la base source.
• Les géométries. Vérifier les objets multiparties, les géométries invalides et les dimensions éventuelles. Un flux qui accepte du 2D n’interprétera pas nécessairement les informations Z de la même façon.
• Les domaines de valeurs. Les listes de codes, statuts et classes de précision doivent rester cohérentes entre la collecte, le SIG et le logiciel de DAO.
• La concurrence d’accès. Un GeoPackage convient bien à la production locale et aux échanges contrôlés. Il n’est pas une base serveur multi-utilisateur à modifier simultanément sans procédure.

Le dernier point mérite une lecture stricte. Le GeoPackage est un excellent format de travail pour une équipe qui centralise, contrôle et diffuse des fichiers. Pour des dizaines d’éditeurs connectés en permanence, une base spatiale serveur reste plus adaptée. Il ne faut pas demander à un fichier SQLite de résoudre un problème d’architecture réseau.

Verdict: GeoPackage en production, Shapefile en compatibilité

Le match n’est pas équilibré sur le plan technique. Le Shapefile conserve une compatibilité exceptionnelle, mais il impose des limites de structure qui ne correspondent plus aux besoins d’un SIG de production: trois fichiers minimum, 2 Go par composant, 255 champs, noms de colonnes réduits à dix caractères, encodage fragile et absence de véritables valeurs nulles numériques.

Le GeoPackage apporte un conteneur unique, multicouche, indexé et ouvert. Il préserve mieux les attributs, accepte les tables non spatiales et peut intégrer des tuiles raster. Pour un choix de format SIG destiné à produire, contrôler, archiver et transmettre des données de topographie ou de cartographie, le verdict est net: GeoPackage.

Le Shapefile doit rester un format de sortie lorsque l’interopérabilité l’impose. Il ne devrait plus être le format où la donnée métier naît, évolue et fait foi.