Neue Vektor-Tiles von OpenStreetMap

 (tech.marksblogg.com)
3 Punkte von GN⁺ 2024-11-20 | 2 Kommentare | Auf WhatsApp teilen
  • OpenStreetMap bietet seit Langem statische, PNG-basierte Raster-Tiles an, hostet nun aber auch Vektor-Tiles im Format Mapbox Vector Tiles (MVT), wodurch sich die Nutzungsmöglichkeiten von Karten erweitern
  • Vektor-Tiles ermöglichen es Nutzern, Stil- und Rendering-Regeln anzupassen, Informationen aus den Tiles zu extrahieren oder Funktionen wie Umschalten der Label-Sprache umzusetzen
  • Die Hauptwebsite von OSM nutzt weiterhin Raster-Tiles, die neuen Vektor-Tiles lassen sich aber direkt in einer separaten Web-Demo, in QGIS und in Leafmap ausprobieren
  • Ein z14-Tile in der Nähe des Burj Khalifa zeigt: 114 KB MVT wurden in 1,4 MB JSON umgewandelt; der POI-Layer enthält 474 Datensätze und mehrere Top-Level-Layer-Keys
  • Mit tiles2columns lassen sich OSM-Vektor-Tiles für eine angegebene Bounding Box herunterladen und in GeoPackage oder Parquet umwandeln, sodass aktualisierte OSM-Daten direkt für dateibasierte Analysen nutzbar werden

Wo sich OSM-Tiles verändern

  • OpenStreetMap hat Karten bislang über statische PNG-Raster-Tiles bereitgestellt, bei denen Rendering-Regeln und Stil vorab festgelegt waren
  • Das neue Hosting stellt Mapbox Vector Tiles bereit, also Vektor-Tiles im MVT-Format
  • Mit Vektor-Tiles können Endnutzer die Darstellung der Karte direkter steuern
    • Anpassung von Stil- und Rendering-Regeln
    • Extraktion der in jedem Tile enthaltenen Basisinformationen
    • Darstellung schärferer Kartenbilder
    • Möglichkeit zum Umschalten der Label-Sprache
  • Die Hauptwebsite von OSM stellt weiterhin Raster-Tiles bereit
  • Die neuen Vektor-Tiles lassen sich in einer Web-Demo auf den meisten Smartphones und Desktop-Geräten ansehen

Für die Praxis verwendete Tools

  • Die Beispiele visualisieren und analysieren OSM-Daten mit Python und mehreren Geospatial-Tools
  • Zu den grundlegenden installierten Tools gehören jq, python3-pip und python3-virtualenv
  • In der virtuellen Python-Umgebung werden folgende Pakete installiert
    • leafmap[maplibre]
    • mapbox_vector_tile
    • morecantile
    • notebook
  • DuckDB wird zusammen mit folgenden Erweiterungen verwendet
  • Für das Karten-Rendering wird QGIS 3.40 verwendet
    • QGIS ist eine Desktop-Anwendung für Windows, macOS und Linux
    • Weltweit wird die Anwendung ungefähr 15 Millionen Mal pro Monat gestartet

Vektor-Tiles in QGIS öffnen

  • In QGIS lassen sich OSM-Vektor-Tiles über Layer Menu -> Add Layer -> Add Vector Tile Layer hinzufügen
  • Für die neue Verbindung wird als Style-URL folgender Wert verwendet
  • Als Source-URL wird der folgende MVT-Endpunkt angegeben
  • Das Stylesheet ist optional; auch ohne Stylesheet kann QGIS die Vektordaten mit zufälligen Farben rendern
  • In QGIS wurde ein Problem mit fehlerhaftem Icon-Rendering festgestellt
    • Andere Mapping-Tools rendern die Sprites dieses Styles korrekt
    • In QGIS wirken die Icons wie unscharfe schwarze Icons
    • Das zugehörige Issue ist QGIS #59492

Rendering mit Leafmap und Jupyter Notebook

  • Es wird ein Konfigurationsordner für Jupyter Notebook erstellt, ein Passwort gesetzt und der Server auf 127.0.0.1 gestartet
  • Das Notebook läuft mit den Rechten des ausführenden Nutzers und kann das aktuelle Verzeichnis sowie darunterliegende Dateien offenlegen; daher wird es in einem leeren Ordner ausgeführt
  • In Leafmap wird leafmap.maplibregl verwendet und colorful.json als Style-URL angegeben, um die Umgebung des Burj Khalifa zu rendern
  • Beim Rendering mit Leafmap werden die POI-Icons korrekt angezeigt

MVT in analysierbare Daten umwandeln

  • Als Beispiel dient ein Tile der Zoomstufe 14 in der Nähe des Burj Khalifa
  • Die ungefähren Koordinaten [55.27, 25.2] werden an morecantile tiles 14 übergeben, um die Tile-Koordinaten [10707, 7006, 14] zu erhalten
  • Mit diesen Werten wird das folgende Tile heruntergeladen
  • Die 114-KB-MVT-Datei wird mit mapbox_vector_tile.decode und einer Funktion zur Koordinatentransformation in eine 1,4-MB-JSON-Datei umgewandelt
  • Die Top-Level-Keys des umgewandelten Tiles enthalten folgende Layer
    • addresses
    • bridges
    • buildings
    • ferries
    • land
    • ocean
    • pier_lines
    • pier_polygons
    • place_labels
    • pois
    • public_transport
    • sites
    • street_labels
    • street_polygons
    • streets
    • streets_labels_points
    • water_polygons
    • water_polygons_labels

POI-Layer mit DuckDB untersuchen

  • Der Layer pois wird als separate JSON-Datei extrahiert und anschließend mit ST_READ in DuckDB geöffnet und analysiert
  • POIs mit einem cuisine-Wert ergeben 67 Zeilen
    • Beispielwerte für amenity sind restaurant, fast_food und cafe
    • Beispielwerte für cuisine sind french, greek, american, lebanese, coffee_shop, asian, persian, chicken und pizza
  • Das Ergebnis von DuckDB SUMMARIZE zeigt, wie vollständig die POI-Daten befüllt sind
    • Insgesamt gibt es 474 POI-Datensätze
    • Die Null-Anteile von name, name_de und name_en liegen jeweils bei 29,96 %
    • Der Null-Anteil von amenity liegt bei 31,86 %
    • Der Null-Anteil von cuisine liegt bei 85,86 %
    • Der Null-Anteil von geom liegt bei 0,00 %
  • Nach approx_unique hat name 258 Werte, name_de 264 Werte, name_en 245 Werte, amenity 27 Werte und cuisine 39 Werte

Bounding Box mit tiles2columns extrahieren

  • Das bestehende osm_split war ein Tool, das von GeoFabrik erzeugte OSM-PBF-Dateien in benannte GeoPackage-Dateien umwandelte
  • GeoFabrik-PBF-Dateien können zu dem Zeitpunkt, an dem sie verarbeitet werden können, bereits Daten von vor einigen Tagen enthalten
  • Die neuen OSM-Vektor-Tiles werden aktualisiert, sobald die zugrunde liegenden Daten bearbeitet wurden
  • tiles2columns ist ein Python-basiertes Utility, das OSM-Tiles für eine angegebene Bounding Box herunterlädt und in GeoPackage- oder Parquet-Dateien umwandelt
  • Das Beispiel einer Bounding Box um den Norden Dubais lädt 42 Tiles herunter und erzeugt GeoPackage-Dateien im Umfang von einigen MB
    • streets.gpkg: 6,8 MB
    • buildings.gpkg: 6,2 MB
    • pois.gpkg: 1,4 MB
    • street_labels.gpkg: 1,4 MB
    • land.gpkg: 744 KB
  • Die erzeugten GeoPackage-Dateien lassen sich direkt in ein QGIS-Projekt einfügen
  • Die Dateien sind nach den in den OSM-MVT-Dateien verwendeten Keys aufgeteilt, sodass sich jeder Layer leicht separat identifizieren, stylen und analysieren lässt
  • Die Attribute jeder Geometrie werden in separaten Spalten gespeichert
  • Eine Beispielabfrage nach POIs mit Namen in pois.gpkg liefert 6.329 Zeilen zurück und enthält Namen wie Kiku, Fujiya Restaurant, Mövenpick Grand Al Bustan Dubai und McDonald's

Verwandte Beiträge

2 Kommentare

 
GN⁺ 2024-11-20
Hacker-News-Kommentare

  • Bei Vektorkacheln habe ich ein etwas zwiespältiges Gefühl. Ich habe noch keine Kombination aus Stil und Tile-Generator-Schema gefunden, die den Detailgrad zeigt, den die bisherigen Rasterkacheln liefern.
    Schon an den Screenshots im Artikel sieht man den Unterschied deutlich. Der erste enthält viele Informationen: Points of Interest wie Statuen, Geschäfte, Theater und Aussichtspunkte, Straßen, die als Brücken markiert sind, unterschiedliche Farben für Rasenflächen und Parks, unterschiedliche Linienstärken je nach Straße, Sportplätze, Gebäude- und Stadtteilnamen, Einbahnstraßenpfeile, Gebäudeteile, Treppen, Bäume und mehr.
    Der zweite zeigt im Wesentlichen nur eine Trolley-Haltestelle und einen Straßennamen, und selbst dieser Straßenname wird falsch gerendert.
    Ich habe viel mit OpenMapTiles-Stilen, dem Standardstil von Protomaps, Mapbox-Stilen sowie den Generatoren von Protomaps, OpenMapTiles und Mapbox gearbeitet, aber nichts war so gut lesbar und gleichzeitig so detailreich wie die OSM-Rasterkacheln.
    Vektorstile bieten flüssiges Zoomen und Verschieben und lassen sich leicht anpassen, aber wenn man nicht nur eine Hintergrundkarte für eigene Daten braucht, sondern die tatsächlichen Kartendaten sehen will, reichen sie nicht aus.
    Vielleicht liegt es auch an Grenzen bei den Rechenressourcen. Um den Detailgrad der OSM-Rasterkacheln darzustellen, könnte es sowohl auf Client-Seite als auch bei der Kachelgenerierung zu ressourcenintensiv werden.
    Ich würde mir wünschen, dass OpenStreetMap eher versucht, den bestehenden Rasterstil genauer nachzubilden, statt noch eine kontrastarme, detailarme Hintergrundkarte anzubieten, und hoffe, dass diese öffentliche Veröffentlichung von Vektorkacheln detailliertere Vektorkarten ermöglicht.

    • Im Grunde stimmt das, aber man kann es auch aus einer etwas anderen Perspektive sehen. Für diejenigen, die Karten bereitstellen, liegt der wichtigste Vorteil von Vektorkacheln nicht in kleineren Vorzügen wie Schärfe oder flexiblerem Styling, sondern darin, dass der nötige Rechenaufwand stark sinkt.
      Eine moderne Infrastruktur zur Erzeugung von Rasterkacheln zu betreiben, ist eine ziemlich große Aufgabe.
      Früher habe ich lange an einem sehr detaillierten Stil für die Planung von Radreisen gearbeitet: https://stevebennett.me/2015/01/14/cycletour-org-a-better-ma...
      Ich habe mehrmals versucht, ihn mit Vektorkacheln nachzubilden, aber es war ziemlich schwierig, genügend Details unterzubringen, ohne an Größenlimits zu stoßen, und die Standard-Mapbox-Kacheln enthielten viel zu wenig der nötigen Informationen.
      Allerdings bieten Vektorkacheln auch Ausweichmöglichkeiten, die Rasterkacheln nicht haben. Zum Beispiel kann man unterschiedliche Layer ein- und ausschalten, während Labels trotzdem erkennen können, was darunter liegt, und so die Lesbarkeit erhalten bleibt.
    • Bisher scheint der Fokus eher auf Software gelegen zu haben, die kontinuierlich aktualisierte Vektorkacheln erzeugt, als darauf, die Stile, die diese Kacheln nutzen, reichhaltiger zu machen.
    • Ich habe einen Fork von OpenRailwayMap erstellt. Das Original ist unter https://www.openrailwaymap.org zu finden, der Vektorstil unter https://openrailwaymap.fly.dev.
      Der Stil ist optisch eng an die ursprünglichen Rasterkacheln angelehnt, aber in der Vektorversion habe ich deutlich mehr Interaktivität hinzugefügt.
      Aus Sicht von Stil- und Kacheldesign ist interessant, dass sich die Performance-Trade-offs völlig unterscheiden, je nachdem, wo und wie die Kacheln gerendert werden. Das ist natürlich naheliegend, wirkt sich aber auch darauf aus, was visuell auf Server und Client möglich ist.
    • Ich stimme voll zu. Für die Navigation nutze ich eine Mischung aus OpenStreetMap und Google Maps; eigentlich würde ich gern nur OSM verwenden, aber die Zahl der eingetragenen Orte ist nicht so groß wie bei Google Maps.
      Trotzdem ist die OSM-Karte viel angenehmer zu benutzen, weil so viele Points of Interest angezeigt werden. Schon beim Anschauen der Karte bekommt man ein Gefühl für den realen Ort; ein Park sieht wie ein Park aus, ein Krankenhaus wie ein Krankenhaus.
      Google Maps mag aus Sicht eines Grafikdesigners besser aussehen. Aber zur Orientierung muss man meist die Formen von Straßen und Kreuzungen abgleichen. In Google Maps sieht alles ziemlich ähnlich aus.
    • Ich sehe das ganz genauso. Der Standardstil von openstreetmap.org kommt für mich persönlich fast reinem Glück gleich, und ich habe ziemlich lange versucht, Vektorkarten auf dieses Niveau zu bringen, aber nichts Brauchbares gefunden.
      Schon nach zwei Minuten Herumprobieren sieht man den Detailverlust sofort. Wirklich schade, aber ich bin optimistisch, dass das irgendwann jemand lösen wird.

  • Es war interessant zu beobachten, wie die Open-Source-Community Vektorkartenkacheln entwickelt hat. Als ich um 2018 an Web-GIS arbeitete, wirkten die Streaming-Vektorkarten von Google/Apple wie Magie, und wenn die Kosten tragbar gewesen wären, hätte ich sie unbedingt nutzen wollen.
    Nicht lange danach wurde die Kerntechnik als Open Source verfügbar, und sogar kostenlose Hosting-Lösungen entstanden. Heute kann man in Leaflet-Karten hervorragende Vektor-Layer kostenlos verwenden. Danke, Open Source.

    • Es ist etwas überraschend, dass OSM so lange gebraucht hat, um hier anzukommen. Die grundlegenden technischen Bausteine gab es schon vor mehr als zehn Jahren.
      Ich will mich nicht über einen kostenlosen Kartendienst beschweren; der Dienst ist großartig, und ich verstehe auch, dass der Fokus stärker auf Bearbeitung und Dateneigentum liegt. Bereitstellungsinfrastruktur ist schwierig und teuer.
      Ich frage mich nur, wie sehr die Dominanz von Mapbox über die Jahre andere Ansätze ausgebremst hat.

  • Ich frage mich, ob beim Hosting von OSM-basierten Karten die Betriebskosten sinken. Schließlich dürfte man weniger CPU fürs Rendering brauchen, und Vektoren sollten auch weniger Speicherplatz und Bandbreite verbrauchen.

    • Ja und nein.
      Nein, weil der offizielle OSM-Tile-Layer stark von Fastly gesponsert wird. Beim letzten Stand waren es 720.000 € von Fastly, während das AWS-Rendering 40.000 € kostete.
      Ja, weil technisch weniger Ressourcen verbraucht werden, was auch AWS+Fastly entlastet und Self-Hosting einfacher macht.
      In einer früheren, ausführlich gelesenen Risikobewertung stand, OSM würde „bei Verlust des Fastly-Sponsorings wahrscheinlich den gesamten Drittanbieterzugriff auf den Standard-Tile-Layer kappen und nur noch eine kleine Zahl von Varnish-Servern betreiben“.
      Nach meinem Verständnis lag die Hauptmotivation für Vektoren weniger in Kostensenkungen, sondern eher in besserer Internationalisierung, darin, Rendering-Entscheidungen clientseitig treffen zu können, und im Aufbau eines modernen Toolings, aus dem sich viele Folge-vorteile ergeben.
      Es dürfte aktuellere Informationen geben; relevante Unterlagen stehen unter 1 und 2.
      1. https://operations.osmfoundation.org/2024/01/25/owg_budget.o...
      2. https://osmfoundation.org/wiki/Finances
    • Man kann auch sagen: nein. Vektortiles lassen sich schon seit langer Zeit mit sehr wenig Aufwand selbst hosten oder von jemand anderem hosten lassen.
      Allerdings stimmt es insofern, als man einen Teil der Verarbeitung auf den Client verlagern kann und, wichtiger noch, viele Style-Entscheidungen vom Client treffen lassen kann. Natürlich nicht alle.
      Statische oder selten aktualisierte Vektortiles lassen sich mit verschiedenen Tools aus OSM-Daten erzeugen; die derzeit beliebtesten sind https://github.com/systemed/tilemaker und https://github.com/onthegomap/planetiler.
      Das eigentlich Neue ist, dass Vektortiles dank der Arbeit, die Paul für die OSMF gemacht hat, sofort aktualisiert werden können, also innerhalb weniger Minuten. Das ist als Feedback-Mechanismus für OSM-Beitragende wichtig und auch der Hauptgrund, warum die OSMF derzeit den Rastertile-Dienst betreibt.
      Derzeit ist noch offen, welche Einschränkungen für die Nutzung des Vektortile-Dienstes gelten werden. Wie beim Rastertile-Dienst ist nicht beabsichtigt, mit Drittanbieterdiensten zu konkurrieren oder sie zu ersetzen, aber der Vektortile-Dienst könnte das potenziell tun.
    • Ja, Vektortiles sind deutlich einfacher selbst zu hosten.
      Beispiele sind https://protomaps.com/, https://openmaptiles.org/, https://versatiles.org/.
    • Ich bin der Macher von openfreemap.org. Stimmt. Bei Vektortiles hostet man im Grunde statische Dateien, und der Server hat außer HTTPS-Verschlüsselung nichts zu tun.
      Auch die gzip-Komprimierung ist bereits innerhalb der Tiles erledigt.

  • Ein weiteres Problem ist, dass arabische Schriftarten in der Vektorversion nicht korrekt gerendert werden. Sie werden von links nach rechts statt von rechts nach links gerendert, und die Buchstaben erscheinen getrennt statt verbunden.

    • Der Kern von Vektortiles ist, dass das Rendering lokal erfolgt und, abgesehen vom Tile-Schema, über veränderbare Style-Einstellungen gesteuert wird.
      Daher liegt der sichtbare Fehler am Style oder an der Bibliothek, die die Inhalte lokal rendert.
    • Ich weiß nicht, wie der QGIS-Vektortile-Renderer funktioniert, aber bei der GitHub-Demoseite dürfte es einfach sein, MapLibre ein RTL-Text-Plugin hinzuzufügen, damit von rechts nach links geschriebener Text korrekt verarbeitet wird: https://maplibre.org/maplibre-gl-js/docs/examples/mapbox-gl-...

  • Ebenfalls sehenswert: OpenFreeMap — kostenloses Hosting von OpenStreetMap-Vektortiles
    https://openfreemap.org/

    • OpenFreeMap bietet Folgendes nicht an: Suche oder Geocoding, Routenberechnung·Navigation·Wegbeschreibungen, Erzeugung statischer Bilder, Hosting von Rastertiles, Hosting von Satellitenbildern, Höhenabfragen, Hosting eigener Tiles oder Datensätze.
      https://github.com/hyperknot/openfreemap?tab=readme-ov-file#...
    • Wow, das wirkt sehr ausgereift.
      Ich frage mich, ob es ebenfalls auf demselben Vektor-Technologiestack basiert oder ob es eine komplett separate Entwicklung ist.

  • Der Teil, dass „die Bilder viel schärfer werden und auch ein Wechsel der Label-Sprache möglich sein wird“, dürfte weniger gut funktionieren als erhofft.
    Wenn man die Sprache ändert, gibt es keinerlei Garantie, dass die Label-Größe gleich bleibt, und die Label-Größe interagiert mit dem Kartenlayout und beeinflusst auch, was angezeigt wird.
    Werden Labels größer, können sie zu viel von der Karte verdecken oder sich gegenseitig überlappen. Werden Labels kleiner, könnten Nutzer sich fragen, warum eine Stadt, die zuvor aus Platzgründen weggelassen wurde, nicht im neu entstandenen freien Raum erscheint.

    • Ich hasse es wirklich, dass in Google Maps beim Hinein- und Herauszoomen Städtenamen und Straßennamen verschwinden. Manche Straßen- oder Geschäftsnamen sind nur auf einer bestimmten Zoomstufe sichtbar und verschwinden, wenn man weiter hinein- oder herauszoomt.
      Zeigt einfach alle Straßennamen an. Wenn es dicht wird, ist mir das egal. An einer Kreuzung zu stehen und auf eine Karte ohne Namen zu schauen, ist eine nutzlose Karte.
    • Ausgangspunkt ist ohnehin automatische Label-Platzierung.
      Das war auch bei den seit Jahren genutzten Rastertiles so.
    • Gibt es einen Grund anzunehmen, dass sich der Platzierungsalgorithmus stark ändern wird?

  • Eine sehr erfreuliche Neuerung. Ich freue mich auf besser aussehende Karten.
    Allerdings wundert mich der Abschnitt „my workstation“ etwas. Er scheint nicht viel mit dem Rest des Artikels zu tun zu haben, und die danach behandelte Arbeit scheint auch keine hohen Systemanforderungen zu stellen.

  • Wenn „die Bilder deutlich schärfer werden und auch das Umschalten der Label-Sprache möglich wird“, heißt das dann zum Beispiel, dass Stadtform-Vektoren – genauer gesagt Polygone – die Metadaten der Städtenamen in allen definierten Sprachen mit sich führen?

    • Große Städte enthalten bereits Namen in mehreren Sprachen. Siehe zum Beispiel Paris: https://www.openstreetmap.org/relation/71525
      Wie nützlich das Umschalten der Sprache ist, hängt natürlich davon ab, ob Übersetzungen vorhanden sind. Es könnte auch Editoren dazu motivieren, mehr Übersetzungen von Ortsnamen hinzuzufügen.
    • Das derzeit für Tests verwendete Tile-Schema shortbread unterstützt zwar keine mehreren Sprachen, aber soweit ich weiß, wollen die daran Arbeitenden das unterstützen, sobald die Bugs bereinigt sind.
      Ein Beispiel dafür, wie so etwas aussieht, sieht man unter https://americanamap.org. Es nutzt OSM-Daten, zielt aber im Gegensatz zu den Tiles in diesem Beitrag nicht auf nahezu Echtzeit ab.
    • Nein, aber man kann Tiles abrufen, die nur den benötigten Text enthalten, und damit die bereits vorhandenen Tiles patchen.

  • Es wäre schön, wenn das bedeuten würde, dass OSMAnd und OrganicMaps endlich ihre Kräfte bündeln und die ultimative freie Open-Source-Karten-App herausbringen.

    • Beide Apps verwenden hauptsächlich herunterladbare Offline-Kartendaten, die in eigenen Formaten vorverarbeitet sind.
      Vektor-Tiles im MVT-Format sind für Navigation oder Suche überhaupt nicht geeignet. Das heißt nicht, dass man es nicht irgendwie zusammenfrickeln könnte, aber es wäre ziemlich erzwungen.
    • Die eine ultimative Karten-App kann es nicht geben, weil die Anwendungsfälle unterschiedlich sind.
      OSMAnd hat zum Beispiel viele Power-User-Funktionen, die für Menschen, die zu OSM beitragen, sehr nützlich sind, in einer App für normale Nutzer aber nur die Oberfläche überladen könnten.
    • Es wäre schon gut, wenn die beiden zumindest Kartentiles teilen könnten, damit nicht Gigabytes an Speicherplatz durch dieselben Karten doppelt belegt werden.

  • https://marble.kde.org/ hatte schon vor neun Jahren eine eigene Implementierung für einen gestreamten Vektor-OSM-Layer, und ich habe ziemlich lange darauf gewartet, dass Ähnliches auch in anderen OSM-Karten-Apps auftaucht.
    Bei Android-OSM-Apps war es immer ein Speicherproblem, Karten in großen Brocken für ganze Länder mit Hunderten von Megabytes herunterzuladen. Ich freue mich sehr, dass sich endlich ein Standard herausbildet, und hoffe, dass er von vielen Apps übernommen und weiter verfeinert wird. Großartige Arbeit.

    • Ich habe nach der Marble-App für Android gesucht, aber sie ist weder im Play Store noch bei F-Droid zu finden. Der Play-Store-Link auf der Website führt zu 404. Wurde sie aufgegeben?