Qu'est-ce que GeoJSON ? Format, types de géométrie et pièges

GeoJSON est le format basé sur JSON que toute carte web moderne sait lire. Si vous avez déjà dessiné un polygone sur une carte Leaflet, stylé une couche vectorielle dans MapLibre ou stocké une zone de service dans PostGIS, vous avez travaillé avec du GeoJSON, même si l'extension du fichier indiquait autre chose.

Ce guide explique ce qu'est réellement GeoJSON, ce que signifient ses types de géométrie, où il apparaît dans les vrais systèmes et quels pièges mordent les équipes lorsque les fichiers GeoJSON quittent le portable d'un développeur pour arriver en production.

Ce qu'est vraiment GeoJSON

GeoJSON est un format ouvert pour encoder des structures de données géographiques, normalisé par l'IETF sous le nom de RFC 7946 en 2016. C'est un sous-ensemble strict de JSON : tout document GeoJSON est du JSON valide, mais la spécification ajoute des règles sur les clés autorisées, sur la structure de la géométrie et sur l'ordre des coordonnées.

Le format est volontairement réduit. Il n'y a que neuf types d'objets de premier niveau dans toute la spec, et un développeur compétent peut tous les garder en tête. Cette petitesse explique pourquoi GeoJSON est devenu la lingua franca de la cartographie web : facile à lire, facile à écrire et facile à valider.

Les coordonnées sont toujours écrites comme [longitude, latitude] (avec une altitude optionnelle en troisième valeur), et le système de référence des coordonnées est fixé à WGS84, le même datum que celui qu'utilise le GPS de votre téléphone. Pas de négociation, pas de métadonnées de projection, pas de débat sur l'ordre des axes. Un seul datum, un seul ordre, partout.

Les types de géométrie

GeoJSON définit sept types de géométrie. Les trois premiers sont les primitives :

• Point : une seule coordonnée, utilisée pour les épingles, les adresses et les capteurs individuels
• LineString : une liste ordonnée de deux coordonnées ou plus, utilisée pour les itinéraires, les routes et les fleuves
• Polygon : un anneau fermé de coordonnées (premier et dernier point identiques), utilisé pour les bâtiments, les parcelles et les frontières administratives

Les trois suivants ne sont que des collections de ces primitives :

• MultiPoint : plusieurs points dans une seule géométrie, utile pour représenter une chaîne de magasins comme une seule entité
• MultiLineString : plusieurs lignes, utilisé pour les itinéraires fragmentés ou les systèmes fluviaux
• MultiPolygon : plusieurs polygones, le bon choix pour tout pays avec des îles (donc, presque tous)

Le septième, GeometryCollection, peut contenir un mélange de tout ce qui précède. La spec en décourage l'usage parce que la plupart des consommateurs le gèrent mal, et vous n'en avez presque jamais besoin. Si vous tendez la main vers un GeometryCollection, c'est généralement le signe que le modèle veut être une FeatureCollection à la place.

Feature et FeatureCollection

Une géométrie seule est rarement utile. Vous devez savoir ce qu'elle représente. C'est à cela que sert Feature : une Feature encapsule une géométrie avec un objet properties qui contient des métadonnées arbitraires.

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [4.8952, 52.3702]
  },
  "properties": {
    "name": "Amsterdam Centraal",
    "type": "station",
    "platforms": 15
  }
}

Une FeatureCollection est une liste de Features. Presque tous les fichiers GeoJSON réels que vous rencontrerez sont des FeatureCollection, parce que les vrais jeux de données contiennent beaucoup de choses.

Le choix de conception crucial est que properties est ouvert. La spec ne dit rien sur les clés qu'il peut contenir ni sur les types de ces valeurs. C'est une fonctionnalité, pas un bug : cela signifie que GeoJSON fonctionne pour le mobilier urbain, les frontières électorales, les zones de livraison et les pistes AIS de navires sans avoir à étendre le format. Cela signifie aussi que les consommateurs doivent rester prudents : si vous dépendez de l'existence de properties.population, validez-la vous-même, parce que le RFC 7946 ne le fera pas.

Où apparaît GeoJSON

Une fois qu'on commence à regarder, GeoJSON est partout dans la stack géospatiale :

• Librairies cartographiques : MapLibre GL, Mapbox GL, Leaflet et OpenLayers consomment tous nativement du GeoJSON comme source de données pour les couches
• Pipelines de tuiles vectorielles : des outils comme Tippecanoe prennent du GeoJSON en entrée et produisent des sets MVT (Mapbox Vector Tile) en sortie
• Specs de styles cartographiques : la Mapbox Style Specification, utilisée par MapLibre, référence GeoJSON comme type de source de première classe
• Bases de données spatiales : PostGIS, BigQuery GIS et Snowflake importent et exportent tous du GeoJSON via des fonctions dédiées
• Sorties d'API : la plupart des API de géocodage, isochrones et routage modernes renvoient des Features GeoJSON pour les résultats, pour que la réponse puisse être déposée directement sur une carte
• Polylignes d'itinéraires : les réponses de navigation incluent couramment une géométrie LineString pour l'itinéraire, prête à afficher
• Partage de données : portails open data, exports OpenStreetMap et publications de frontières administratives gouvernementales prennent GeoJSON par défaut quand ils visent les usagers web

Si un outil sait parler le moindre format géospatial, il sait presque certainement parler GeoJSON.

Pièges en production

GeoJSON est tolérant le premier jour et impitoyable le quatre-vingt-dixième. Les pièges qui attrapent les équipes :

Longitude d'abord. Le RFC 7946 fixe l'ordre comme [lon, lat]. Les humains, les adresses et la plupart de la documentation écrivent lat, lon. Les intervertir est le bug GeoJSON le plus courant, et votre point se retrouve dans le mauvais océan.

Sens de bobinage des polygones. Le RFC 7946 spécifie que les anneaux extérieurs doivent être en sens antihoraire et les anneaux intérieurs (trous) en sens horaire. Beaucoup de fichiers GeoJSON anciens ignorent cela. Certains moteurs de rendu s'en moquent, d'autres (notamment Mapbox GL avec des polygones traversant l'antiméridien) rendent le polygone à l'inverse de ce que vous vouliez : une petite île devient un trou dans l'océan qui couvre le reste du monde.

Gestion de l'antiméridien. La géométrie qui traverse le méridien 180 / -180 doit être découpée selon la spec. Les polygones naïfs tracés à travers le Pacifique se rendent comme une fine bande enroulée par le long chemin autour de la planète.

Pas de support natif d'autre CRS que WGS84. Le RFC 7946 a délibérément retiré le membre crs des anciennes versions. Si vos données sont dans une grille nationale (British National Grid, RD New, EPSG:3857), vous devez les reprojeter en WGS84 avant la sérialisation. Les outils qui émettent du GeoJSON non WGS84 sont techniquement non conformes.

Taille de fichier. Une FeatureCollection avec des millions de polygones détaillés peut gonfler à plusieurs gigaoctets. Pour la livraison au navigateur, basculez sur des tuiles vectorielles, simplifiez la géométrie avec Douglas-Peucker, ou streamez avec du GeoJSON délimité par sauts de ligne (.ndjson).

Validation. Utilisez un linter comme GeoJSONLint ou la librairie geojson-validation en CI. Détecter un sens de bobinage invalide ou des coordonnées interverties au build coûte moins cher que de le découvrir via un ticket client.

GeoJSON dans MapAtlas

GeoJSON est le format d'échange de données par défaut dans toute la plateforme MapAtlas. Le produit Dynamic Maps accepte directement des sources GeoJSON pour les superpositions personnalisées, le stylage et les couches interactives, sans aucun prétraitement.

L'API Geocoding renvoie les adresses trouvées sous forme de Features GeoJSON, pour qu'un résultat de géocodage direct puisse être déposé directement sur une carte ou stocké dans PostGIS sans remappage de champs. L'API Isochrone renvoie les zones de temps de trajet sous forme de polygones GeoJSON, ce qui veut dire qu'une requête "lieux atteignables en 15 minutes" est à un fetch et un appel addSource d'être à l'écran.

GeoJSON n'a rien de glamour. C'est un sous-ensemble réduit et opinionné de JSON avec un ordre de coordonnées fixe et une poignée de types de géométrie. Mais c'est le format qui permet à chaque couche d'une stack de localisation moderne, de la base de données spatiale au canvas cartographique, de s'accorder sur ce qu'est un lieu. Mettez la longitude dans le bon ordre, validez le bobinage, et le reste de la stack a tendance à se débrouiller seul.