GeoJSON zu GeoParquet Konverter

Warum GeoJSON in GeoParquet umwandeln

GeoJSON lässt sich leicht lesen und von Hand schreiben, und genau deshalb wurde es zum Standardformat für den Austausch von Kartendaten im Web. Doch dieselbe Einfachheit hat ihren Preis, sobald ein Datensatz über einige tausend Features hinauswächst. GeoJSON speichert jede Koordinate als reinen Text innerhalb einer JSON-Struktur, und ein Reader muss die gesamte Datei Klammer für Klammer parsen, bevor er sich auch nur eine einzige Eigenschaft ansehen kann. Es gibt keine Möglichkeit, nur die benötigten Spalten zu lesen, und keine Möglichkeit, die Ausdehnung einer Datei zu kennen, ohne sie vollständig zu öffnen und zu durchsuchen.

GeoParquet löst dieses Problem, indem es sich die spaltenbasierte Speicherung ausleiht, die Data Engineers bereits für große tabellarische Datensätze verwenden. Jede Eigenschaft wird zu einer eigenen Spalte, die Geometrie wird zu einer binären Spalte aus WKB-Werten, und die Datei trägt einen kleinen Metadatenblock, der die Geometrietypen und die gesamte Bounding Box vorab angibt. Ein Tool wie DuckDB oder GeoPandas kann dann nur die Spalten lesen, die eine Abfrage tatsächlich braucht, Dateien überspringen, deren Bounding Box sich nicht mit einem interessierenden Gebiet überschneidet, und sich auf die eingebaute Komprimierung von Parquet verlassen, um wiederholte Werte wie Ortsnamen oder Statuscodes zu verkleinern.

Dieses Tool existiert, um genau diesen ersten Schritt reibungslos zu machen. Statt GDAL, eine Python-Umgebung oder ein Kommandozeilen-Tool zu installieren, können Sie eine GeoJSON-Datei einfach in Ihrem Browser ablegen und innerhalb von Sekunden eine funktionierende GeoParquet-Datei zurückbekommen. Die Umwandlung läuft clientseitig mithilfe von WebAssembly ab, sodass das Tool egal ob Ihre Datei zehn Features oder hunderttausend enthält gleich funktioniert, und Ihre Daten werden nirgendwohin gesendet.

GeoParquet: Geschichte, Struktur und Fakten

GeoParquet baut auf Apache Parquet auf, einem spaltenorientierten Dateiformat, das Twitter und Cloudera 2013 als Open-Source-Projekt für die Verarbeitung großer Datenmengen auf Hadoop veröffentlicht haben. Parquet selbst weiß nicht, was eine Koordinate ist; es speichert lediglich typisierte Spalten effizient, mit spaltenweiser Komprimierung und Metadaten, die es einem Reader erlauben, ganze Datenblöcke zu überspringen, die er nicht braucht.

Die GeoParquet-Spezifikation fügt diesem allgemein einsetzbaren Format georäumliche Regeln hinzu. Sie wurde von einer offenen Community unter dem Dach des Cloud-Native Geospatial Forum entwickelt, wobei die erste Version 1.0.0 im August 2023 veröffentlicht wurde. Version 1.1.0, veröffentlicht 2024, fügte optionale Unterstützung für eine Bounding-Box-Spalte pro Zeile sowie ein "covering"-Feld hinzu, beide darauf ausgelegt, einem Reader das Filtern von Zeilen zu ermöglichen, ohne jede Geometrie dekodieren zu müssen.

Ein paar Fakten, die es wert sind zu wissen: GeoParquet speichert Geometrie standardmäßig als WKB, sodass jede Sprache mit einer WKB-Bibliothek die Geometriespalte lesen kann, auch ohne GeoParquet-spezifisches Werkzeug. Die Spezifikation geht von der Reihenfolge Längengrad/Breitengrad in OGC:CRS84 aus, sofern eine Datei nicht mittels PROJJSON ein anderes Koordinatenreferenzsystem angibt. Und GeoParquet ist längst über den Experimentierstatus hinaus im Einsatz: Overture Maps, das gemeinsame Kartierungsprojekt von Amazon, Meta, Microsoft und TomTom, veröffentlicht seinen gesamten globalen Datensatz, Gebäude, Orte, Straßen und Verwaltungsgrenzen, als GeoParquet, und Source Cooperative hostet Dutzende öffentliche GeoParquet-Datensätze, die sich direkt aus dem Cloud-Speicher abfragen lassen.

Kurz gesagt: GeoParquet ist kein neues Geometriemodell. Es ist eine Übereinkunft darüber, wie man eine bestehende, gut verstandene Geometriekodierung in ein schnelles, spaltenbasiertes Dateiformat packt, auf das sich der Rest der Data-Engineering-Welt bereits verlässt.

Schritt-für-Schritt-Anleitung

Schritt 1

Wählen Sie eine .geojson-Datei von Ihrem Computer aus, fügen Sie GeoJSON-Text direkt in das Feld ein, oder klicken Sie auf "Try sample", um eine kleine, fertige Datei mit deutschen Städten zu laden.

Schritt 2

Sobald Ihr GeoJSON geladen ist, klicken Sie auf "Convert to GeoParquet". Die Umwandlung läuft vollständig in Ihrem Browser ab und ist bei typischen Dateien in einem Bruchteil einer Sekunde abgeschlossen.

Schritt 3

Es erscheint eine Zusammenfassung: wie viele Features umgewandelt wurden, welche Geometrietypen gefunden wurden, die Bounding Box, die Eigenschaftsspalten und die resultierende Dateigröße.

Schritt 4

Die Ausgangs-Features werden auf der Karte gezeichnet, damit Sie bestätigen können, dass die richtigen Daten umgewandelt wurden, bevor Sie irgendetwas herunterladen.

Schritt 5

Klicken Sie auf "Download converted.parquet", um die fertige GeoParquet-Datei auf Ihrem Computer zu speichern.

Sechs Anwendungsfälle aus der Praxis

Wo GeoParquet tatsächlich zum Einsatz kommt, jenseits des Dateiformats selbst.

1. Große offene Datensätze veröffentlichen. Projekte wie Overture Maps veröffentlichen globale Gebäude- und Ortsdatensätze als GeoParquet, weil eine einzige Datei Millionen von Features enthalten kann und dabei bei regionalen Abfragen trotzdem schnell bleibt.
2. Geodaten in ein Cloud-Data-Warehouse laden. BigQuery, Snowflake und DuckDB lesen alle Parquet nativ. Wandelt man GeoJSON zuerst in GeoParquet um, lädt die Geometriespalte zusammen mit dem Rest der Tabelle, ohne separaten Importschritt.
3. Machine-Learning-Pipelines mit Daten versorgen. Trainings-Pipelines, die viele kleine Dateien lesen, profitieren vom spaltenbasierten Aufbau von Parquet: Ein Modell, das nur Koordinaten und eine Label-Spalte braucht, kann jede andere Eigenschaft überspringen, statt pro Zeile ein vollständiges GeoJSON-Objekt zu parsen.
4. Kommunale und behördliche GIS-Datensätze archivieren. Open-Data-Portale, die derzeit Stadtgrenzen, Flächennutzungspläne oder Flurstücksdaten als GeoJSON bereitstellen, können daneben eine GeoParquet-Kopie anbieten und Analysten damit eine kleinere, schneller abfragbare Datei mit exakt denselben Daten geben.
5. Satelliten- und Fernerkundungs-Footprints katalogisieren. Szenen und Kachel-Footprints aus Satellitenbildern sind von Natur aus tabellarisch: eine Geometrie plus Metadaten wie Aufnahmedatum und Wolkenbedeckung pro Zeile, genau die Form, für die ein spaltenbasiertes Format wie Parquet gebaut ist.
6. Daten für eine Web-Mapping-Pipeline vorverarbeiten. Data Engineers, die Vektor-Kacheln oder Karten-Backends bauen, wandeln rohes GeoJSON häufig zuerst in GeoParquet um, da nachgelagerte Tools wie DuckDB Spatial oder Apache Sedona Millionen von Features weit schneller filtern und umformen können als erneutes Parsen von JSON-Text.

Technische Fragen und Antworten

Zehn häufige Fragen dazu, wie dieser Konverter funktioniert, direkt beantwortet.

Die Mathematik hinter der Umwandlung

Die Umwandlung enthält keine Mehrdeutigkeit und keine Schätzung. Jeder Schritt ist eine feste, umkehrbare Operation auf Bytes und Zahlen, und genau das macht einen Byte-für-Byte-Roundtrip überhaupt erst möglich. Hier ist, was mit Ihren Daten tatsächlich passiert.

1. Koordinaten sind bereits IEEE-754-Doubles

Eine GeoJSON-Koordinate wie 13.404954 wird vom JSON-Parser von JavaScript in einen 64-Bit-IEEE-754-Double geparst: 1 Vorzeichenbit, 11 Exponentenbits und 52 Mantissenbits, was etwa 15 bis 17 signifikante Dezimalstellen an Genauigkeit ergibt. WKB speichert jede Koordinate als genau denselben 8-Byte-Double, geschrieben in Little-Endian-Byte-Reihenfolge. Hier findet keine Rundung und kein Formatwechsel statt; die Umwandlung kopiert einfach dieselben 64 Bits, die bereits im Speicher lagen, in den Ausgabepuffer.

2. WKB-Byte-Layout und Größe

Jeder WKB-Wert beginnt mit einem 1-Byte-Flag für die Byte-Reihenfolge und einem 4-Byte-Ganzzahlcode für den Geometrietyp, sodass der feste Header immer 5 Bytes groß ist. Danach hängt die Größe vom Geometrietyp ab. Für einen Ring aus n Koordinatenpaaren (verwendet von LineString und jedem Ring eines Polygon) speichern 4 Bytes die Punktanzahl, und danach kostet jedes Paar 16 Bytes (8 für X, 8 für Y):

ring_bytes(n) = 4 + 16n

Point           = 5 + 16                                  = 21 bytes
LineString(n)   = 5 + ring_bytes(n)
Polygon(rings)  = 5 + 4 + Σ ring_bytes(ring)   for each ring
MultiPoint(n)   = 5 + 4 + 21n                  (each point repeats the 5-byte header)
MultiLineString = 5 + 4 + Σ (5 + ring_bytes(line))   for each line
MultiPolygon    = 5 + 4 + Σ (5 + 4 + Σ ring_bytes(ring))   for each polygon, each ring

Das ist präzise, nicht bloß angenähert: Der Konverter berechnet die exakte Byte-Größe einer Geometrie, bevor er ihren Puffer alloziert, schreibt den Header und jede Koordinate mit einem DataView und ändert die Größe des Puffers während des Schreibens nie. Eine einfache Zwei-Punkte-Linie belegt daher jedes Mal, auf jeder Plattform, exakt 5 + 4 + 32 = 41 Bytes.

3. Die Bounding Box entsteht in einem einzigen linearen Durchlauf

Die Bounding Box [minX, minY, maxX, maxY] wird berechnet, indem jedes Koordinatenpaar genau einmal besucht wird, während ein laufendes Minimum und Maximum geführt werden, eine O(n)-Reduktion, wobei n die Gesamtzahl der Koordinatenpaare über alle Features hinweg ist. Es gibt kein Sortieren und keinen zweiten Durchlauf: Jede neue Koordinate muss nur mit den vier laufenden Werten verglichen werden, sodass die Kosten für die Berechnung der Bbox linear mit der Größe des Datensatzes wachsen, nie schneller und nie langsamer.

4. Warum die Datei am Ende kleiner ausfällt

Ein GeoJSON-Koordinatenpaar wie [13.404954, 52.520008] belegt als Text rund 20 Bytes, einschließlich Klammern und Komma. Dasselbe Paar als zwei WKB-Doubles belegt exakt 16 Bytes, für sich genommen ein bescheidener Gewinn. Der größere Gewinn kommt aus der spaltenweisen Kodierung von Parquet: Eine Text-Eigenschaftsspalte wie ein Ländername, der sich über Tausende Zeilen wiederholt, lässt sich unter Dictionary-Encoding extrem gut komprimieren, da Parquet nur jeden eindeutigen String einmal speichern muss, plus eine kurze Ganzzahlreferenz pro Zeile. Numerische Spalten profitieren ähnlich von Lauflängen- und Bit-Packing-Kodierungen, wenn sich Werte wiederholen oder in einem engen Bereich liegen. Nichts davon steht einem zeilenbasierten Textformat wie GeoJSON zur Verfügung, bei dem jeder Wert in jeder einzelnen Zeile erneut als Text geschrieben wird.

Zusammengenommen ist die Umwandlungs-Pipeline in jedem Schritt deterministisch: einen bekannten IEEE-754-Double parsen, ihn in ein bekanntes Byte-Layout schreiben, ein laufendes Min/Max führen und das Ergebnis an einen allgemeinen spaltenbasierten Kompressor übergeben. Genau dieser Determinismus macht den Roundtrip verlustfrei, und deshalb erzeugt dieselbe GeoJSON-Datei, zweimal auf zwei verschiedenen Rechnern umgewandelt, byte-identische GeoParquet-Ausgaben.