GeoJSON is het JSON-gebaseerde format dat elke moderne webkaart kan lezen. Als je ooit een polygoon op een Leaflet-kaart hebt getekend, een vector-laag in MapLibre hebt gestyled of een servicegebied in PostGIS hebt opgeslagen, heb je met GeoJSON gewerkt, zelfs als de bestandsextensie iets anders zei.
Deze gids legt uit wat GeoJSON daadwerkelijk is, wat zijn geometrietypen betekenen, waar het opduikt in echte systemen, en de valkuilen die teams bijten wanneer GeoJSON-bestanden de laptop van een developer verlaten en productie raken.
Wat GeoJSON werkelijk is
GeoJSON is een open format voor het encoderen van geografische datastructuren, gestandaardiseerd door de IETF als RFC 7946 in 2016. Het is een strikt subset van JSON: elk GeoJSON-document is valide JSON, maar de spec voegt regels toe over welke keys toegestaan zijn, hoe geometrie gestructureerd is en hoe coördinaten geordend zijn.
Het format is bewust klein. Er zijn maar negen top-level objecttypen in de hele spec, en een competente developer kan ze allemaal in z'n hoofd houden. Die kleinheid is waarom GeoJSON de lingua franca van web-mapping is geworden: makkelijk te lezen, makkelijk te schrijven en makkelijk te valideren.
Coördinaten worden altijd geschreven als [longitude, latitude] (met optionele altitude als derde waarde), en het coördinatenreferentiesysteem is gefixeerd op WGS84, dezelfde datum die de GPS van je telefoon gebruikt. Geen onderhandeling, geen projectiemetadata, geen as-volgorde-debat. Eén datum, één volgorde, overal.
Geometrietypen
GeoJSON definieert zeven geometrietypen. De eerste drie zijn de primitieven:
- Point: één coördinaat, gebruikt voor pinnen, adressen en individuele sensoren
- LineString: een geordende lijst van twee of meer coördinaten, gebruikt voor routes, wegen en rivieren
- Polygon: een gesloten ring van coördinaten (eerste en laatste punt identiek), gebruikt voor gebouwen, percelen en administratieve grenzen
De volgende drie zijn simpelweg verzamelingen van die primitieven:
- MultiPoint: veel punten in één geometrie, nuttig om een keten winkels te representeren als één feature
- MultiLineString: veel line strings, gebruikt voor gefragmenteerde routes of riviersystemen
- MultiPolygon: veel polygonen, de juiste keuze voor elk land met eilanden (dus bijna allemaal)
De zevende, GeometryCollection, kan een mix van bovenstaande bevatten. De spec ontmoedigt het omdat de meeste consumers het slecht afhandelen, en je hebt het bijna nooit nodig. Als je naar GeometryCollection grijpt, is het meestal een teken dat het model eigenlijk een FeatureCollection wil zijn.
Feature en FeatureCollection
Een geometrie alleen is zelden nuttig. Je moet weten wat het representeert. Daar is Feature voor: een Feature omhult een geometrie met een properties-object dat willekeurige metadata bevat.
{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [4.8952, 52.3702]
},
"properties": {
"name": "Amsterdam Centraal",
"type": "station",
"platforms": 15
}
}
Een FeatureCollection is een lijst Features. Bijna elk echt GeoJSON-bestand dat je in het wild tegenkomt is een FeatureCollection, omdat echte datasets veel dingen bevatten.
De cruciale ontwerpkeuze is dat properties open is. De spec zegt niets over welke keys het kan bevatten of welke types die waarden moeten hebben. Dat is een feature, geen bug: het betekent dat GeoJSON werkt voor straatmeubilair, kiesgrenzen, bezorgzones en AIS-scheepstracks zonder het format uit te hoeven breiden. Het betekent ook dat consumers voorzichtig moeten zijn: als je afhankelijk bent van het bestaan van properties.population, valideer dat zelf, want RFC 7946 zal dat niet doen.
Waar GeoJSON opduikt
Zodra je begint te kijken, is GeoJSON overal in de geospatial-stack:
- Kaartbibliotheken: MapLibre GL, Mapbox GL, Leaflet en OpenLayers consumeren GeoJSON allemaal native als databron voor lagen
- Vector-tile-pipelines: tools als Tippecanoe nemen GeoJSON aan en produceren MVT (Mapbox Vector Tile)-sets
- Map-style-specs: de Mapbox Style Specification, gebruikt door MapLibre, refereert GeoJSON als first-class brontype
- Ruimtelijke databases: PostGIS, BigQuery GIS en Snowflake importeren en exporteren GeoJSON via dedicated functies
- API-outputs: de meeste moderne geocoding-, isochrone- en routing-APIs geven GeoJSON Features terug voor resultaten, zodat de response direct op een kaart kan
- Route-polylines: navigatie-responses bevatten vaak een LineString-geometrie voor de route, klaar om te renderen
- Datadeling: open-data-portalen, OpenStreetMap-exports en overheidsgrenzen-releases defaulten op GeoJSON wanneer ze webgebruikers targeten
Als een tool überhaupt een geospatial-format kan spreken, spreekt het vrijwel zeker GeoJSON.
Valkuilen in productie
GeoJSON is vergevingsgezind op dag één en niet vergevingsgezind op dag negentig. De vallen die teams vangen:
Longitude eerst. RFC 7946 fixeert de volgorde als [lon, lat]. Mensen, adressen en de meeste documentatie schrijven lat, lon. Ze verwisselen is de meest voorkomende GeoJSON-bug, en je punt eindigt in de verkeerde oceaan.
Polygoon-windrichting. RFC 7946 specificeert dat exterior rings tegen de klok in moeten zijn en interior rings (gaten) met de klok mee. Veel oudere GeoJSON-bestanden negeren dit. Sommige renderers maakt het niet uit, andere (met name Mapbox GL met antimeridiaan-kruisende polygonen) renderen de polygoon als de inverse van wat je wilde: een klein eilandje wordt een gat in de oceaan dat de rest van de wereld bedekt.
Antimeridiaan-handling. Geometrie die de 180/-180-meridiaan kruist moet gesplitst worden volgens de spec. Naïeve polygonen getekend over de Pacific renderen als een dunne strip die lang om de planeet heen gewikkeld is.
Geen native CRS-ondersteuning buiten WGS84. RFC 7946 verwijderde bewust het oudere crs-lid. Als je data in een nationaal grid zit (British National Grid, RD New, EPSG:3857), moet je herprojecteren naar WGS84 voor serialisatie. Tools die niet-WGS84 GeoJSON emitteren zijn technisch non-conform.
Bestandsgrootte. Een FeatureCollection met miljoenen gedetailleerde polygonen kan opzwellen tot gigabytes. Voor browser-delivery, schakel over op vector tiles, vereenvoudig geometrie met Douglas-Peucker, of stream met newline-delimited GeoJSON (.ndjson).
Validatie. Gebruik een linter zoals GeoJSONLint of de geojson-validation-bibliotheek in CI. Invalide windrichting of verwisselde coördinaten op build-time vangen is goedkoper dan ze vangen vanuit een klantticket.
GeoJSON in MapAtlas
GeoJSON is het standaard data-uitwisselingsformat over het MapAtlas-platform. Het Dynamic Maps-product accepteert GeoJSON-bronnen direct voor custom overlays, styling en interactieve lagen, zonder preprocessing.
De Geocoding API geeft gematchte adressen terug als GeoJSON Features, zodat een forward-geocoderesultaat direct op een kaart kan worden geplaatst of in PostGIS opgeslagen zonder velden te remappen. De Isochrone API geeft reistijdgebieden terug als GeoJSON-polygonen, wat betekent dat een "plekken bereikbaar binnen 15 minuten"-query één fetch en één addSource-call van het scherm verwijderd is.
GeoJSON is niet glamoureus. Het is een klein, opinionated subset van JSON met een vaste coördinaatvolgorde en een handvol geometrietypen. Maar het is het format dat elke laag van een moderne locatiestack, van ruimtelijke database tot map-canvas, in staat stelt het eens te worden over wat een plek is. Krijg de longitude-volgorde goed, valideer de windrichting, en de rest van de stack zorgt vaak voor zichzelf.
Veelgestelde vragen
Wat is GeoJSON?
GeoJSON is een JSON-gebaseerd open format voor het encoderen van geografische data, gestandaardiseerd als RFC 7946 door de IETF. Het definieert een kleine set geometrietypen (Point, LineString, Polygon en hun multi-varianten) plus Feature- en FeatureCollection-objecten die geometrie omhullen met willekeurige properties. Coördinaten worden altijd geschreven als longitude, latitude op de WGS84-datum, wat is wat elke moderne webkaartbibliotheek verwacht.
Wat is het verschil tussen GeoJSON en JSON?
GeoJSON is een strikt subset van JSON met extra regels. Elk GeoJSON-document is valide JSON, maar niet elk JSON-document is valide GeoJSON. De spec fixeert de top-level objecttypen, de structuur van geometrie-objecten, de coördinaatvolgorde (longitude eerst) en het coördinatenreferentiesysteem (WGS84). Alles buiten die regels is gewoon JSON dat toevallig geografische data bevat.
Wanneer moet ik GeoJSON gebruiken in plaats van een shapefile of KML?
Gebruik GeoJSON wanneer de data door een webstack moet stromen: APIs, browsers, databases zoals PostGIS, of MapLibre, Leaflet, Mapbox GL of OpenLayers. Shapefiles zijn nog steeds gangbaar in desktop GIS maar leveren als vier of meer bestanden en gebruiken een binair format uit de jaren 90. KML is prima voor Google Earth maar wijdlopig en XML-gebaseerd. GeoJSON wint voor alles dat JSON APIs raakt.
Waarom zijn GeoJSON-coördinaten longitude eerst?
RFC 7946 fixeert de volgorde als longitude, latitude, optionele altitude. Dit matcht met de x, y, z-conventie die in de meeste graphics- en GIS-systemen gebruikt wordt. Het is het tegenovergestelde van hoe mensen coördinaten schrijven (latitude eerst, zoals in 51.5, -0.1) en is de meest voorkomende bug bij het zelf bouwen van GeoJSON: verwissel de twee waarden en je punt landt op het verkeerde halfrond. Altijd longitude eerst in GeoJSON.

