Neues OSM-Dateiformat GOB: 30 % kleiner als PBF und 5-mal schneller beim Import

• Um den weltweit gewaltigen OpenStreetMap-(OSM-)Datensatz schneller und effizienter zu verarbeiten, wurde das neue Dateiformat GOB (Geo-Object Bundle) eingeführt
• GOB ist eine komprimierte Version der bestehenden Geo-Object Library (GOL), bei der Indizes entfernt wurden, um die Größe zu reduzieren und die Verarbeitung zu beschleunigen
• GOB-Dateien sind im Durchschnitt 30 % kleiner als PBF, etwa halb so groß wie GOL, und der Import ist 5-mal schneller
• Dank der kachelbasierten Struktur lassen sich regionale Ausschnitte leicht extrahieren und zusammenführen, außerdem ist schnelles Laden auch auf schwächerer Hardware möglich
• Metadaten und Änderungshistorie sind nicht enthalten, dennoch ist das Format für Verteilung und Archivierung sehr gut geeignet

---

Überblick über das GOB-Format

• GOB ist ein neues Dateiformat, um OpenStreetMap-(OSM-)Daten kleiner und schneller zu handhaben
  • Halb so groß wie GOL und im Durchschnitt 30 % kleiner als PBF
  • Verwendet eine komprimierte, kachelbasierte Struktur für die Verarbeitung großer Datenmengen
• GOB ist Teil des GeoDesk Toolkit und wird als Open Source bereitgestellt
  • In Version GOL Tool 2.1 werden das Speichern (save) und Laden (load) von GOB unterstützt

Leistung und Effizienz

• GOB ist beim Import 5-mal schneller als bestehende Formate
  • Im Vergleich zur Zeit, die zum Erstellen von GOL aus PBF benötigt wird, ist die Dauer deutlich kürzer
  • Auf aktuellen Systemen wird der komplette Planetendatensatz in nur 3 Minuten geladen
  • Arbeitet auch mit weniger als 32 GB RAM effizient, sodass die Verarbeitung selbst auf älteren Laptops innerhalb einer Stunde möglich ist
• Beispielhafter Größenvergleich (PBF → GOB):
  • Planet: 65.4GB → 46.0GB (-29.7%)
  • Frankreich: 4.54GB → 2.84GB (-36.3%)
  • Japan: 2.13GB → 1.34GB (-37.0%)
• Je dichter die Daten, desto höher die Kompressionseffizienz; in Regionen mit geringerer Datendichte wie Brasilien oder China liegt die Reduktion bei etwa 23 %

Struktur und Einsatzweise

• GOB ist in Kacheln aufgebaut und orientiert sich an der Zoom-Struktur von Kartenkachel-Renderern (Zoom 6–12)
  • Der komplette Planetendatensatz besteht aus rund 60.000 Kacheln
  • Regionale Daten lassen sich mit Dateikopiergeschwindigkeit extrahieren und zusammenführen
• Dadurch werden regionale Archivierung, Verteilung und partielle Aktualisierung vereinfacht

Einschränkungen

• GOB enthält keine Metadaten (Bearbeitername, Zeitstempel usw.) und keine Änderungshistorie
  • Es ist nicht für die Bearbeitung, sondern für Verteilung und Archivierung optimiert
  • Um aktuelle Daten vorzuhalten, muss ein neuer GOB-Snapshot erzeugt werden

Verwendung

• GOB kann ab GOL Tool 2.1 verwendet werden
  • Mit dem Befehl gol save <gol-file> [<gob-file>] wird GOL in GOB umgewandelt
  • Mit dem Befehl gol load <gol-file> [<gob-file>] wird GOB in GOL geladen
• Mit der Option --area lassen sich per GeoJSON, WKT oder Koordinaten nur bestimmte Regionen exportieren oder laden
  • Beispiel: gol save world bodensee -a 9.55,47.4,8.78,47.66,9.01,47.88,9.85,47.58,9.82,47.46

Verfügbare Datensätze und weitere Pläne

• Open Planet Data verteilt täglich aktualisierte globale GOB-Dateien (unter 50 GB)
• Die Entwickler arbeiten an weiteren Verbesserungen:
  • Experimente mit anderen Kompressionsalgorithmen als zlib (zstd brachte keine nennenswerte Verbesserung)
  • Künftig soll gol load GOB direkt von einer URL laden können
  • Damit soll durch einen „Hintergrund-Build parallel zum Download“ ein praktisch sofortiger Import erreicht werden

[GN⁺]

Hacker-News-Kommentare

• Ich habe nach der Spezifikation des neuen GOB-Formats gesucht, weil ich neugierig war. Eine offizielle Spezifikation gibt es noch nicht, aber es gibt einen Thread, der auf Details eingeht
  Ein hochperformantes räumliches Datenformat mit Unterstützung für räumliche Indexierung, nicht nur auf OSM beschränkt, hat großen Einfluss auf Nutzbarkeit und Produktivität von Apps
  Wenn man zum Beispiel in QGIS große Datenmengen als KMZ (gezippte XML) speichert, hängt es mehrere Minuten, während dieselben Daten als flatgeobuf sofort geladen werden

  • Der Unterschied liegt vermutlich daran, dass KMZ nicht streamingfähig ist und daher komplett in den Speicher geladen und dann in die internen Strukturen von QGIS umgewandelt werden muss
    Ich habe auch die Erfahrung gemacht, dass sich komplexe KMZ/KML-Dateien in anderen GIS-Apps nicht gut laden ließen
    Mich würde interessieren, wie sich dieselben Daten als GeoJSON verhalten
  • In QGIS hatte ich den Eindruck, dass es leistungstechnisch deutlich besser ist, die Daten in Postgres zu speichern und von dort zu nutzen

• Ich frage mich, ob dieses Format das neue OSM-Datenmodell verwendet
  Dazu gibt es den Forschungsbericht zum Datenmodell, das GitHub-Repository und einen Blogbeitrag mit Bitte um Feedback im offiziellen Blog
  Im aktuellen Modell ist die Umwandlung von Koordinaten in Node-Referenzen langsam und verbraucht viel RAM, was mühsam ist

• Ich habe eine GIS-Frage. Ich suche nach einer guten Methode, um LIDAR-Punktwolken in Meshes umzuwandeln
  Bei nahezu vertikalen Bereichen wie Gebäudewänden sind die Daten spärlich, und es gibt auch keine Punktnormalen, sodass übliche Verfahren wie Poisson, Ball Pivot oder VCG in Meshlab degenerierte Ergebnisse liefern oder zu langsam sind
  Wegen Baumkronen und Dachvorsprüngen stößt auch ein einfacher Heightmap-Ansatz an Grenzen
  Ich möchte etwa 90 Milliarden Punkte auf 30 bis 50 Millionen Dreiecke reduzieren, möglichst ohne monatelang eine eigene Pipeline zu entwickeln

  • Das 3DBAG-Projekt könnte einen Versuch wert sein. Es ist ein Open-Source-Projekt, das 11 Millionen Gebäude in den Niederlanden aus LiDAR und Gebäudeumrissen rekonstruiert hat
    Das GitHub-Repository und die Rekonstruktions-Pipeline sind ebenfalls öffentlich verfügbar
  • Meshroom kann inzwischen LIDAR-Daten als Eingabe verarbeiten
    Ich habe es früher für Photogrammetrie und Camera-Tracking für VFX verwendet, und dafür war es ein sehr solides Open-Source-Toolset

• Ich denke, wenn libosmium und GDAL das Format nicht unterstützen, wird es wohl weiterhin ein Nischendasein führen

  • Das heißt aber nicht, dass es für sie einen Grund gäbe, es nicht zu unterstützen
    Es ist noch nicht einmal eine fertige Spezifikation, sondern erst im Ideenstadium, und so beginnt jedes neue Format

• Ich frage mich, ob das mit osmium kompatibel ist

  • Noch nicht. Das Format wurde gerade erst vorgestellt und hat noch nicht einmal eine offizielle Spezifikation