Vector Tiles - Ein Erfahrungsbericht

Wer träumt nicht gerne davon, die Geschwindigkeit zu steigern, die Effizienz zu erhöhen und dabei gleichzeitig die Qualität zu verbessern? Liest sich wie ein Versprechen aus einem Hochglanzkatalog. Ist es auch. Könnte aber im Bereich GIS, mit Hilfe von Vector Tiles tatsächlich möglich werden. Lesen Sie in unserem Artikel, wie wir es geschafft haben, die mehrere Tage dauernde Berechnung, sowie den Speicherplatz von 13 Millionen Bildkacheln einzusparen und dabei das Rendering in allen Masstäben zu optimieren.

Von Reto Zahner am 24.06.2021

Für die Umsetzung der interaktiven Karte der Bad RagARTz 2021, einer der renommiertesten Freiluftausstellungen weltweit, haben wir OpenLayers, GeoJSON, Vector Tiles, MBStyles und Maputnik genutzt.

Wir haben diese Technologien zur Erreichung der folgenden Ziele genutzt:

  • Die Karte soll swisstopo Daten verwenden.

  • Die Gestaltung der Karte soll einfach und mit frei verfügbaren Werkzeugen erfolgen.

  • Die Karte soll ausschliesslich mit OpenSource-Bibliotheken aufgebaut werden.

  • Das Caching und die Performance soll für die mobile Nutzung optimiert sein.

Mit den Vector Tiles haben wir eine Technologie gewählt, die noch nicht sehr verbreitet ist, aber sehr viel Potential in sich birgt und künftig bei der Erstellung von interaktiven Karten eine grosse Rolle spielen wird.

In diesem Artikel will ich darauf eingehen, was Vector Tiles sind und welchen Nutzen sie konkret bringen. Weiter möchte ich ein Fazit ziehen und mit euch unsere Einschätzung zum aktuellen Stand der Technik teilen.

Bevor wir aber in das Thema Vector Tiles einsteigen können, müssen wir zuerst verstehen, was Tiles sind und weshalb sie für Karten im Internet erforderlich sind.

Was sind Tiles und wozu braucht man sie?

Die Erzeugung eines Kartenbildes benötigt auf dem Kartenserver viel Rechenleistung und kann je nach Ebene und Komplexität mehrere Sekunden zur Berechnung benötigen. Das führt dazu, dass ein flüssiges Arbeiten mit einer solchen Karte nicht möglich ist. Deshalb versucht man Ebenen, die wenig nachgeführt werden, für alle Nutzer identisch sind und in sämtlichen Karten verwendet werden, bereits vor der Nutzung zu berechnen und zwischenzuspeichern.

Würde man die gesamte Karte als einzelnes Bild zwischenspeichern, würde nur schon für das GeoRi-Gebiet (

) ein Bild von mehreren GB entstehen. Dieses Bild müsste man für jede der 18 Zoomstufen einzeln bereitstellen. Weil der Download eines solchen Bildes mehrere Minuten oder gar Stunden dauern würde, würde dies die Internetanbindung in die Knie zwingen. Es liegt auf der Hand, dass ein effizienteres System gefunden werden muss.

Zur Lösung dieses Problems wird deshalb nicht nur ein einzelnes, grosses Bild erzeugt. Die Karte wird anstelle dessen für jede Zoomstufe in einen Raster mit kleineren Bildern aufgeteilt. Daraus ergeben sich dann Bilder mit einer Grösse von 256x256 Pixel. Diese Bilder werden Kacheln oder in Englisch “tiles” genannt. Es gibt verschiedene Systeme, wie das Raster gebildet und aus einer Koordinate auf die entsprechende Kachel geschlossen werden kann. Die am häufigsten verwendeten Systeme heissen XYZ und WMTS. XYZ ist gerade durch die grossen Anbieter, wie Google Maps, Bing Maps und Apple Maps sehr stark verbreitet. In professionellen GIS-Anwendungen mit unterschiedlichen Koordinatensystemen, wird meist auf WMTS, das durch die OGC (Open Geospatial Consortium), der Standardisierungs-Organisation für GIS-Daten, definiert wurde gesetzt.

Web Map Tile Service (WMTS) - Die Gegenwart

Diese Kachelbilder werden als PNG-Daten vor der Nutzung berechnet und abgespeichert. Für unser GeoRi-Gebiet (https://www.geori.ch/) sind das pro Ebene und Koordinatensystem 13'496'266 Kacheln. Die Berechnung dieser Kacheln dauert je nach Komplexität der Ebene teilweise mehrere Tage. Um den Plan für das Grundbuch auf dem Stand der täglichen Nachführung halten zu können, haben wir deshalb ein spezielles inkrementelles Verfahren entwickelt und müssen dadurch meist nur ca. 5000 Kacheln pro Tag neu berechnen.

Ist die Karte als ein Satz von Kachelbilder erzeugt worden, müssen nur noch die einzelnen Kacheln abgefragt, übermittelt und im Browser zu einem zusammenhängenden Bild zusammengesetzt werden. Wird der Kartenausschnitt verschoben, sind lediglich ein paar wenige Kacheln vom Kartenserver nachzuladen. Sind diese Bilder sogar im Browser-Cache auf dem PC des Betrachters zwischengespeichert, müssen sie nicht einmal mehr über das Internet übertragen werden. Dadurch wird der Kartenserver und das Netzwerk entlastet und die Darstellungsgeschwindigkeit massiv gesteigert.

Raster und Vektoren

Wie wir gesehen haben, braucht die Berechnung der Bilder auf dem Server viel Zeit und Rechnerleistung.

Diese Kachelbilder bestehen aus Pixel, den einzelnen Bildpunkten, die in einem Raster angeordnet sind. Deshalb wird bei einem Dateiformat wie JPEG, PNG, TIFF oder GIF von einem sogenannten Rasterbild gesprochen.

Um ein Rasterbild erzeugen zu erzeugen, müssen die Vektoren, also Punkte, Linien und Polygone, aus der Datenbank geladen und danach gemäss dem Darstellungsmodell bspw. als Gemeindegrenze, Strasse oder Gebäude “gezeichnet”, oder in Fachsprache “gerendert” werden. Bei diesem Prozess werden die Vektorpunkte den Bildpunkten zugeordnet und entsprechend dem Darstellungsmodell eingefärbt.

Diese konventionellen Raster-Kacheln haben ein jedoch paar nennenswerte Nachteile:

  • Die Rechenleistung zur Erzeugung des Bildes muss immer zentral auf dem Kartenserver aufgewendet werden. Heute besitzt jedoch jedes mobile Gerät eine Grafikkarte, die auf genau diese Aufgabe spezialisiert ist und die Umwandlung sehr effizient durchführt.

  • Werden die Daten mit unterschiedlichen Darstellungsmodellen ausgegeben, muss für jedes Modell ein eigener Satz an Zwischengespeicherten Bilder berechnet werden. Zur Erinnerung: Für zwei Darstellungsformen würden in der GeoRi-Region bereits 26 Millionen Kacheln berechnet werden.

  • Eine PNG-Datei ist zwar relativ klein, oft aber grösser als die entsprechende Vektor-Datei im Binärformat.

Mit Vector Tiles können diese Nachteile eliminiert werden.

Vector Tiles - Die Zukunft

Jetzt wo wir verstanden haben, welchen Nutzen Kacheln, also “Tiles”, bieten und wir den Unterschied zwischen Vektoren und Rastergrafiken kennen, können wir uns anschauen, was die Vector Tiles so interessant macht und wie sie funktionieren.

Wie funktionieren Vector Tiles?

Bei Vector Tiles werden nun nicht mehr die einzelnen Kacheln auf dem Server gerendert, sondern es werden die Vektoren der einzelnen Objekte für die jeweilige Kachel aus der Datenbank ausgelesen. Dabei werden die Geometrien so ausgeschnitten und aufbereitet, damit sie im Client wieder zu einer Einheit zusammengesetzt werden können.

Entsprechend der Zoomstufen wird ein sogenanntes Level of Detail (LOD) zugeordnet. D.h. je tiefer die Zoomstufe, desto weniger Details sind ersichtlich und die Geometrien müssen entsprechend stärker generalisiert werden. Bei der Generalisierung werden die Geometrien vereinfacht, was sie zwar technisch gesehen ungenauer macht, die Datenmenge aber stark reduziert. Die reduzierte Genauigkeit ist in diesem Fall auch kein Problem. Denn in einem Massstab von 1:32000 braucht es für eine Gemeindegrenze keine Auflösung mit einer Genauigkeit von 1cm. Das würde im Client, beim Rendering ohnehin nicht mehr dargestellt werden können. Die Darstellung eines einzelnen Bildpunktes wird durch ca. 10 Vektorpunkte beschrieben. Deshalb kann hier die Auflösung ohne weiteren Informationsverlust auf ungefähr 10 Meter gesetzt werden. Daraus ergibt sich, dass bei 96 DPI pro Bildpunkt ca. 1 Vektorpunkt zugeordnet werden kann. In diesem Fall wäre die zu übertragende Datenmenge 1000-mal kleiner und trotzdem ausreichend. Das heisst, das Level Of Detail beschreibt, wie viele Details in den Daten enthalten sind. Bei einer kleinen Zoomstufe bzw. einem kleinen Massstab sind weniger Daten ersichtlich und eine geringeres Level of Details ist erforderlich.

Eine weitere Herausforderung ist die Tatsache, dass sich einzelne Flächen und Linien über mehrere Kacheln erstrecken können. Dazu wurden verschiedene Verfahren entwickelt, um die Geometrien über Kacheln hinweg einem Feature effizient zuordnen und zusammensetzen zu können. Dabei wird meist mit Überlappungen gearbeitet. Passen einzelne Punkte aus verschiedenen Kacheln exakt zusammen und gehören sie zum selben Objekt, wird davon ausgegangen, dass sie zur selben Fläche oder Linie gehören. Die beiden Geometrien werden dann vor dem Rendering zu einer einzelnen Fläche oder Linie zusammengesetzt.

Wie oben bereits erwähnt, ist einer der grossen Vorteile von Vector Tiles, dass die Objekte erst unmittelbar vor der Darstellung auf dem Computer des Betrachters gerendert werden. Deshalb müssen die, für die Darstellung relevanten, Attribute auch an den Client übermittelt werden. Um auch in diesem Bereich die Datenmenge reduzieren zu können, wird versucht, möglichst viele doppelte Daten, in Fachsprache “Redundanzen” zu vermeiden. Um die daraus entstehende Komplexität zu reduzieren und die Daten auch mit den lokal im Browser zwischengespeicherten Kacheln korrekt darstellen zu können, wird ein Verfahren angewendet, das die Attribute, von auf mehreren Kacheln verteilten Objekten, zwar redundant in jeder Kachel mitliefert, doch innerhalb der Kachel trotzdem möglichst viele Redundanzen vermeidet. Als Ersteller einer Kartenlösung können wir zusätzliche Redundanzen vermeiden, indem wir in den Kacheln lediglich die, zur Darstellung erforderlichen Attribute, mitliefern und Attribute für die räumliche Analyse, über eine zusätzlich Abfrage via WFS (Web Feature Service), erst zum Zeitpunkt des effektiven Bedarfs nachladen.

Die oben genannten Schritte der Generalisierung und Attribuierung werden auf dem Kartenserver durchgeführt und können theoretisch bei der Anforderung einer Kachel ausgeführt werden. Bei Ebenen, die nicht sehr häufig geändert werden, versucht man aber die Datenbank nicht unnötig zu belasten und erzeugt, wie bei den Raster-Kacheln, die einzelnen Kacheln im Voraus. Ein weiterer Ansatz ist es, die Kacheln bei der ersten Anfrage zu erzeugen und danach für weitere Anfragen zwischenzuspeichern. Dieser Ansatz gut geeignet, um die Last auf die Datenbank generell etwas zu reduzieren und sich den Speicherplatz für Kacheln, die vielleicht nie oder sehr selten benötigt werden, zu sparen.

Die Übertragung an den Client erfolgt heute meist mittels des MVT-Formats. Das MVT-Format wurde von Mapbox, einem der weltweit führenden Unternehmen für WebGIS-Applikationen, entwickelt und basiert auf den Google Protocol Buffers oder kurz PBF. Das PBF Format beschreibt, wie die Daten plattformübergreifend binär kodiert werden und ist sehr effizient hinsichtlich des Speicherbedarfs und der Zugriffszeiten. PBF kann als binäres XML betrachtet werden. MVT definiert das Regelwerk, wie Geometrien und Attribute für jede Kachel in die PBF Datei geschrieben und an den Client ausgeliefert werden. Das Regelwerk ist in der sogenannten Proto Datei für MVT festgehalten.

Und jetzt das Ganze in schön - Styling mit Vector Tiles

Die Geometrien können je nach Anwendung für unterschiedlichen Darstellungsmodelle gerendert werden.

Wie das aussehen kann, zeigen diese drei Beispiele:

OSM Liberty

Klokantec Basic

Toner

Alle Beispiele verwenden dieselben MVT-Dateien und können einfach durch den Austausch der Stil-Definition, ohne neu zu laden, unterschiedlich dargestellt werden.

Die Stil-Definition ist die technische Beschreibung des Darstellungsmodells und definiert, aufgrund welcher Attribute und Zoomstufe, die Vektoren in welcher Form dargestellt werden müssen.

In unserem Beispiel verwendet die Stil-Definition das Mapbox Style (MBStyles) Format. In diesem Format wird festgelegt, wie die Features (Objekte bestehend aus Geometrie und Attribute) dargestellt und zu visuellen Ebenen gruppiert werden sollen.

Zur Veranschaulichung, basierend auf dem OSM Liberty Stil, ist hier eine sehr einfache MBStyles-Datei dargestellt:

example.mbstyle.json

Mit dieser Datei wird die folgende Karte erzeugt:

Maputnik der WYSIWYG-Editor für MBStyles

Die Definition der Stile direkt in der Datei wäre jedoch sehr unübersichtlich und ziemlich zeitraubend. Um das zu vereinfachen, gibt es grafische Stil-Editoren für das MBStyles-Format.

Mit Maputnik gibt es einen namhaften Open Source Editor für das Format.

Der Editor kann direkt Online verwendet werden: maputnik.github.io

Und die Zukunft? Wie geht es weiter?

Die Idee der Vector Tiles gibt es ursprünglich zwar bereits seit den 1960er Jahren. Erst im Jahr 2009 wurden die Grundlagen der heutigen Technik formuliert und kamen ab 2012 zum Einsatz. Ab dem Jahr 2016 wurde durch den Einsatz von Vector Tiles bei Google Maps, Mapbox und OpenStreetMap die Technik bekannter und in immer mehr Lösungen eingesetzt. Leider hat sich bis heute noch kein einheitlicher Standard durchgesetzt. Mit den Mapbox Vector Tiles (MVT) gibt es einen Defacto-Standard, der von ESRI, dem weltweit grössten Anbieter professioneller GIS-Lösungen, adaptiert wurde. Um die Verbreitung und Weiterentwicklung zu fördern, wurden die Spezifikationen als OpenSource freigegeben und genutzt.

Das OGC arbeitet bereits seit einiger Zeit an einem Standard für den Bezug von Vector Tiles, wie es bei Raster Tiles via WMTS möglich ist. Es gibt Ideen und Arbeiten zur Erweiterung der WMTS-Spezifikation oder den Web Feature Services (WFS) mit den entsprechenden Funktionen.

Immer mehr Anbieter bieten die Daten als Vector Tiles an. Swisstopo bspw. bietet die “Leichte Basiskarte” im MVT-Format an. Die OpenStreetMap Daten können inzwischen auch als MVT-Kacheln bezogen werden.

Gerade ausserhalb der klassischen GIS-Anwendungen, in der Navigation und für mobile Geräte, werden aufgrund der Performance und Flexibilität immer öfter Vector Tiles verwendet.

Insgesamt gesehen, handelt es sich bei Vector Tiles um eine noch junge Technologie, die immer mehr Verbreitung findet und viel Potential birgt.

Fazit - Unsere Erfahrung

Mit konventionellen Raster Tiles hätten wir einen speziellen Rendering-Prozess zur Erzeugung der Kacheln im Bad RagARTz 2021 Stil aufsetzen und damit die Kacheln berechnen lassen müssen. Mit MVT konnten wir bereits existierende Kacheln mit einer angepassten Stil-Definition verwenden.

Obwohl mit Maputnik ein gutes Werkzeug existiert, muss beim Einsatz zusammen mit OpenLayers, öfters im Quelltext nachgeforscht werden, um undokumentierte Verhaltensweisen nachvollziehen zu können und um herauszufinden, wie eine Funktion überhaupt genutzt werden kann. Gerade dieser Umstand hält (im Moment noch) die breite Masse ohne Programmierkenntisse davon ab, Vector Tiles für Ihre Plattformen einzusetzen.

Weiter erfordert die Nutzung von Vector Tiles das Erlernen von MBStyles, um die Darstellung zu steuern. Da im GIS-Umfeld seit Jahren zur Umsetzung der Darstellungsmodelle, SLD (Styled Layer Definition) verwendet wird, würde die Unterstützung dieser Beschreibungssprache die Nutzung von Vector Tiles fördern.

Abschliessend kann gesagt werden, dass die Nutzung von Vector Tiles noch etwas ungewohnt ist und deshalb wir die Umsetzung nicht ganz so effizient wie erwünscht durchführen konnten. Das Potential ist aber nach wie vor riesig und Vector Tiles werden deshalb in naher Zukunft ein wichtiger Bestandteil beim Aufbau von GIS-Applikationen sein.

Der Autor

Reto Zahner ist Informatik Techniker TS und Java Applikationsentwickler NDS. Seit dem Jahr 2000 arbeitete er als Web-Entwickler bei unterschiedlichen Firmen und Branchen. Seit dem Jahr 2018 arbeitet er für die beiden Firmen Kreis AG Sargans und FKL & Partner Grabs AG als Software-Entwickler im Bereich GIS.

https://www.linkedin.com/in/reto-zahner/