La donnée géo pour les devs web : formats, projections et standards OGC

Avant de construire ChronoMEL, un projet qui affiche 90 ans d'orthophotos de la métropole lilloise, la donnée géographique m'apparaissait comme un monde à part, plein d'acronymes et de standards que je ne comprenais pas. Pourtant, afficher une carte dans un navigateur ne demande qu'une poignée de concepts bien rangés. Voici la carte mentale que j'aurais aimé avoir avant de m'y mettre, de la nature de la donnée jusqu'aux standards qui la diffusent.

La première bifurcation : raster ou vectoriel

Tout commence par une question : la donnée est-elle une image ou des géométries ?

• Raster : une grille de pixels géoréférencée. Une orthophotographie, une carte d'élévation, une image satellite. Lourd, mais affichable tel quel : le client reçoit une image, point.
• Vectoriel : des objets décrits par des coordonnées (points, lignes, polygones) avec des attributs. Le contour d'une commune, un réseau de rues, des points d'intérêt. Léger, interrogeable, stylable côté client.

Cette distinction commande tout le reste : les formats, les standards de diffusion, et ce qu'on peut faire de la donnée une fois dans le navigateur. On manipule rarement l'un comme l'autre. Règle pratique : si l'on veut cliquer sur un objet pour lire ses attributs, le filtrer ou le restyler à la volée, il faut du vectoriel. Si l'on veut afficher un fond riche (une photo, un relief) sans interaction fine, le raster suffit, et souvent il s'impose, parce que certaines données (une orthophoto de plusieurs gigaoctets) ne peuvent pas transiter en vectoriel jusqu'au navigateur.

L'orthophotographie, le raster par excellence

Une orthophotographie est une photographie aérienne (ou satellite) redressée géométriquement : corrigée des déformations dues au relief, à l'inclinaison de l'objectif et à la perspective. Résultat, une image à échelle homogène qui se superpose à une carte et permet de mesurer, contrairement à une photo aérienne brute, où les distances mentent.

On parle de millésime pour l'année de prise de vue, d'où l'intérêt de comparer plusieurs années pour observer l'évolution d'un territoire. Le redressement s'appuie sur des modèles d'élévation (MNT/MNS), et les versions les plus abouties (« vraie-ortho ») redressent même les bâtiments à la verticale.

Côté fichier, deux formats à connaître :

• GeoTIFF : un TIFF enrichi des informations de géoréférencement (emprise, CRS, résolution). Le format de stockage le plus courant pour du raster géo.
• COG : sa variante moderne, structurée en interne pour qu'un client puisse en lire seulement la portion utile via des requêtes HTTP partielles (Range), sans télécharger le fichier entier. Idéal pour servir de gros rasters depuis un simple stockage objet.

Mais pour l'affichage interactif dans un navigateur, on passe rarement le GeoTIFF brut : on le sert via un standard de diffusion (WMS/WMTS), justement pour éviter au client d'avaler des gigaoctets.

Le format vectoriel de référence : GeoJSON

Côté vectoriel, le web a un favori clair : GeoJSON (RFC 7946), un format JSON pour représenter des données géographiques. Trois briques à connaître :

• une géométrie : Point, LineString, Polygon (et leurs variantes Multi) ;
• une Feature : une géométrie + ses propriétés (properties) ;
• une FeatureCollection : une liste de Feature.

Avec une bibliothèque comme Leaflet, un FeatureCollection s'affiche en une ligne :

L.geoJSON(featureCollection, {
  onEachFeature: (f, layer) => layer.bindPopup(f.properties.nom),
}).addTo(map);

Atout décisif : par défaut, les coordonnées sont en WGS84 (longitude, latitude), exactement ce qu'attendent Leaflet ou Mapbox. Pour les gros jeux, on regarde du côté de TopoJSON (topologie partagée, fichiers plus légers) ou on simplifie les géométries pour réduire le poids.

Le casse-tête des projections

La Terre est ronde, les écrans sont plats : il faut projeter. C'est une source fréquente de bugs difficiles à diagnostiquer. Trois systèmes de référence de coordonnées (CRS) à distinguer, chacun identifié par un code EPSG qui donne un identifiant unique à chaque CRS.

• EPSG:4326 (WGS84) : longitude/latitude en degrés. Le repère « brut » du GPS et de GeoJSON.
• EPSG:3857 (« Web Mercator ») : la projection des fonds de carte web (Google Maps, OpenStreetMap, Leaflet). Elle exprime les positions en mètres. Conforme (elle préserve les angles, donc les formes locales) mais elle déforme les surfaces en s'éloignant de l'équateur, c'est pour ça que le Groenland paraît énorme.
• EPSG:2154 (Lambert-93) : la projection légale de la France métropolitaine, précise au mètre à l'échelle nationale.

Leaflet raisonne nativement en 3857. Or les données françaises sont souvent publiées en 2154. On pourrait être tenté de tout reprojeter soi-même avec proj4/proj4leaflet. La bonne nouvelle : ce n'est presque jamais nécessaire, car le serveur s'en charge (voir plus bas). Dernier piège à connaître : l'ordre des axes change selon le CRS en WMS 1.3.0, une source classique de cartes « décalées » ou retournées.

Diffuser la donnée : les standards OGC

L'OGC normalise la façon dont un serveur expose sa donnée. Quatre standards couvrent l'essentiel du web :

WMS : l'image à la demande

Le WMS renvoie une image de carte (raster) pour une emprise, une taille et un CRS donnés. Le client demande une vue, le serveur la dessine, renvoie un PNG ou un JPEG. Trois opérations :

• GetCapabilities : ce que le service sait faire (couches, projections, formats) ;
• GetMap : l'image pour une emprise (BBOX), une taille, un CRS ;
• GetFeatureInfo : les attributs sous un pixel cliqué.

Toujours avec Leaflet, une couche WMS s'ajoute comme n'importe quelle autre couche de tuiles :

L.tileLayer.wms('https://exemple/geoserver/wms', {
  layers: '1930_ortho', format: 'image/png', transparent: true, version: '1.3.0',
}).addTo(map);

Avantage : n'importe quelle donnée, même très lourde, devient affichable, on reçoit une image, pas des géométries. Inconvénient : chaque vue est calculée à la demande, donc coûteuse et peu cacheable.

WMTS : les tuiles pré-calculées

Le WMTS résout ce coût : au lieu de dessiner à la demande, il sert des tuiles pré-générées (souvent 256×256), organisées en pyramide de niveaux de zoom. Plus rapide, hautement cacheable derrière un CDN, idéal pour le grand public. C'est proche, côté web, des schémas XYZ/TMS (la convention de tuilage {z}/{x}/{y}) qu'utilisent OSM et la plupart des fonds de carte. Règle simple : WMS pour des couches dynamiques ou rarement consultées, WMTS pour un fond stable servi à grande échelle.

OGC API Features : le vectoriel en REST/JSON

Pour le vectoriel, le standard moderne est OGC API Features, le successeur du WFS, le standard XML/GML du vectoriel OGC, toujours très présent sur les services publics. Plus de GML à parser : on navigue une API web classique :

• /collections : les jeux de données disponibles ;
• /collections/{id}/items : les entités, en GeoJSON par défaut ;
• pagination et navigation par liens (rel: next).

Côté client, un simple fetch suffit pour récupérer ce GeoJSON et l'injecter dans Leaflet :

const r = await fetch('https://exemple/ogc/features/v1/collections/communes/items?f=json&limit=1000');
const geojson = await r.json(); // FeatureCollection → L.geoJSON(geojson)

Le CRS de sortie par défaut est CRS84 : du WGS84 avec l'ordre d'axes longitude/latitude, contrairement à EPSG:4326 qui suit officiellement l'ordre inverse (voir le piège d'ordre des axes évoqué plus haut). Résultat : immédiatement consommable côté front avec un simple fetch, sans reprojection.

Le chef d'orchestre : GeoServer

Reste à savoir qui expose tout ça. GeoServer est un serveur géospatial open source (Java) qui publie des données selon ces standards OGC. On y branche des sources (PostGIS, GeoTIFF, shapefile…), on les organise en workspaces et layers, et il les sert en WMS, WMTS, OGC API.

Surtout, il sait reprojeter à la volée : même si son GetCapabilities n'annonce qu'un CRS (par exemple Lambert-93), un GetMap en EPSG:3857 fonctionne souvent quand même, GeoServer convertit. C'est ce qui évite, dans la grande majorité des cas, d'embarquer proj4leaflet côté client. Pour la performance, il embarque GeoWebCache (génération et service de tuiles). Ses alternatives : MapServer, QGIS Server, ou pg_tileserv/Martin pour les tuiles vectorielles.

Conclusion

Voici donc la carte mentale promise en introduction. On se demande d'abord raster ou vectoriel. Pour du raster, c'est WMS (à la demande) ou WMTS (tuilé), souvent via GeoServer qui reprojette vers le 3857 de Leaflet. Pour du vectoriel, c'est GeoJSON, servi en OGC API Features, déjà en WGS84 prêt à afficher. Le reste (les acronymes, les codes EPSG) n'est que du vocabulaire posé sur ces deux chemins.

Pour aller plus loin : les sigles du domaine

• OGC (Open Geospatial Consortium) : l'organisme qui normalise les standards de diffusion géospatiale (WMS, WMTS, OGC API Features…).
• WMS (Web Map Service) : standard OGC qui renvoie une image de carte calculée à la demande.
• WMTS (Web Map Tile Service) : standard OGC qui sert des tuiles raster pré-calculées.
• WFS (Web Feature Service) : standard OGC historique du vectoriel, en XML/GML, remplacé côté web par OGC API Features.
• GML (Geography Markup Language) : le format XML de géométries utilisé par WFS.
• TMS (Tile Map Service) : la convention de tuilage {z}/{x}/{y} utilisée par OSM et la plupart des fonds de carte (schéma souvent appelé XYZ).
• COG (Cloud Optimized GeoTIFF) : variante du GeoTIFF lisible par portions via des requêtes HTTP Range.
• MNT/MNS (Modèle Numérique de Terrain/de Surface) : modèles d'élévation utilisés pour redresser une orthophotographie.
• CRS (Coordinate Reference System) : un système de référence de coordonnées (ex. WGS84, Web Mercator, Lambert-93).
• EPSG : le registre international (à l'origine celui de l'European Petroleum Survey Group) qui attribue un code numérique unique à chaque CRS.
• WGS84 (World Geodetic System 1984) : le système géodésique de référence du GPS, exprimé en longitude/latitude (EPSG:4326).
• CRS84 : l'équivalent de WGS84 mais avec l'ordre d'axes longitude/latitude, utilisé par défaut en sortie d'OGC API Features.