Was ist GeoJSON? Format, Geometrie-Typen und Praxisstolpersteine

GeoJSON ist das JSON-basierte Format, das jede moderne Web-Map liest. Wer jemals ein Polygon auf einer Leaflet-Karte gezeichnet, einen Vector-Layer in MapLibre gestylt oder ein Servicegebiet in PostGIS gespeichert hat, hat mit GeoJSON gearbeitet, selbst wenn die Dateiendung etwas anderes hieß.

Dieser Leitfaden erklärt, was GeoJSON tatsächlich ist, was die Geometrie-Typen bedeuten, wo es in realen Systemen auftaucht und welche Stolperfallen Teams treffen, sobald GeoJSON-Dateien das Laptop des Entwicklers verlassen und in die Produktion gehen.

Was GeoJSON wirklich ist

GeoJSON ist ein offenes Format zur Kodierung geografischer Datenstrukturen, 2016 von der IETF als RFC 7946 standardisiert. Es ist eine strikte Teilmenge von JSON: jedes GeoJSON-Dokument ist gültiges JSON, doch die Spec ergänzt Regeln darüber, welche Schlüssel erlaubt sind, wie Geometrie strukturiert ist und wie Koordinaten geordnet werden.

Das Format ist bewusst klein. In der gesamten Spec gibt es nur neun Top-Level-Objekttypen, und ein kompetenter Entwickler hat sie alle im Kopf. Genau diese Kompaktheit hat GeoJSON zur Lingua franca des Web-Mappings gemacht: leicht zu lesen, leicht zu schreiben, leicht zu validieren.

Koordinaten werden immer als [longitude, latitude] geschrieben (mit optionaler Altitude als drittem Wert), und das Koordinatenreferenzsystem ist auf WGS84 fixiert, dasselbe Datum, das auch das Smartphone-GPS nutzt. Keine Verhandlung, keine Projektionsmetadaten, keine Achsenreihenfolge-Diskussion. Ein Datum, eine Reihenfolge, überall.

Geometrie-Typen

GeoJSON definiert sieben Geometrie-Typen. Die ersten drei sind die Primitiven:

• Point: eine einzelne Koordinate, für Pins, Adressen und Einzelsensoren
• LineString: eine geordnete Liste aus zwei oder mehr Koordinaten, für Routen, Straßen und Flüsse
• Polygon: ein geschlossener Ring aus Koordinaten (erster und letzter Punkt identisch), für Gebäude, Flurstücke und Verwaltungsgrenzen

Die nächsten drei sind schlicht Sammlungen dieser Primitiven:

• MultiPoint: viele Punkte in einer Geometrie, sinnvoll, um eine Filialkette als ein Feature zu repräsentieren
• MultiLineString: viele LineStrings, für fragmentierte Routen oder Flusssysteme
• MultiPolygon: viele Polygone, die richtige Wahl für jedes Land mit Inseln (also fast alle)

Der siebte Typ, GeometryCollection, kann eine Mischung aus allen oben genannten halten. Die Spec rät von ihm ab, weil die meisten Konsumenten schlecht damit umgehen, und Sie brauchen ihn fast nie. Wer nach GeometryCollection greift, modelliert in der Regel eigentlich eine FeatureCollection.

Feature und FeatureCollection

Eine Geometrie allein ist selten nützlich. Sie müssen wissen, was sie repräsentiert. Genau dafür gibt es Feature: ein Feature umschließt eine Geometrie mit einem properties-Objekt, das beliebige Metadaten hält.

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

Eine FeatureCollection ist eine Liste von Features. Fast jede reale GeoJSON-Datei in freier Wildbahn ist eine FeatureCollection, weil reale Datensätze viele Dinge enthalten.

Die entscheidende Designentscheidung: properties ist offen. Die Spec sagt nichts darüber, welche Schlüssel oder Werttypen erlaubt sind. Das ist ein Feature, kein Bug: GeoJSON funktioniert für Stadtmöblierung, Wahlbezirke, Liefergebiete und AIS-Schiffsspuren, ohne das Format erweitern zu müssen. Es bedeutet aber auch, dass Konsumenten vorsichtig sein müssen: Wenn Sie sich darauf verlassen, dass properties.population existiert, validieren Sie es selbst, denn RFC 7946 tut es nicht.

Wo GeoJSON zum Einsatz kommt

Wer einmal hinschaut, sieht GeoJSON überall im Geospatial-Stack:

• Kartenbibliotheken: MapLibre GL, Mapbox GL, Leaflet und OpenLayers konsumieren GeoJSON nativ als Datenquelle für Layer
• Vector-Tile-Pipelines: Tools wie Tippecanoe nehmen GeoJSON entgegen und produzieren MVT-Sets (Mapbox Vector Tiles)
• Map-Style-Specs: die Mapbox Style Specification, die auch MapLibre nutzt, referenziert GeoJSON als First-Class-Source-Type
• Räumliche Datenbanken: PostGIS, BigQuery GIS und Snowflake importieren und exportieren GeoJSON über dedizierte Funktionen
• API-Outputs: die meisten modernen Geocoding-, Isochrone- und Routing-APIs liefern Ergebnisse als GeoJSON-Features, sodass die Antwort direkt auf eine Karte fällt
• Routen-Polylines: Navigationsantworten enthalten regelmäßig eine LineString-Geometrie für die Route, fertig zum Rendern
• Datenaustausch: Open-Data-Portale, OpenStreetMap-Exporte und behördliche Grenzdaten setzen für Web-Konsumenten standardmäßig auf GeoJSON

Wenn ein Werkzeug überhaupt ein Geospatial-Format spricht, dann fast sicher GeoJSON.

Stolperfallen im Produktivbetrieb

GeoJSON ist am ersten Tag nachsichtig und am neunzigsten unnachgiebig. Die häufigsten Fallen:

Longitude zuerst. RFC 7946 fixiert die Reihenfolge als [lon, lat]. Menschen, Adressen und die meiste Doku schreiben lat, lon. Sie zu vertauschen ist der häufigste GeoJSON-Bug, und der Punkt landet im falschen Ozean.

Polygon-Wicklungsrichtung. RFC 7946 schreibt vor, dass Außenringe gegen den Uhrzeigersinn und Innenringe (Löcher) im Uhrzeigersinn laufen. Viele ältere GeoJSON-Dateien ignorieren das. Manche Renderer stört es nicht, andere (etwa Mapbox GL bei Antimeridian-querenden Polygonen) zeichnen das Polygon invers: aus einer kleinen Insel wird ein Loch im Ozean, das den Rest des Globus überdeckt.

Antimeridian-Behandlung. Geometrie, die den 180/-180-Meridian quert, muss laut Spec geteilt werden. Naive Polygone quer über den Pazifik rendern als dünner Streifen, der den langen Weg um den Planeten nimmt.

Kein nativer CRS-Support jenseits WGS84. RFC 7946 hat das ältere crs-Member bewusst entfernt. Wenn Ihre Daten in einem nationalen Gitter liegen (British National Grid, RD New, EPSG:3857), müssen Sie vor der Serialisierung nach WGS84 reprojizieren. Tools, die nicht-WGS84-GeoJSON ausgeben, sind technisch nicht konform.

Dateigröße. Eine FeatureCollection mit Millionen detaillierter Polygone bläht sich schnell auf Gigabytes. Für die Browser-Auslieferung wechseln Sie auf Vector Tiles, vereinfachen die Geometrie mit Douglas-Peucker oder streamen mit Newline-getrenntem GeoJSON (.ndjson).

Validierung. Nutzen Sie einen Linter wie GeoJSONLint oder die Bibliothek geojson-validation in der CI. Eine ungültige Wicklungsrichtung oder vertauschte Koordinaten zur Build-Zeit zu finden ist günstiger als sie aus einem Kunden-Ticket zu lernen.

GeoJSON in MapAtlas

GeoJSON ist das Default-Datenaustauschformat in der gesamten MapAtlas-Plattform. Das Produkt Dynamic Maps akzeptiert GeoJSON-Quellen direkt für eigene Overlays, Stylings und interaktive Layer, ohne Vorverarbeitung.

Die Geocoding API liefert getroffene Adressen als GeoJSON-Features, sodass ein Forward-Geocode-Ergebnis ohne Feld-Remapping direkt auf eine Karte fällt oder in PostGIS landet. Die Isochrone API liefert Reisezeit-Flächen als GeoJSON-Polygone, sodass eine Anfrage nach "Orten erreichbar in 15 Minuten" einen Fetch und einen addSource-Call vom Bildschirm trennt.

GeoJSON ist nicht glamourös. Es ist eine kleine, meinungsstarke Teilmenge von JSON mit fester Koordinatenreihenfolge und einer Handvoll Geometrie-Typen. Aber es ist das Format, in dem sich jede Schicht eines modernen Location-Stacks, von der räumlichen Datenbank bis zum Map-Canvas, darüber einig ist, was ein Ort ist. Stimmen Longitude-Reihenfolge und Wicklung, kümmert sich der Rest des Stacks meistens von selbst.