Qu'est-ce qu'une API de données spatiales et en quoi diffère-t-elle de WFS ?

Une API de données spatiales sert des entités géospatiales sur HTTP afin que les clients puissent interroger par bbox, attribut et SCR sans télécharger des fichiers entiers. OGC API - Features est le remplaçant moderne, JSON/REST, de l'ancien WFS basé sur XML, avec des chemins de ressources comme /collections/{id}/items et des paramètres de requête standard.

À quoi sert OGC API - Features ?

Elle définit une manière RESTful, décrite en OpenAPI, de publier, paginer et filtrer des entités vectorielles en GeoJSON. La Partie 1 (Core) couvre la lecture ; la Partie 3 (Filtering) ajoute CQL2 ; des parties ultérieures ajoutent la création/mise à jour/suppression. C'est le bloc de construction des entités spatiales, aux côtés de PostGIS, des tuiles vectorielles et de STAC pour l'imagerie.

Quand une équipe SIG doit-elle construire une API plutôt que partager des fichiers ?

Construisez une API lorsque le même jeu de données est consommé de façon répétée, par plusieurs clients, avec filtrage ou mises à jour quasi temps réel. Pour une remise ponctuelle d'un jeu de données stable, un GeoPackage ou un fichier optimisé pour le cloud est plus simple et moins cher que de faire tourner un service.

Comment servir une table PostGIS comme une API ?

Pointez un serveur OGC API tel que pg_featureserv, pygeoapi ou GeoServer sur une table ou une vue PostGIS. Il publie automatiquement les collections à partir du schéma de la table ; vous contrôlez les colonnes exposées, le SCR et les limites de pagination, et vous ajoutez des index (GiST sur la géométrie) pour la performance.

API de données spatiales pour équipes SIG : guide

Réponse courte

Une API de données spatiales sert des entités géospatiales sur HTTP afin que tout client — une carte web, un notebook, un autre service — puisse demander exactement le sous-ensemble dont il a besoin (par emprise, filtre attributaire ou SCR) au lieu de télécharger un shapefile entier et de filtrer localement. Le standard moderne est OGC API - Features, un successeur REST/JSON de WFS, typiquement adossé à PostGIS et exposé par un serveur comme pygeoapi, pg_featureserv ou GeoServer. Pour les données à l'échelle de la visualisation, vous l'associez aux tuiles vectorielles ; pour l'imagerie et les grands catalogues raster, vous utilisez STAC. Construisez une API quand un jeu de données est consommé de façon répétée par plusieurs clients ; livrez un fichier quand il s'agit d'une remise stable et ponctuelle.

OGC API - Features vs l'ancien WFS

Le Web Feature Service (WFS 1.1/2.0) fonctionnait mais était lourd en XML, utilisait GML par défaut et exigeait des requêtes GetFeature POST verbeuses. OGC API - Features repense la même capacité autour de REST simple et d'OpenAPI :

GET /collections — lister les jeux de données disponibles.
GET /collections/{collectionId} — métadonnées d'un jeu de données (emprise, SCR, nombre d'éléments).
GET /collections/{collectionId}/items — les entités, en GeoJSON.
GET /collections/{collectionId}/items/{featureId} — une entité unique.

L'interrogation se fait avec des paramètres de requête ordinaires : ?bbox=minx,miny,maxx,maxy, ?limit=1000, ?datetime=2026-01-01/.., et des filtres attributaires. La spec est modulaire : la Partie 1 (Core) est en lecture seule ; la Partie 2 ajoute la gestion du SCR ; la Partie 3 (Filtering) introduit CQL2 pour des expressions comme ?filter=lithology='basalt' AND elevation>1500. Comme chaque endpoint est décrit par un document OpenAPI à /api, les clients peuvent découvrir le schéma par eux-mêmes.

Cela compte pour les équipes SIG car le GeoJSON sur REST est consommable par MapLibre, deck.gl, Leaflet, Python (requests + geopandas.read_file) et R sans parseur XML ni SIG bureautique dans la boucle.

Les couches d'un vrai produit de données spatiales

Un dossier de fichiers n'est pas un produit. Un produit de données spatiales maintenu sépare les responsabilités :

Ingestion des sources — livraisons brutes (CSV, shapefile, exports de levé) arrivant dans une zone de staging, avec la provenance enregistrée.
Stockage normalisé — une base PostGIS où la géométrie est validée, reprojetée vers un SCR connu et indexée. C'est la source de vérité.
Couches d'analyse / dérivées — vues matérialisées ou tables calculées à partir de la source.
Couche de publication — OGC API - Features pour les requêtes vectorielles, tuiles vectorielles pour le rendu, STAC pour l'imagerie, téléchargements bruts pour le volume.
Métadonnées et versionnage — descriptions de collection, licence, lignage et horodatage updated, afin qu'un consommateur sache ce qu'il récupère.

Le bénéfice est la reproductibilité : une nouvelle livraison passe par l'ingestion, la base se met à jour, et chaque client en aval voit les nouvelles données sans que personne ne ré-exporte un shapefile à la main.

Exemple détaillé : d'une table PostGIS à une API en direct

Supposons que vous ayez une table geology.outcrops dans PostGIS et que vous vouliez l'interroger sur HTTP.

Préparez la table. Assurez un SCR unique et déclaré ainsi qu'un index spatial :
```
ALTER TABLE geology.outcrops
  ALTER COLUMN geom TYPE geometry(Point, 4326)
  USING ST_Transform(ST_SetSRID(geom, 4326), 4326);
CREATE INDEX idx_outcrops_geom ON geology.outcrops USING GIST (geom);
```
Stocker la géométrie en EPSG:4326 rend la sortie GeoJSON conforme aux standards ; OGC API - Features fixe par défaut son bbox et son SCR de sortie à CRS84 (lon/lat).
Exposez-la. Avec pg_featureserv (un serveur Go léger des auteurs de PostGIS), pointez-le sur la base et il publie automatiquement chaque table et vue comme une collection :
```
DATABASE_URL="postgres://user:pw@host/db" pg_featureserv
```
La table outcrops est désormais à /collections/geology.outcrops/items.
Contrôlez ce qui est exposé. Plutôt que publier des tables brutes, publiez des vues qui ne sélectionnent que les colonnes et lignes publiques. pg_featureserv prend aussi en charge les fonctions (/functions/...) pour des requêtes paramétrées — par exemple une fonction stockée renvoyant les affleurements dans un tampon autour d'un point.

Interrogez-la. Un client web ne demande que l'emprise courante de la carte :

GET /collections/geology.outcrops/items?bbox=2.1,48.7,2.5,49.0&limit=2000

Pour un ensemble d'entités plus lourd, pygeoapi (Python) ajoute le filtrage CQL2 et un modèle de fournisseur plus riche ; GeoServer ajoute WMS/WMTS et le style si vous avez aussi besoin d'images rendues.

Pagination et contrôle de la charge utile

L'échec d'API le plus courant est de renvoyer trop d'entités d'un coup. Défendez-vous :

Fixez une limit par défaut et maximale (p. ex. 1000 par défaut, plafond strict à 10000). Les serveurs exposent numberReturned et numberMatched ainsi que des liens next/prev — les clients devraient les suivre plutôt que de tout demander.
Pour les jeux de données à l'échelle du rendu (millions d'entités), ne paginez pas du tout les Features — servez des tuiles vectorielles (Mapbox Vector Tiles / ST_AsMVT dans PostGIS, ou un endpoint de tuiles). L'API Features sert aux requêtes et téléchargements ; les tuiles servent au dessin.
Utilisez le filtrage par bbox côté serveur pour que la base, avec son index GiST, fasse le tri spatial — n'expédiez jamais la couche entière pour filtrer dans le navigateur.
Activez la compression gzip/brotli ; le GeoJSON se compresse bien, souvent à plus de 80 %.

-- Génération de tuiles vectorielles dans PostGIS
SELECT ST_AsMVT(t, 'outcrops') FROM (
  SELECT id, lithology,
         ST_AsMVTGeom(geom, ST_TileEnvelope(z, x, y)) AS geom
  FROM geology.outcrops
  WHERE geom && ST_TileEnvelope(z, x, y)
) AS t;

Quand NE PAS construire d'API

Une API est une infrastructure que vous devez faire tourner, surveiller et sécuriser. Faites-en l'impasse quand :

Le jeu de données est stable et remis une seule fois — livrez un GeoPackage (un fichier, plusieurs couches, basé sur SQLite) ou un format optimisé pour le cloud (COG pour les rasters, GeoParquet/FlatGeobuf pour les vecteurs) que le consommateur lit directement depuis le stockage objet.
Le consommateur a de toute façon besoin du jeu de données entier — le paginer via une API est plus lent qu'un téléchargement unique.
Il n'y a aucune mise à jour récurrente — le coût de maintenance d'un service n'achète rien.

Les fichiers optimisés pour le cloud (COG, GeoParquet, PMTiles) brouillent de plus en plus cette frontière : un fichier statique sur S3 avec des requêtes HTTP par plage offre une bonne partie du bénéfice « interroger un sous-ensemble » sans serveur en marche.

Pièges courants et leurs causes

Aucun SCR déclaré sur la source. Si la géométrie PostGIS a un SRID 0, la sortie GeoJSON est ambiguë et les clients la placent mal. Fixez le SRID explicitement avec ST_SetSRID/ST_Transform.
Publier des tables brutes. Exposer directement le schéma de stockage divulgue des colonnes internes et couple votre API à l'agencement de votre base. Publiez plutôt des vues ou des fonctions.
Aucun index spatial. Sans index GiST, chaque requête bbox parcourt la table ; la latence explose à mesure que la table grandit.
Ignorer licence et lignage. Un jeu de données servi sans provenance ni conditions de redistribution est un risque dès que quelqu'un le réutilise. Mettez licence et source dans les métadonnées de la collection.

QA et validation

Interrogez /conformance et confirmez que le serveur déclare les classes OGC API dont vous dépendez.
Validez que le GeoJSON renvoyé se parse (geopandas.read_file(url)), que les géométries sont valides (ST_IsValid) et que les coordonnées sont dans l'ordre lon/lat attendu.
Faites un test de charge sur une requête bbox réaliste et confirmez que l'index est utilisé (EXPLAIN ANALYZE).
Vérifiez que les liens de pagination font l'aller-retour et que numberMatched correspond à un COUNT direct.

Le point de vue Bathyl

Nous concevons les jeux de données géologiques comme des produits, pas comme des exports : une source de vérité PostGIS versionnée, un endpoint OGC API - Features pour les requêtes, des tuiles vectorielles pour le rendu, et des métadonnées qui voyagent avec la donnée. Le test est de savoir si la prochaine mise à jour passe automatiquement et si un consommateur peut voir le lignage, le SCR et la licence sans avoir à demander. Une API ne vaut la peine d'être exploitée que lorsque la réutilisation est réelle — sinon, un fichier bien décrit est le livrable le plus honnête.

Les API de données spatiales pour les équipes SIG