Requêtes géospatiales PostGIS : tout ce que vous pouvez faire en pur SQL

« PostGIS ? C'est là que je range mes couches avant de les ouvrir dans QGIS. »
Cette phrase résume l'usage que la plupart des projets font de leur base spatiale : un entrepôt.

Pourtant, l'essentiel de l'analyse que vous faites à la main dans QGIS — jointures, zones tampon, comptages par secteur, plus proche voisin — tient en quelques lignes de SQL, exécutées là où la donnée vit.

Mieux : cette capacité d'analyse est en soi une raison de choisir une base SQL plutôt qu'un format fichier. Voici ce que le SQL spatial sait faire, et quand c'est le bon canal.

La géométrie est une donnée, pas une image

Pour tout l'article, gardons le même jeu de données : un gestionnaire de réseau qui suit son patrimoine sur trois couches — les équipements (points, table equipements), le réseau (lignes, reseaux) et les zones d'intervention (polygones, zones_intervention). Toutes les requêtes qui suivent s'appuient dessus.

Le malentendu de départ tient en une image mentale : on se représente une couche SIG comme un dessin, une carte qu'on affiche.
Dans PostGIS, une géométrie est une colonne, exactement comme un nombre ou une date. Une table equipements a une colonne nom, une colonne date_pose et une colonne geom — et cette dernière s'interroge avec un WHERE, au même titre que les autres.

C'est tout le basculement. Au lieu d'ouvrir la couche et de cliquer pour sélectionner, vous posez une question géographique en SQL :

-- Combien d'équipements dans un rayon de 500 m autour d'un point ?
SELECT count(*)
FROM equipements
WHERE ST_DWithin(
  geom,
  ST_SetSRID(ST_MakePoint(352000, 6740000), 2154),
  500
);

ST_DWithin est une fonction spatiale parmi plusieurs centaines. Le déploiement de ces couches sur un VPS est traité dans le guide de mise en production d'un PostGIS hébergé ; ce qui suit, c'est ce qu'on en fait une fois la donnée en place.

Cinq familles de fonctions pour (presque) tout faire

Les centaines de fonctions ST_* peuvent décourager. En pratique, elles se rangent en cinq familles, et chaque famille répond à un type de question métier. Connaître les familles vaut mieux que mémoriser les fonctions : on cherche la bonne dans la documentation une fois qu'on sait dans quelle case on est.

Une remarque sur la famille « Reprojeter » : elle n'est pas qu'une question de format de sortie. ST_Transform conditionne aussi la justesse des mesures, parce qu'une distance n'a de sens qu'exprimée en mètres — j'y reviens dans les limites.

La jointure spatiale, la requête qui change tout

S'il ne fallait retenir qu'une seule chose du SQL spatial, ce serait celle-là. Une jointure classique relie deux tables par une valeur commune — un identifiant client, un code postal.
Une jointure spatiale relie deux couches par leur position : « quel équipement tombe dans quelle zone », sans qu'aucune colonne ne porte cette information au départ. C'est elle qui calcule la relation, et c'est, selon le workshop officiel PostGIS, le pain quotidien des bases spatiales.

L'exemple le plus courant en gestion de patrimoine : rattacher des actifs dispersés à leurs secteurs d'intervention, puis les compter.

-- Rattacher chaque équipement à sa zone, et compter par zone
SELECT z.nom_zone, count(e.id) AS nb_equipements
FROM zones_intervention z
LEFT JOIN equipements e
  ON ST_Contains(z.geom, e.geom)
GROUP BY z.nom_zone
ORDER BY nb_equipements DESC;

En une requête, vous avez le tableau « combien d'actifs par secteur » que personne n'avait jamais réussi à tenir à jour dans un tableur.
Le LEFT JOIN garde même les zones vides — utile pour repérer un secteur sans équipement référencé, donc un trou de données. La même mécanique répond à des dizaines de questions : croiser des incidents signalés avec les zones d'intervention, des points de mesure avec des bassins versants, des compteurs avec des secteurs de relève.

Trois questions métier, trois requêtes

La jointure spatiale posée, voici trois motifs qui couvrent une grande part des besoins terrain. Chacun tient en quelques lignes.

La zone tampon — « tout ce qui est à moins de X mètres »

Question classique : quels équipements tombent dans la bande de servitude de 10 mètres autour du réseau ? ST_Buffer matérialise la zone tampon, ST_Intersects teste le recouvrement.

-- Équipements situés dans la bande de servitude de 10 m autour du réseau
SELECT DISTINCT e.id, e.nom
FROM equipements e
JOIN reseaux r
  ON ST_Intersects(e.geom, ST_Buffer(r.geom, 10));

Le linéaire par zone — « combien de réseau dans chaque secteur »

Ici on ne compte pas des objets, on mesure une longueur découpée par une autre couche. ST_Intersection calcule la portion de réseau dans chaque zone, ST_Length la mesure.

-- Linéaire de réseau par zone d'intervention, en mètres
SELECT z.nom_zone,
       round(SUM(ST_Length(ST_Intersection(r.geom, z.geom)))) AS metres
FROM zones_intervention z
JOIN reseaux r ON ST_Intersects(r.geom, z.geom)
GROUP BY z.nom_zone
ORDER BY metres DESC;

Le plus proche voisin — « l'équipement le plus proche d'un incident »

Quand un incident est signalé à une position donnée, quel est l'équipement le plus proche ? L'opérateur <-> trie par distance et s'appuie sur l'index pour ne pas balayer toute la table.

-- Les 3 équipements les plus proches d'un point signalé
SELECT e.id, e.nom
FROM equipements e
ORDER BY e.geom <-> ST_SetSRID(ST_MakePoint(352120, 6740310), 2154)
LIMIT 3;

La vue, quand l'analyse devient une couche

Une requête, c'est ponctuel. PostGIS permet de la figer dans une vue : un objet nommé qui rejoue la requête à la demande, toujours sur la donnée à jour. La jointure « actifs par secteur » devient une couche equipements_par_zone que QGIS ouvre comme n'importe quelle table.

-- Figer l'analyse "actifs par secteur" dans une vue réutilisable
CREATE VIEW equipements_par_zone AS
SELECT z.nom_zone, count(e.id) AS nb_equipements, z.geom
FROM zones_intervention z
LEFT JOIN equipements e ON ST_Contains(z.geom, e.geom)
GROUP BY z.nom_zone, z.geom;

Pour les analyses lourdes, la vue matérialisée pré-calcule le résultat et le stocke, avec un REFRESH quand la donnée change. On gagne la vitesse d'un export figé sans en perdre la fraîcheur.
Et c'est exactement ce qu'un format fichier ne sait pas faire : une vue est dérivée, vivante, et consommable directement par QGIS ou par un serveur de tuiles comme Martin. L'analyse cesse d'être un geste, elle devient une couche du SI.

Le SQL spatial n'est qu'un canal d'analyse

Tout ceci pourrait laisser croire que PostGIS est l'outil universel de l'analyse spatiale. Il ne l'est pas, et le prétendre serait malhonnête. Le SQL spatial est un canal parmi quatre, chacun avec son terrain de prédilection.

Le SQL spatial gagne quand la donnée est vivante et partagée : elle change, plusieurs personnes l'alimentent, et vous voulez des analyses reproductibles côté serveur sur des volumes moyens à gros.

QGIS reste imbattable pour l'exploration visuelle ponctuelle et la cartographie de rendu. Python s'impose dès qu'on entre dans la data science, le machine learning ou les traitements qui débordent du SQL.

Et pour de l'analytique massive en lecture seule posée sur du stockage objet, DuckDB sur GeoParquet bat PostGIS sans discussion.

Pourquoi ça pèse dans le choix du format

Voilà le point que la plupart des comparatifs de stockage oublient. On choisit souvent un format géospatial sur des critères de volume, de coût ou de portabilité.
La capacité d'analyse en place est un critère au moins aussi structurant, et il penche nettement du côté de la base SQL.

Autrement dit, si votre donnée est destinée à être interrogée, croisée et tenue à jour, vous ne choisissez pas seulement un format de stockage : vous choisissez un moteur d'analyse. C'est l'un des arguments qui font pencher la balance vers PostGIS dans le comparatif des solutions de stockage géospatial.

Là où le SQL spatial s'arrête

Rester honnête, c'est aussi nommer les murs. Le SQL spatial a trois limites qu'il faut connaître avant de tout vouloir faire en base.

Une fois l'analyse faite en base, la diffuser proprement sur le web est un autre métier, traité dans le guide pour diffuser PostGIS en sécurité.

Ce qu'il faut retenir

Le SQL spatial transforme PostGIS d'un entrepôt en moteur d'analyse : jointures spatiales, zones tampon, agrégations par secteur et plus proche voisin remplacent l'essentiel du clic-bouton qu'on fait aujourd'hui à la main.
Ce n'est pas l'outil unique — c'est un canal parmi quatre, pertinent quand la donnée est vivante, partagée et interrogée en continu. Et cette puissance d'analyse en place est, à elle seule, une raison sérieuse de choisir une base SQL plutôt qu'un format fichier.
Vous avez maintenant les cinq familles de fonctions en tête et les motifs de requête qui couvrent la plupart des besoins : de quoi décider ce qui se traite en base, et ce qui reste au desktop ou au script.