Derrière chaque carte web, chaque requête spatiale, chaque export SIG, il y a un format de fichier ou un protocole qui conditionne la performance, la scalabilité et la maintenabilité de tout le système. Choisir le mauvais format, c'est potentiellement des temps de chargement excessifs, une scalabilité impossible et une dette technique durable. Ce premier volume de la collection « Chaîne de la donnée géospatiale » couvre trente ans d'évolution — du SIG desktop des années 1990 aux formats cloud-native et WebGPU de 2026 — avec plus de vingt formats analysés en profondeur, un guide décisionnel complet et cinq architectures de référence.

Préface

Les formats de données géospatiales constituent l'un des sujets les plus stratégiques — et les plus sous-estimés — de l'écosystème des systèmes d'information. Depuis près de trente ans, j'ai vu des projets échouer non pas par manque de compétences métier, mais parce que les choix technologiques fondamentaux avaient été faits trop vite, sans recul sur les implications architecturales, de performance ou de maintenabilité.

Ce livre blanc est né d'un double constat. D'abord, la documentation existante sur les formats géospatiaux est souvent fragmentée : les développeurs trouvent des références techniques précises sur chaque format pris isolément, mais rarement une vision d'ensemble qui permette de comprendre pourquoi un format a émergé, quel problème concret il résolvait, et comment il s'inscrit dans la trajectoire longue de l'évolution du SIG vers le web, puis vers le cloud et le GPU.

Ensuite, 2026 marque un tournant concret : l'arrivée de MapLibre Tile (MLT) comme successeur du MVT, l'adoption massive de PMTiles qui supprime le besoin de tile server, et la montée en puissance de GeoParquet dans les pipelines de data engineering spatial. Ce n'est pas une simple évolution incrémentale — c'est une recomposition des fondamentaux.

Ce document s'adresse aux développeurs web et SIG, aux architectes solutions, aux chefs de projet en transformation digitale et à tous ceux qui prennent des décisions techniques impliquant de la donnée géographique. Il ne présuppose pas une expertise préalable en cartographie, mais suppose une familiarité avec les concepts d'API, de base de données et d'architecture web.

Mattieu Pottier — Consultant en transformation digitale, spécialiste Odoo ERP et applications SIG

Introduction — Pourquoi les formats géospatiaux sont un sujet stratégique

La donnée géographique est partout. Dans votre application de livraison quand elle calcule un itinéraire, dans votre plateforme de gestion de patrimoine quand elle localise un équipement, dans votre dashboard de monitoring quand il représente une carte de chaleur. Derrière chaque carte web, derrière chaque requête spatiale, derrière chaque export SIG, il y a un format de fichier ou un protocole qui conditionne la performance, la scalabilité et la maintenabilité de tout le système.

Le fil conducteur : quatre ruptures technologiques

L'histoire des formats géospatiaux n'est pas une accumulation linéaire de standards. Elle se structure autour de quatre ruptures technologiques majeures, chacune provoquée par un changement de contexte d'usage.

Partie 1 — Taxonomie et grille de lecture

Avant d'entrer dans le détail de chaque format, il est essentiel de disposer d'une grille de lecture commune. Les formats géospatiaux peuvent être classifiés selon plusieurs dimensions orthogonales.

1.1 Vecteur, Raster, Nuage de points, 3D, Scientifique

La première distinction fondamentale concerne la nature des données représentées.

1.2 Fichier, API, Tile

La deuxième dimension concerne le mode d'accès et de distribution de la donnée.

1.3 Environnement de consommation cible

1.4 Les cinq critères de choix d'un format

Tout choix de format géospatial devrait être évalué selon ces cinq dimensions.

Partie 2 — Ère 1 : Le SIG Desktop (1994–2004)

Au milieu des années 1990, le SIG est un outil professionnel réservé aux spécialistes. Les logiciels — ArcView 3.x d'ESRI, MapInfo Professional, Intergraph — tournent sur des postes de travail coûteux. L'internet grand public n'existe pas encore sous sa forme actuelle. Les formats de données géospatiales de cette époque reflètent ces contraintes : accès fichier local, échange entre spécialistes, peu de préoccupation pour le réseau ou l'interopérabilité avec des navigateurs. C'est dans ce contexte que naissent les formats fondateurs, dont certains sont encore actifs trente ans plus tard.

Contexte et problématique

En 1994, les données satellitaires et aériennes numérisées se multiplient, mais chaque fournisseur utilise ses propres conventions pour stocker l'information de géoréférencement. Résultat : une image SPOT ne pouvait pas être superposée directement à une image d'un autre capteur sans retraitement manuel. GeoTIFF répond à ce problème en étendant le format TIFF standard avec des balises normalisées qui stockent le système de coordonnées, la transformation affine et la projection cartographique directement dans le fichier image.

Architecture technique

GeoTIFF est un TIFF enrichi de métadonnées géographiques sous forme de tags privés. L'image est stockée en tuiles ou en bandes, potentiellement compressée (LZW, Deflate, JPEG). Les métadonnées clés : GeoKeyDirectory (répertoire des clés de géoréférencement), ModelPixelScaleTag (résolution X/Y dans les unités de la projection), ModelTiepointTag (correspondance pixel ↔ coordonnée terrain), ModelTransformationTag (matrice affine de transformation).

Architecture technique

Un "fichier Shapefile" est en réalité un ensemble d'au moins trois fichiers avec le même nom de base : .shp (géométries vectorielles), .shx (index d'accès aux géométries), .dbf (attributs en format dBASE III — héritage des années 1980), .prj (projection cartographique), .cpg (encodage des caractères).

Pourquoi le Shapefile survit malgré ses limitations : support universel (absolument tous les logiciels SIG le lisent), simplicité d'usage (pas de base de données requise), et inertie institutionnelle (décennies de workflows, données archivées et scripts automatisés).

WMS répond à un problème fondamental du web cartographique naissant : comment permettre à un client quelconque de demander une image cartographique d'une zone précise, à une échelle précise, sans télécharger toute la donnée ? Le serveur génère et renvoie une image PNG ou JPEG pour chaque requête. Le traitement est entièrement côté serveur.

En 2000, XML est au sommet de sa popularité. L'OGC publie GML comme format d'échange universel pour les données géographiques complexes. GML est pensé comme le langage universel de l'information géographique — et c'est précisément son problème : la verbosité XML.

<!-- GML — un point avec srsName -->
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
  <gml:pos>48.8566 2.3522</gml:pos>
</gml:Point>

// GeoJSON équivalent
{"type": "Point", "coordinates": [2.3522, 48.8566]}

// Rapport de taille : GML est typiquement 5 à 15× plus volumineux.

KML est créé en 2001 pour EarthViewer (qui deviendra Google Earth). Il popularise la carte 3D interactive auprès du grand public et introduit massivement la notion de couche cartographique partageable. Conçu pour la présentation visuelle avec styles, icônes et animations. Sa forme compressée KMZ facilite la distribution.

WFS répond à la question : comment accéder aux données vectorielles brutes (géométries + attributs) via le web, de manière standardisée ? Il hérite de GML pour la représentation — chaque feature retournée est encodée en XML GML. Les conséquences sont directes : requêtes volumineuses, parsing côté client coûteux, pas de pagination native en WFS 1.x, complexité du filtre OGC.

GPX émerge avec la démocratisation des récepteurs GPS portables (Garmin, Magellan). Format d'échange universel XML pour les données de navigation GPS : traces avec timestamp et altitude, waypoints, routes. Support natif sur Garmin, Strava, Komoot, QGIS. Sa niche est stable — il n'est pas concerné par les tendances web.

Partie 3 — Ère 2 : L'explosion du web cartographique (2005–2013)

Février 2005 marque un tournant historique : Google lance Google Maps sur le web. Pour la première fois, une carte interactive glissante (slippy map) est disponible dans un simple navigateur, sans plugin. La technique des tuiles raster combinée à du JavaScript asynchrone révolutionne l'expérience cartographique. L'écosystème web cartographique explose : OpenLayers (2006) puis Leaflet (2011) démocratisent la cartographie JavaScript open source. Ces nouveaux usagers ont besoin de formats adaptés au web : légers, JSON-natifs, faciles à manipuler.

Structure et architecture

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [2.3522, 48.8566]
      },
      "properties": {
        "name": "Paris",
        "population": 2161000
      }
    }
  ]
}

// Types géométriques : Point, MultiPoint, LineString, MultiLineString,
// Polygon, MultiPolygon, GeometryCollection
// RFC 7946 : WGS84 obligatoire, polygones en sens antihoraire

Pourquoi GeoJSON a gagné

Les limites de GeoJSON

• !Volumétrie — au-delà de 50 000 entités, les performances de parsing et de rendu se dégradent significativement
• !Pas de compression native — un GeoJSON de données OSM d'une ville peut peser plusieurs centaines de Mo
• !Pas d'index spatial — interroger un GeoJSON côté serveur nécessite de le charger entièrement en mémoire
• !WGS84 obligatoire — RFC 7946 impose ce CRS, incompatible avec certains contextes (Lambert 93, etc.)

WMS génère une image à la demande pour chaque requête — ce qui est coûteux en CPU et impossible à cacher efficacement. WMTS standardise la technique des tuiles : on pré-calcule des tuiles 256×256 pour chaque niveau de zoom et chaque position dans une grille fixe. Ces tuiles sont identiques pour tous les utilisateurs et parfaitement cachables sur CDN.

Quand on génère des tuiles pour un zoom mondial, on peut facilement produire des millions de fichiers PNG individuels. Stocker des millions de petits fichiers sur un système de fichiers est inefficace. MBTiles encapsule toutes les tuiles dans une base SQLite unique, portable, indexée et directement servable via TileServer GL. PMTiles (2022) offre une alternative sans serveur via HTTP Range Requests.

OSM distribue l'intégralité de sa base mondiale sous forme de dumps. Le format PBF (Protocol Buffers), adopté en 2010, divise la taille par 2–3 et multiplie la vitesse de parsing par 5–6 par rapport au XML.

TopoJSON encode la topologie explicitement : au lieu de stocker des polygones fermés, il stocke des arcs (segments de frontière) référencés par les polygones adjacents. Une frontière commune entre deux départements n'est stockée qu'une seule fois. Pour une carte choroplèthe classique, TopoJSON est typiquement 2 à 4× plus petit que GeoJSON équivalent. Sa niche est stable : excellent pour la dataviz D3.js et les cartes choroplèthes web légères.

3.4 Le schéma XYZ — le tuilage dominant non-OGC

Parallèlement aux standards OGC, un schéma de facto s'impose par sa simplicité : le schéma XYZ, popularisé par Google Maps et OpenStreetMap. L'URL d'une tuile suit le pattern https://tile.openstreetmap.org/{z}/{x}/{y}.png où z est le niveau de zoom (0–22) et x, y la position dans la grille de Mercator. Ce schéma est directement supporté par Leaflet, Mapbox GL et tous les frameworks cartographiques modernes. Il n'a pas de spécification formelle OGC mais est devenu un standard de facto universel.

Partie 4 — Ère 3 : La performance vectorielle web (2014–2019)

En 2013–2014, la carte web est confrontée à un mur de performance. Les tuiles raster gèrent parfaitement les fonds de carte statiques, mais posent deux problèmes majeurs : elles ne sont pas interactives, et elles doivent être régénérées entièrement si le style change. WebGL, disponible dans les navigateurs depuis 2011 et stable depuis 2013, ouvre une nouvelle possibilité : utiliser le GPU du client pour le rendu cartographique. Si on envoie des données vectorielles brutes au client et qu'on les rend avec WebGL, le style peut être modifié en temps réel côté client sans régénérer les tuiles. C'est cette idée qui donne naissance aux vector tiles.

Architecture technique

Une tuile MVT est un fichier binaire encodé en Protocol Buffers. Elle contient des layers (couches thématiques : routes, bâtiments, eau), des features (entités avec attributs), des géométries (coordonnées entières relatives à la grille 0–4096) et des clés/valeurs compressées (les attributs strings sont dédupliqués via un dictionnaire interne). Le fichier est encodé row-based — limitation que MLT résoudra.

L'écosystème MVT — pourquoi il a tout conquis

GeoPackage est publié par l'OGC en 2014 comme remplacement officiel du Shapefile. Un GeoPackage est une base SQLite avec une structure de tables normalisée : gpkg_contents (métadonnées des couches), gpkg_geometry_columns (description des colonnes géométriques), gpkg_spatial_ref_sys (projections), tables métier avec géométries WKB + attributs typés, et tables optionnelles pour les tuiles raster.

FlatGeobuf répond à un problème spécifique : diffuser un grand jeu de données vectorielles sur le web en permettant des requêtes spatiales sans serveur. GeoJSON nécessite de charger le fichier entier. FlatGeobuf intègre un index Hilbert R-Tree directement dans le fichier, permettant des requêtes bbox en n'accédant qu'aux octets pertinents via HTTP Range Requests. Structure : Header (schéma, CRS, emprise), Index spatial, Features ordonnées selon la courbe de Hilbert.

OGC API Features est conçu selon les principes REST modernes : URLs lisibles (/collections/{id}/items/{featureId}), JSON natif (GeoJSON par défaut), pagination via liens next/prev, filtrage CQL2, documentation OpenAPI auto-générée, et rendu HTML pour la navigation humaine.

// Lister les communes de plus de 10 000 habitants dans une emprise
GET /collections/communes/items
  ?bbox=2.0,48.5,3.0,49.0
  &filter=population>10000
  &limit=100
  &offset=0

// Accéder à une feature spécifique
GET /collections/communes/items/75056

// Implémenter dans pygeoapi (Python)
// GeoServer, ldproxy, 52°North — implémentations disponibles

Servir des tuiles cartographiques a longtemps nécessité un serveur dédié. PMTiles supprime ce besoin : le format organise toutes les tuiles dans un fichier unique avec un index spatial en en-tête. Pour récupérer une tuile, le client envoie une requête HTTP Range pour télécharger uniquement les octets correspondants. Les CDN et stockages objets supportent nativement les Range Requests.

Partie 5 — Ère 4 : Cloud, Big Data et WebGPU (2020–2026)

Deux tendances convergent au début des années 2020. D'un côté, le volume de données géospatiales explose : satellites Sentinel et Landsat en open access, données ADS-B, traces de smartphones, LiDAR des villes. Les formats binaires compacts orientés colonnes (Apache Parquet, Arrow) dominent l'ingénierie des données — il devient naturel de les étendre au domaine spatial. De l'autre côté, WebGPU arrive dans les navigateurs — successeur de WebGL, il ouvre des possibilités nouvelles pour le rendu cartographique si le format des données est adapté à la structure GPU.

GeoTIFF standard présente un problème pour le cloud : pour accéder à une petite zone d'une image de 10 Go, un client doit télécharger le fichier entier. COG résout ce problème avec HTTP Range Requests — la même technique que PMTiles. Un COG est un GeoTIFF réorganisé avec deux caractéristiques clés : tuiles internes (256×256 ou 512×512 px, répertoire d'offsets en en-tête) et aperçus pré-calculés (plusieurs niveaux de résolution dans le même fichier).

Apache Parquet s'est imposé comme le format standard du data engineering : orienté colonnes, compressé, optimisé pour les requêtes analytiques. GeoParquet l'étend avec une convention pour stocker des géométries (en WKB dans une colonne bytes) et des métadonnées géospatiales (CRS, emprise, type) dans les métadonnées Parquet. DuckDB, Spark, BigQuery, Pandas, Polars — tous le lisent nativement.

-- Compter les bâtiments dans Paris intra-muros
LOAD spatial;

SELECT COUNT(*) FROM read_parquet('buildings.parquet')
WHERE ST_Within(
  geometry,
  ST_GeomFromText('POLYGON((2.224 48.815, 2.469 48.815,
                             2.469 48.902, 2.224 48.902,
                             2.224 48.815))')
);
-- Sur 100 millions de bâtiments : résultat en ~2 secondes
-- Sans infrastructure serveur, directement sur fichier local ou S3

-- Lire depuis Cloudflare R2 / S3 sans téléchargement complet
SELECT name, ST_Area(geometry) as area_m2
FROM read_parquet('s3://bucket/communes.parquet')
WHERE ST_Intersects(geometry, ST_GeomFromText('POINT(2.35 48.86)'))
LIMIT 10;

Architecture column-oriented — pourquoi c'est révolutionnaire

Apache Arrow est le standard de représentation des données analytiques en mémoire : un format orienté colonnes avec un buffer mémoire commun partageable entre processus (zero-copy). GeoArrow définit une extension Arrow native pour les géométries stockées directement dans des buffers Arrow typés. L'intérêt fondamental : les coordonnées géométriques sont dans des buffers numériques qui peuvent être transférés au GPU sans conversion. Dans le contexte WebGPU, les vertex buffers GPU attendent exactement ce format.

Genèse et contexte

En 2014, MVT a résolu le rendu vectoriel web avec WebGL. En 2026, MLT résout le problème suivant : MVT a été conçu quand les volumes correspondaient à une ville. Douze ans plus tard, trois contraintes ont changé : volumes planet-scale (Overture Maps, LiDAR nationaux), WebGPU (nécessite des données structurées différemment de WebGL), et l'efficacité du row-based vs column-based.

Architecture technique — la différence column-oriented

// MVT — Row-based : chaque feature est un bloc complet
Feature 1: [geometry] [name: "rue de Rivoli"]   [class: "primary"]   [oneway: true]
Feature 2: [geometry] [name: "bd Haussmann"]     [class: "secondary"] [oneway: false]
Feature 3: [geometry] [name: "rue du Faubourg"]  [class: "primary"]   [oneway: true]
// → Lire "class" de toutes les features = parcourir toute la structure

// MLT — Column-oriented : chaque attribut est un tableau contigu
col_geometry : [geom1_bytes] [geom2_bytes] [geom3_bytes] ...
col_name     : ["rue de Rivoli"] ["bd Haussmann"] ["rue du Faubourg"] ...
col_class    : ["primary"] ["secondary"] ["primary"] ...
col_oneway   : [true] [false] [true] ...
// → Lire "class" = lire un seul tableau contigu → SIMD possible
// → Compression RLE : ["primary","secondary","primary"] → très efficace

Performances mesurées (benchmarks OSM)

Fonctionnalités étendues

MLT ajoute des capacités structurelles absentes de MVT : coordonnées 3D natives (altitude comme type de première classe — bâtiments extrudés, terrain, LiDAR), nested types (attributs contenant objets ou listes — horaires OSM, relations routières), linear referencing et M-values (positionnement kilométrique pour les données routières), et maps et listes pour les attributs polymorphes.

Guide de décision MLT vs MVT

Partie 6 — Formats 3D, LiDAR et Nuages de Points

La troisième dimension s'est imposée avec la démocratisation du LiDAR aéroporté et les besoins des smart cities et du BIM. Ces formats répondent à des problématiques radicalement différentes des formats 2D : volumétrie massive (des milliards de points pour un scan LiDAR), modélisation sémantique des bâtiments, visualisation 3D temps réel de scènes urbaines.

LAS est publié par l'ASPRS en 2003 pour les nuages de points LiDAR (coordonnées XYZ, intensité, classification, timestamp). LAZ (vers 2010–2011 par Martin Isenburg) est la version compressée sans perte : réduction de 70 à 85% sans sacrifier la précision. LAZ est aujourd'hui le format standard de distribution. Un successeur émerge : COPC (Cloud Optimized Point Cloud) — applique à LAS la même idée que COG à GeoTIFF, avec un index spatial permettant des requêtes partielles via HTTP Range Requests.

Comment visualiser une ville entière en 3D dans un navigateur ? Les modèles BIM d'un quartier peuvent contenir des millions de triangles. 3D Tiles résout ce problème avec un streaming hiérarchique basé sur un arbre spatial (octree ou quadtree) : les tuiles les plus grossières sont chargées en premier, puis raffinées à mesure que l'utilisateur se rapproche. Chaque nœud peut contenir des meshes 3D glTF (bâtiments), des nuages de points LiDAR, ou des objets instanciés (arbres, lampadaires).

CityGML représente non seulement la géométrie des bâtiments, mais aussi leur structure sémantique (toits, murs, portes, fenêtres), leurs attributs (usage, date de construction) et leurs relations. Il définit cinq niveaux de détail LoD 0 (empreinte au sol) à LoD 4 (modèle intérieur complet). La plupart des projets smart city utilisent LoD 2. Sa complexité XML est un frein — CityJSON (2019) est la version JSON qui gagne en popularité.

IFC est le standard d'échange du BIM. Un modèle IFC contient la géométrie précise d'un bâtiment avec ses métadonnées (matériaux, propriétés thermiques, coûts). IFC 4.3 intègre nativement la géolocalisation. La chaîne IFC → CityGML/CityJSON → 3D Tiles pour la visualisation web est maintenant opérationnelle.

Partie 7 — Formats Scientifiques et Climatiques

Les sciences de la Terre produisent des données multidimensionnelles qui dépassent le cadre classique du SIG 2D : données climatiques sur une grille régulière avec une dimension temporelle, profils océanographiques avec une dimension de profondeur, données de modèle atmosphérique sur plusieurs niveaux de pression.

NetCDF est un format binaire auto-descriptif pour les données scientifiques multidimensionnelles. Il contient des variables (tableaux n-dimensionnels), des dimensions (latitude, longitude, temps, altitude) et des attributs. Un fichier de prévisions météo peut contenir : dimensions lat[721] × lon[1440] × time[240] × pressure_level[37] avec les variables temperature, wind_u, wind_v, humidity — soit ~37 milliards de valeurs dans un seul fichier. NetCDF-4 (basé sur HDF5) supporte la compression interne, l'accès parallèle et les groupes de variables. Les librairies Python xarray et netCDF4-python permettent une manipulation expressive.

HDF5 organise les données en groupes (comme des répertoires) et datasets (tableaux n-dimensionnels), avec compression, chunking et accès parallèle. NetCDF-4 est construit sur HDF5. HDF5 est utilisé pour les données de télédétection (HDF-EOS pour MODIS/VIIRS), les données LiDAR aéroportées et les données de simulation numérique.

Partie 8 — Formats CAD dans l'écosystème géospatial

La frontière entre CAD et SIG s'est progressivement estompée. Les projets d'infrastructure (routes, réseaux, bâtiments) sont souvent conçus en CAD puis intégrés dans des systèmes SIG pour la gestion patrimoniale, la maintenance et l'analyse territoriale.

DWG est le format natif binaire d'AutoCAD (propriétaire, spécification partiellement publique). DXF est la version d'échange texte publiée par Autodesk pour l'interopérabilité. L'intégration CAD-SIG pose plusieurs défis : coordonnées relatives (pas géographiques), structure en couches et blocs (pas en features typées), géométries complexes (splines, arcs, NURBS), et attributs dans les blocs à mapper vers des attributs SIG.

Le flux CAD → SIG en pratique

Partie 9 — Guide décisionnel complet

Ce guide synthétise les recommandations pratiques de l'ensemble du document. Il est conçu pour être utilisé comme référence rapide lors d'un choix architectural.

9.1 Matrice décisionnelle par cas d'usage

9.2 Arbre de décision — Format vectoriel web

9.3 Compatibilité par logiciel

9.4 Cinq scénarios architecturaux types

Partie 10 — Architectures de référence 2026

Cette partie présente les stacks techniques recommandées par profil d'usage. Le socle commun incontournable reste PostgreSQL + PostGIS : maturité, richesse fonctionnelle (ST_Intersects, ST_Buffer, ST_AsMVT), écosystème universel (GDAL, QGIS, GeoServer, SQLAlchemy).

10.2 Architecture standard — PME / Startup

10.3 Architecture cloud-native — volumétrie élevée

10.4 Architecture institutionnelle / OGC-compliant

Partie 11 — Tendances et horizon 2030

Les tendances identifiées ici ne sont pas spéculatives — elles sont déjà visibles en 2026, certaines en phase de production, d'autres en adoption précoce. Elles permettent d'anticiper les choix architecturaux pour les 3 à 5 prochaines années.

11.6 Synthèse — Les formats à surveiller d'ici 2030

Conclusion générale

En parcourant trente ans d'évolution des formats géospatiaux — du Shapefile des années 1990 à MLT en 2026 — une trajectoire se dessine avec une clarté remarquable : chaque génération de formats répond à un changement structurel du contexte technologique et des usages.

Le SIG desktop des années 1990 avait besoin de formats stables pour des logiciels spécialisés — Shapefile et GeoTIFF ont parfaitement rempli ce rôle. L'explosion du web cartographique a exigé des formats JSON-natifs — GeoJSON a répondu et reste dominant pour sa niche. La révolution WebGL de 2014 a donné naissance à MVT et l'écosystème des tuiles vectorielles. Aujourd'hui, en 2026, WebGPU, GeoParquet, PMTiles et MLT posent les bases de la quatrième ère.

Références et ressources

Standards et spécifications

Librairies et outils de référence

Glossaire

BBox / Bounding Box

Emprise rectangulaire d'une géométrie ou d'une requête spatiale, définie par (minX, minY, maxX, maxY).

BIM

Building Information Modeling — modélisation numérique des bâtiments avec données sémantiques et géométriques. Standard IFC porté par buildingSMART.

CDN

Content Delivery Network — réseau de distribution de contenu avec serveurs en périphérie (edge). Utilisé pour distribuer les tiles PMTiles et COG à faible latence.

COG

Cloud Optimized GeoTIFF — GeoTIFF avec index interne permettant des requêtes partielles via HTTP Range Requests. Standard de fait pour le raster cloud en 2026.

Column-oriented

Structure de stockage où les données d'une même colonne sont contiguës en mémoire. Optimal pour les opérations analytiques (OLAP). Base de GeoParquet et MLT. Opposé de row-based.

COPC

Cloud Optimized Point Cloud — extension du format LAS avec index spatial HTTP Range compatible. Équivalent COG pour les données LiDAR.

CRS

Coordinate Reference System — système de référence de coordonnées (projection cartographique + datum). WGS84 (EPSG:4326) est obligatoire en GeoJSON RFC 7946.

DXF

Drawing Exchange Format — format d'échange CAD texte ou binaire, créé par Autodesk pour AutoCAD. Version ouverte de DWG pour l'interopérabilité SIG.

FlatGeobuf

Format binaire vectoriel avec index Hilbert R-Tree intégré. Permet des requêtes spatiales bbox via HTTP Range Requests sans serveur. Basé sur FlatBuffers (Google).

GeoArrow

Extension Apache Arrow pour les géométries spatiales. Buffers mémoire alignés permettant des transferts zero-copy CPU→GPU. Brique fondamentale pour WebGPU et deck.gl.

GeoJSON

Format JSON pour les données géographiques vectorielles, standardisé en RFC 7946. WGS84 obligatoire. Standard de facto pour les API REST géospatiales.

GeoPackage

Format fichier OGC basé sur SQLite. Successeur du Shapefile pour les échanges SIG desktop. Un seul fichier, multi-couches, UTF-8, ACID. Spec OGC 2014.

GeoParquet

Extension Apache Parquet pour les données géospatiales. Standard pour le data engineering spatial. Spec v1.0 publiée en septembre 2023. Adopté par Overture Maps Foundation.

GML

Geography Markup Language — format XML de l'OGC pour les données géospatiales. Verbeux (5–15× GeoJSON). Format sous-jacent de WFS. Remplacé par GeoJSON dans OGC API Features.

HTTP Range Requests

En-tête HTTP permettant de télécharger une partie d'un fichier (bytes spécifiques). Fondement technique de COG, PMTiles, FlatGeobuf et COPC — permet le streaming sans serveur.

IFC

Industry Foundation Classes — standard d'échange BIM de buildingSMART International. IFC 4.3 (2021) intègre la géolocalisation native. Pivot de la convergence BIM-GIS.

KML

Keyhole Markup Language — format XML de visualisation géographique, créé par Keyhole/Google pour EarthViewer. Standard OGC depuis 2008. Niche : annotations grand public.

LAZ

Compression lossless du format LAS pour les données LiDAR. Réduction ~75–85% de la taille sans perte de précision. Développé par Martin Isenburg (LASzip). Standard de distribution LiDAR.

LiDAR

Light Detection And Ranging — technique de mesure par laser produisant des nuages de points 3D géoréférencés avec intensité, classification et timestamp.

MLT

MapLibre Tile — format vector tile column-oriented, successeur de MVT, conçu pour WebGPU. Compression 3–6× meilleure que MVT. Coordonnées 3D natives. Types complexes (nested). Annoncé janvier 2026.

MBTiles

Container SQLite pour tuiles cartographiques raster ou vectorielles. Format Mapbox, portable, indexé. Remplacé progressivement par PMTiles pour la distribution web.

MVT

Mapbox Vector Tiles — format de tuiles vectorielles binaires (protobuf), standard web depuis 2014. Row-based. Écosystème massif (Mapbox, MapLibre, OpenLayers, QGIS). Standard dominant en 2026.

OGC

Open Geospatial Consortium — organisation de standardisation des formats et protocoles géospatiaux (WMS, WFS, OGC API Features, 3D Tiles, GeoPackage, etc.).

OGC API Features

Standard OGC REST moderne pour exposer des données vectorielles. Successeur de WFS. API JSON, pagination, filtrage CQL2, documentation OpenAPI. Recommandé pour toute nouvelle API géospatiale.

OSM PBF

OpenStreetMap Protocolbuffer Binary Format — format de dump complet d'OpenStreetMap. Planétaire : ~80 Go. 2–3× plus compact et 5–6× plus rapide à parser que le XML OSM.

PMTiles

Single-file tile archive permettant la distribution de tiles sur CDN sans serveur dédié. HTTP Range Requests. Compatible MVT et MLT. Développé par Protomaps (Brandon Liu), 2022.

PostGIS

Extension PostgreSQL ajoutant des types géométriques, index GiST spatial et 800+ fonctions spatiales (ST_Intersects, ST_Buffer, ST_AsMVT…). Socle de toute architecture SIG professionnelle.

Protobuf

Protocol Buffers — format de sérialisation binaire Google. Utilisé par MVT pour l'encodage des tuiles vectorielles. Compact et rapide mais nécessite une librairie de décodage.

Row-based

Structure de stockage où toutes les colonnes d'une ligne sont contiguës en mémoire. Optimal pour les transactions OLTP. Architecture de MVT — limitation pour les gros volumes que MLT résout.

Shapefile

Format vectoriel ESRI (~1993, spec 1998). Multi-fichiers (.shp, .shx, .dbf). Noms de colonnes 10 chars max, 2 Go max, encodage ambigu. Legacy mais encore omniprésent dans les portails open data.

SIMD

Single Instruction Multiple Data — exécution parallèle de la même opération sur plusieurs données. Rendu possible par la structure column-oriented de MLT pour le décodage GPU.

STAC

SpatioTemporal Asset Catalog — standard de catalogage des données géospatiales cloud (COG, GeoParquet). Utilisé par ESA, USGS, NASA pour leurs archives satellitaires.

TopoJSON

Extension JSON de GeoJSON encodant la topologie (arcs partagés entre polygones adjacents). 2–4× plus compact pour les cartes choroplèthes. Niche D3.js. Créé par Mike Bostock, 2012.

Vector Tiles

Tuiles vectorielles — données géométriques encodées par tuile pour le rendu GPU côté client. Permettent le style dynamique côté client et l'interactivité sur les features. MVT et MLT.

WebGL

Web Graphics Library — API JavaScript pour le rendu 2D/3D via GPU dans le navigateur. Base de Mapbox/MapLibre GL JS depuis 2013. Successeur : WebGPU (disponible 2023–2024).

WebGPU

Successeur de WebGL — API GPU généraliste dans le navigateur. Support compute shaders (GPGPU). Base de la prochaine génération de rendu cartographique. MLT est conçu pour en tirer parti.

WFS

Web Feature Service — standard OGC pour l'accès aux données vectorielles via le web. Réponses GML/JSON. Successeur officiel : OGC API Features (2019).

WMS

Web Map Service — standard OGC (2000) pour la diffusion d'images cartographiques générées côté serveur. Traitement CPU à chaque requête. Toujours actif dans les portails institutionnels en 2026.

WMTS

Web Map Tile Service — standard OGC (2010) pour la diffusion de tuiles raster pré-calculées. Cachable sur CDN. Successeur : OGC API Tiles (2022).

WKB / WKT

Well-Known Binary / Well-Known Text — formats d'encodage des géométries en base de données. WKB est utilisé par GeoParquet pour stocker les géométries dans les colonnes Parquet.

XYZ

Schéma d'URL de facto pour les tuiles cartographiques : /{z}/{x}/{y}.png. Standard non OGC mais universel, supporté nativement par Leaflet, MapLibre, Mapbox. Popularisé par Google Maps (2005).

À propos de l'auteur

Mattieu Pottier est consultant indépendant en transformation digitale, spécialisé dans les ERP (Odoo V18/V19), les systèmes d'information géographique (QGIS, développement QGIS), et les applications web (WordPress, FastAPI, Python, JavaScript). Il intervient sous la marque MP-i — Mattieu Pottier Indépendant auprès d'organisations souhaitant intégrer des outils open source dans leurs processus métier.

La trilogie de livres blancs techniques MP-i répond à un besoin terrain récurrent : disposer d'une référence synthétique, factuellement vérifiable et architecturalement actionnable sur la chaîne complète des données géospatiales — du format de stockage à l'exposition web.

Historique des révisions

Mattieu Pottier

Consultant SI indépendant — MP-i

Expert SIG, architecture système et Odoo. J'aide les collectivités, PME et bureaux d'études à construire des systèmes d'information calibrés sur leurs besoins réels — sans surcoût ni dépendance éditeur.

Volume suivant — LB2

Stocker la donnée géospatiale (1970–2026) — du Shapefile au GeoParquet cloud-native

→