> ## Content Index > Fetch the complete content index at: https://www.sfeir.dev/llms.txt > Use this file to discover other available public pages before exploring further. # La donnée géo pour les devs web : formats, projections et standards OGC - URL: https://www.sfeir.dev/data/donnee-geo-pour-devs-web/ - Published: 2026-09-22T08:09:48.000Z - Updated: 2026-09-22T08:09:48.000Z - Description: 🌍 Raster ou vectoriel ? 3857, 4326 ou 2154 ? WMS, WMTS ou OGC API Features ? Le vocabulaire de la donnée géo rangé en une carte mentale pour devs web : formats (GeoJSON, orthophoto), projections et standards OGC, jusqu'à GeoServer qui reprojette à la volée. - Author: Romain Lespinasse - Tags: Data, Cartographie, Web, API, Tutoriel Avant de construire [*ChronoMEL*](https://www.romainlespinasse.dev/chronomel/?ref=sfeir.dev), 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** ? ![Arbre de décision raster ou vectoriel : besoin de cliquer, filtrer ou restyler mène au chemin vectoriel, besoin d'afficher un fond de carte riche mène au chemin raster.](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/09/fork-raster-vectoriel-image.webp) Raster ou vectoriel : l'arbre de décision - **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 : ```js 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 : ```js 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 : ```js 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 ![Les deux chemins de la donnée géo web : raster via WMS/WMTS/GeoServer vers EPSG:3857, vectoriel via GeoJSON/OGC API Features en WGS84, tous deux vers Leaflet](https://storage.ghost.io/c/0b/31/0b31478e-a66a-46f1-8c34-d44388e21192/content/images/2026/09/carte-mentale-image.webp) Carte mentale de la donnée géo web 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.