We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Vektortile-Erfahrungen mit Shortbread

00:00

Formale Metadaten

Titel
Vektortile-Erfahrungen mit Shortbread
Serientitel
Anzahl der Teile
107
Autor
Lizenz
CC-Namensnennung 4.0 International:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Das neue Vektortile-Schema Shortbread wird in der Geofabrik zum Rendern mehrere Kartenstile eingesetzt. Die Vektortiles werden mit Tilemaker erzeugt und anschließend mit Mapnik als Rastertiles gerendert. Mapnik selbst greift mit dem GDAL-MVT-Treiber auf die Vektortiles zu. Das Rendering erfolgt mit Tirex. Der Vortrag berichtet über die Hürden, die genommen wurden und die Besonderheiten von GDAL, die zu gewissen Anforderungen an die Inhalte der Vektortiles führen. Unter dem Namen Shortbread gibt es seit dem Jahr 2022 ein weiteres Vektortileschema unter einer freien Lizenz. Dieses wird in der Geofabrik zum Rendern mehrere Kartenstile eingesetzt und ist unter der CC-0-Lizenz (Schema) bzw. FTWPL (Code) verfügbar. Die Vektortiles werden mit Tilemaker erzeugt und anschließend mit Mapnik als Rastertiles gerendert. Mapnik selbst greift mit dem GDAL-MVT-Treiber auf die Vektortiles zu. Das Rendering erfolgt mit Tirex, der Renderd-Alternative. Der Vortrag ist ein Erfahrungsbericht über die Implementierung eines Vektortileschemas mit Tilemaker, welches anschließend von GDAL, Mapnik und Tirex verwendet wird. Weil beispielsweise Mapnik nicht in der Lage ist, die Features eines Layers selbst zu sortieren, muss dies schon bei der Vektortile-Erzeugung erfolgen. GDAL erwartet in jedem Layer ein Attribut, selbst wenn der Layer nur Meeresflächen enthält. Für jede Zoomstufe ist ein eigener Kartenstil nötig, was seinerseits zu Anpassungen an Tirex geführt hat. Auch die Performanceunterschiede zwischen einem Vektortile-basierten Rastertileserver und einem klassischen Rastertileserver werden beleuchtet.
Schlagwörter
Stochastische ErzeugungDatenbankFokalpunktVariableSoftwareentwicklungFestplatteVirtuelle AdresseDatenbankMAPSoftwareVektorVECTOR <Programm>Bitmap-GraphikTeilmengeGeometrieChipkarteARM <Computerarchitektur>CASHEDeforestation <Informatik>Abteilung <Mathematik>ElementargeometrieDistributionenraumWort <Informatik>ALT <Programm>SchnittmengeComputeranimation
DatenbankDatenbankComputeranimation
DatenbankBASICVersion <Informatik>DateisystemZoomMaximumMinimumDateiXMLRAMLaufzeitServerAMD <Marke>IntelServerDateisystemHardwareReiheConstraint <Künstliche Intelligenz>DownloadingTreiber <Programm>UpdateTemplateXMLMAPLaufzeitEigenwertproblemVersion <Informatik>Brücke <Graphentheorie>Gebiet <Mathematik>ChipkarteVECTOR <Programm>DateiElementargeometrieRandVektorDatenerhebungEinfacher RingNoten <Programm>FlächentheorieKerndarstellungRAMTrägerPlug inTexteditorStruktur <Mathematik>Multi-Tier-ArchitekturZeitzoneZahlSlay <Computerspiel>Computeranimation
RAMAMD <Marke>IntelLaufzeitServerDateiVektorVersion <Informatik>DownloadingSoftwareDienst <Informatik>InformationQUICK <Programm>InternetdienstImplementierungWeb SiteQuellcodeVektorBLENDDatenbankFestplatteRALLY <Programm>FünfServerIndexRAMCachingGebiet <Mathematik>ScheibeInhalt <Mathematik>TabelleChipkarteMAPTangente <Mathematik>GRABE <Programmiersprache>Ebene KurveCASHESchnittmengeLaufzeitUnlösbarkeitTeilmengeVersion <Informatik>PartitionsfunktionQuellcodeHaar-MaßDateiProgrammfehlerKerndarstellungKonfigurationsraumRechnenComputeranimation
Transkript: Deutsch(automatisch erzeugt)
Hallo allerseits, willkommen zum zweiten Vortrag unserer Session, wo es um OpenStreetMap und mit dem Fokus auf Softwareentwicklung geht. Dieser Vortrag handelt auch von OpenStreetMap,
obwohl es in der Beschreibung erst gar nicht das Wort explizit vorkommt, aber die Leute, die sich auskennen in dem Thema, wissen es natürlich. Michael Reichert ist auch kein Unbekannter im OSM-Umfeld. Wir sind jetzt auf jeden Fall gespannt, was sich jetzt hinter Shortbread verbirgt und sind gespannt, was du uns darüber erzählen hast.
Vielen Dank für die einleitenden Wörter, Jakob. In meinem Vortrag Vektor-Teilerfahrungen mit Shortbread geht es natürlich nur um OSM-Daten. Zuerst zur Motivation, dann möchte ich das Shortbread-Schema vorstellen, wie wir in der Geofabrik, wo ich arbeite, die Vektor-Teils mit Teilmäger erzeugen, Erfahrungen beim Umgang mit dem Raster-Teil-Rendering mit MEPNIC,
wenn man als Datenquelle Vektor-Teils verwendet und zum Schluss einen Ausblick für das Shortbread-Projekt selbst. Zur Motivation, klassisches Raster-Teil-Rendering heißt, man hat einen Kartenstil und hat einen Teil-Cache. Das heißt, wenn man fünf Kartenstile anbieten möchte, braucht man fünf Teil-Caches, irgendwann sind die Festplatten voll.
Das skaliert nicht besonders gut. Vektor-Teils, man kann mit beliebig vielen Kartenstilen arbeiten, aber nur einem Teil-Cache, weil man eben Vektor-Geometrien cashed auf dem Teilserver und keine Raster-Grafiken. In der Geofabrik haben wir seit 2016, 2017 tatsächlich schon Vektor-Teils im Einsatz
für einzelne Raster-Teil-Kartenstile, die eher schwach nachgefragt sind. Bislang haben wir ein Vektor-Teilschema verwendet, das auf den Layern von OSM Cardo vom Stand etwa 2016 basiert. Das sind sehr große Vektor-Teils, also das einzelne Vektor-Teil
ist in seiner Datenmenge sehr groß. Die Produktion ist sehr langsam. Da braucht die Teil-Erstellung für den gesamten Planet einen Monat, was auch daran liegt, dass eine Datenbank daran noch beteiligt ist. Und für die Details dazu verweise ich auf den Vortrag meines damaligen Kollegen Rory Macken auf das Date of the Map 2016. Dieses Setup ist aber nicht zukunftsfähig,
weil es eben schwer und langsam ist. Und die Software hätte eigentlich auch mal wieder aktualisiert werden müssen, damit sie auf aktuellen Ubuntu-Distributionen noch läuft. Wir wollten deshalb in der Geofabrik ein neues Vektor-Teilschema haben und haben uns angeschaut, was es gibt. Wir wollten keine Namenssendung für das Schema von unseren Kunden verlangen,
sondern nur die Namenssendung für die OSM-Daten. Sonst hat man irgendwann unten rechts in der Karte eigentlich nur noch Text stehen und kein Kartenbild mehr, weil man lauter auch Quellenangaben machen muss. Das Rasterteil-Rendering sollte weiterhin mit MAPNIC erfolgen. Da haben wir angeschaut, das Mapbox-Vektor-Teilschema ist direkt rausgeflogen,
das ist proprietär. Da haben schon die Open-Map-Teils-Leute vor Jahren Ärger mit Mapbox gehabt, deswegen, als sie das nachgebaut haben. Das Open-Map-Teilschema selbst ist zwar unter einer freien Lizenz, aber das ist die CC-BY-Lizenz. Das heißt, da ist eine Namenssendung erforderlich und es benötigt eine Datenbank. Und die Erstellung der Vektor-Teils ist so kompliziert,
dass direkt docker angepriesen wird. Das ist uns zu kompliziert, das soll einfacher sein. Das Ziel ist also einfach, schnell und schlank und keine Datenbank. Die Schema-Lizenz ohne Namenssendung und ohne Share-Alike natürlich.
Und deshalb sind extra Features auch in ergänzendem Schema tazufinden und nicht im Shortbread-Schema selbst. Shortbread übrigens ist ein schottisches Gebäck, das man zu T reicht. Das ist ein Nurbteilgebäck. Der Shortbread-Schema selbst hat als Layer Boundary Labels,
also Punkte zur Beschriftung von Verwaltungsgrenzen, aber nur die Admin-Stufen 2 bis 4, also Nationalstaaten bis Bundesstaaten, Straßenflächen, Beschriftungspunkte, Adresspunkte, POIs, Beschriftungspunkte für Wasserflächen
und für sogenannte Place-Notes, also besiedelte Orte. Grenzen zwischen Verwaltungsgebieten sind bei uns im Vektortal-Schema als Linien vorhanden. Es werden auch unterstrittene Grenzen unterstützt, da ist dann ein extra Attribut gesetzt. Natürlich ein Streets-Layer für Straßengeometrien,
ein Linien-Layer für Straßennamen und für Seilbahnen, Brücken als Flächen, Straßenflächen, Gebäude, Wasserflächen, Landflächen und auch Sondernutzungsflächen, also wie jetzt zum Beispiel Schulen oder Universitäten.
Und dazu noch Dämme und Piers als Linien und als Flächen, weil die in Open-Street-Mapte als linienförmig, als flächenförmig erfasst sind. Damit muss sich dann leider der Kartenstil-Auto herumschlagen mit diesen Eigenheiten. Das wollten wir und konnten wir nichts auf die Schnelle eliminieren. So, wo kommen die Daten für Shortbread her? Die Hauptdatenquelle ist der Planetdump oder ein regionaler OSM PBFX-Trakt.
Außerdem nutzt der Teilmaker, den wir einsetzen, auch noch drei Shapefiles. Das sind zwei Shapefiles von OSM Data Open-Street-Map.de, das von Jochen Topf betrieben wird. Und zwar vereinfachte Meeresflächen und die Meeresflächen selbst
für verschiedene Zoom-Stufen, für die Niedrigen, die vereinfachten. Und die Beschriftungspunkte für die Verwaltungsgebiete erzeugen wir nicht direkt aus dem Planetdump heraus, sondern mit einer Postges-Datenbank, die mit OSM und der PKS-Qual importiert wurde. Der Grund ist nämlich, dass der Teilmaker für Beschriftungspunkte nur Zentroide machen kann.
Das ist aber bei Staatsgebieten problematisch, weil das Zentroid von Norwegen liegt, glaube ich, nicht in Norwegen. Das sehen wir auch nachher noch auf einem der Beispiel-Renderings, dass es noch andere Verwaltungsgebiete gibt, deren Mitte außerhalb des Gebietes liegt. Es gibt derzeit einen Kartenstil für MAPNIC mit Carto CSS für diese Vektortals.
Das ist der sogenannte Short-Prep-MAPNIC-Stil, der ist auch schon auf GitHub unter freier Lizenz. Ihr seht hier zwar einige Beispiel-Renderings. Das ist halt so eine Standard-Basis-Karte, bisschen weniger farbenfroh wie OSM-Carto, aber nicht absolut blass.
Denn diesen Kartenstil findet ihr auch jetzt schon zum Anschauen auf map.geofabrik.de, wo er produktiv in Betrieb ist. Er enthält keine Points of Interest. Das haben wir dort weggelassen. Rastatize mit MAPNIC. Man lernt sehr viel, wenn man sich damit beschäftigt. Und ich glaube, ich bin auch in Bereiche vorgedrungen, die noch nicht so wirklich erforscht sind, sage ich jetzt mal.
Ich glaube, ich sollte mir jetzt mal ein Stack-Overflow-Account anlegen, zum Antworten schreiben. Vector-Tiles direkt als Datenquelle geht nur, wenn man die Node-JS-Bindings von MAPNIC verwendet. Diese sind, glaube ich, im Auftrag von Mapbox mal entwickelt worden, als Mapbox noch MAPNIC eingesetzt hat.
Das ist jetzt auch schon fast zehn Jahre her. Es gibt ein GDAL-Input-Plugin für MAPNIC, das wir deswegen verwendet haben. Das ist ab Vers. 2.3 enthalten. Aber da gibt es eine ganze Reihe von Einschränkungen. Und zwar, man kann bei GDAL ein Treiberpräfix vor dem Pfad angeben, damit man nicht erst noch automatisch den Treiber ermitteln muss.
Das wird mit MAPNIC nicht unterstützt, weil MAPNIC dieses Präfix nicht abtrennt. Das heißt, dann heißt es find not found. Die metadata.json-Datei, die zu den Vector-Tiles gehört und die Vector-Tiles selbst, müssen lokal im Dateisystem vorhanden sein. Ein automatisch Download bei HTTP geht nicht.
Und die sogenannten OpenOptions von GDAL werden auch von MAPNIC nicht unterstützt. Das heißt, man kann die Vector-Tiles nicht aus einer MB-Tiles-Datei laden, sondern sie müssen als zxy.pbf im Dateisystem vorliegen.
Und der Pfad muss auf das Verzeichnis der jeweiligen Zoom-Stufe zeigen. Und das hat zur Konsequenz, dass wir einen Kartenstil pro Zoom-Stufe brauchen und nicht einen für alle Zoom-Stufen. Das heißt, in dem MAPNIC XML hier mal beispielhaft ein kleiner Auszug muss extra drinstehen, ja, das ist jetzt hier der Layer für Zoom-Stufe 12.
Das heißt, wir haben dann jeweils einen Kartenstil pro Zoom-Stufe 0 bis 13 und einen für 14 und größer, weil ab der Zoom-Stufe 14 haben wir nur noch einen Satz Vector-Tiles.
Wir haben deswegen auch den T-Rex erweitert, der bei uns im Teil-Rendering-Stack verwendet wird, sodass er seit Version 0.8 mehr als eine Kartenstil-Datei für einen Kartenstil, den er ausliefert, unterstützt. Also bislang gab es nur die Map-File-Option in der Konfigurations-Datei und jetzt gibt es noch
Map-File.zahl und das ist eben die Zoom-Stufe, für die ein anderer Kartenstil verwendet werden soll. Das Styling mit Cosmetic ist nicht möglich. Da bin ich dran gescheitert. Das heißt, die Kartenstile
habe ich schlicht und einfach im Text-Editor geschrieben und dann mit NIC 4 Beispielbilder gerendert. Ist zwar nicht so komfortabel, aber es geht auch. Wegen der Anforderung, dass wir einen Kartenstil pro Zoom-Stufe brauchen, kann man eben
nicht mit diesen typischen Repository-Strukturen arbeiten, die bei den Karten-CSS-Stilen üblich sind. Sondern man nimmt wie gehabt eine MML-Datei mit den Layer-Definitionen, wobei man dort eben nicht den Pfad zu den Vector-Tiles oder zur Datenquelle angibt. Und man hat die mehrere MSS-Dateien. Dafür braucht es jetzt noch zusätzlich ein Python
-Script, das haben wir jetzt auch auf GitHub, das die MML-Datei als Template begreift und dort eben dann aus dieser MML-Datei mehrere MML-Dateien erzeugt, eine Prozums-Stufe, die dann nachher mit Karten in XML umgewandelt werden. Das heißt, das ist eine kleine Template-Engine.
Zur Performance von Teil-Maker, also zur Vektor-Tile-Erstellung. Er benötigt 400 bis 500 GB RAM für einen Planet. Laufzeit hängt sehr davon ab, was für Hardware man hat. Unser schneller Server braucht 9 Stunden dafür. Der hat also 64 Kerne, 128 Shreds, die Ausgabe auf NVMe-Datenträgern.
Das ist sehr schnell, da könnte man prinzipiell jeden Tag ein Update rendern. Da ist dann eher dann wieder das Weiterverteilen an die eigentlichen Teilserver der Engpass. Wenn man weniger Kerne hat oder gar auf Festplatten schreiben möchte, dann kann man mit 30 Stunden Laufzeit rechnen.
Ich empfehle, lasst die Finger von Festplatten, schmeißt den Müll an. Was wir noch untersuchen müssen, ist, inwiefern es nützlich ist, den Planet in mehreren Regionen aufzuteilen. Die höheren Zoom-Stufen also ab Zoom-Stufe 8 bis 14 mit kleineren Gebieten zu arbeiten, wie zum Beispiel nur ein Kontinent.
Denn bei Zoom-Stufe 7 ist ein Sprung, was die Anzahl der Features und der Layer angeht. Für die kleineren Zoom-Stufen kann man einen gefilterten Planet verwenden, der bloß noch 4 GB groß ist, weil man da sehr viel Ashapefiles nimmt und noch ein bisschen Staatsgrenzen hat.
Das werden wir noch untersuchen und da wird es in Zukunft sicherlich noch einen Vortrag zu dem Thema geben. Nun zum Ausblick. MB-Teils-Dateien gehen nicht mit MAPNIC. Dieses ZXY-Schema hat den Nachteil, dass man sehr viele Inodes benötigt.
Das heißt, typischerweise muss man als erstes mal wieder die Partition neu formatieren. Die Teils benötigen etwa 1,1 TB Platz zurzeit. Da wäre eine mögliche Lösung, alle Vektor-Teils in einer Datei zu speichern, hintereinander, mit einem Index dazu. Dazu verweise ich auf den Vortrag von Michael Greil morgen Mittag zu Versa-Teils.
Es gibt derzeit noch keinen Release von Shortbrett, den wird es dann voraussichtlich nächste Woche geben. Es sind noch ein paar Bug-Fixes, die ich noch merken möchte und die ganzen Teils müssen alle noch erstellt werden.
Das Shortbrett ist ein Open-Source-Projekt. Wir laden daher auch andere zu Mitarbeitern ein, das Schema weiterzuentwickeln, Bugs zu finden und zu beheben. Wir haben auch schon etliche Pull-Request akzeptiert. Wir möchten eine semantische Versionierung pflegen.
Das heißt, wir achten darauf, dass wenn es nicht abwärtskompatible Änderungen gibt, dass das auch in der Versionsnummer richtig sichtbar ist. Damit man da auch gescheit arbeiten kann. Ein Kartenstil für Map Libre, der ist noch in Arbeit oder habt ihr schon einen?
Drei habt ihr schon, das zeigt ihr dann morgen. In Arbeit ist bei uns noch eine Konfiguration für OSM der PGSQL, sodass man auch eine Datenbank mit OSM-Daten befüllen kann, die Tabellen hat, als wären es Vektorteils von den Inhalten her.
Damit kann man dann auch die Mapnik-Stile direkt mit einer Datenbank verwenden. Das ist vor allem für die Kartenstilentwicklung nützlich. Der Quellcode unseres Projekts ist auf GitHub auf mehrere Repositories verteilt und wir laden zum Nutzen und Mitmachen ein.
Vielen Dank für eure Aufmerksamkeit. Vielen Dank, Michael, für den spannenden und detailreichen Vortrag. Wir haben online noch keine Fragen. Gibt es denn aus dem Auditorium eine Frage?
Ja, danke Michael. Auf einigen Fohlen stand oben mal drauf Raster-Tiles mit Mapnik. War das jetzt ein Copy-and-Paste-Type oder habe ich irgendwas missverstanden? Das ist richtig. Wir haben Vektorteils auf dem Server legen und produzieren damit Raster-Tiles für die Kunden.
Wieso habt ihr für die Generation der Raster-Tiles Mapnik benutzt und nicht so etwas wie Map Libre GL Native? Weil wir bislang schon sehr intensiv Mapnik im Einsatz haben und das halt recht gut kennen.
Und es sich damit eben auch in unseren normalen Teilserver-Stack integrieren lässt, der parallel auch aus einer Datenbank Raster-Tiles erzeugt. Eine weitere Frage kommt gleich.
Nicht leuchten, okay. Habt ihr schon richtig gesehen bei der Folie 400 bis 500 GB an RAM? Also ich kenne so 128, aber so viel oder?
Das ist richtig. Mit was ist das begründet? Der Teilmaker lädt alle Daten, die er aus den Blenden geladen hat, erstmal in den RAM. Dafür ist er eben recht schnell. Und 400 bis 500 GB, das hat doch ein bisschen viel. Das sind die Server bei Hetzen dafür recht teuer. Deshalb möchten wir das runterkriegen, idealerweise auf 128 GB, indem
wir einfach die Regionen nacheinander prozessieren, damit die Server bezahlbar bleiben. Okay, danke. Okay, gibt es noch weitere Fragen? Ja.
Habt ihr darüber nachgedacht einen Cache aufzubauen für den Teilmaker, ähnlich wie der PlaneTiler das macht, dass er das nicht alles in RAM ladet? Nein, bislang nicht. Weil das ist gerade, ich glaube der Unterschied zwischen PlaneTiler und Teilmaker, der eine ist ein C++, der andere ein Java und der PlaneTiler schafft das mit 128 GB auszukommen, weil er halt so eine lokale Caching-Struktur aufbaut.
Kann es sein, dass man den PlaneTiler noch nicht konfigurieren kann, sondern er sein Schema hardkodiert hat? Er hat es relativ hardkodiert, es ist ein bisschen was geht, aber... Das ist dann für uns nicht geeignet. Dann müsste ich ja den PlaneTiler folgen. Wir haben zwar den Teilmaker derzeit auch gefolgt, aber nur um ein neues Feature zu haben, das noch nicht gemärcht ist.
Ja gut, aber die Technologie von einem Cache schließt das ja nicht aus. Wenn ihr das Schema kennt, wo ihr hin wollt, dann könnt ihr ja auch darauf basierend einen Cache bauen.
Okay, noch weitere Fragen? Habe ich noch eine... Ist schon Short-Bit in MAP Libre nutzbar? Ja. Ja, kurze Antwort. Der Kartenstil ist dreiviertel fertig oder so.
Dreiviertel? Ja. Okay, alles klar, also es ist absehbar, dass man das dann auch wirklich bald hin wirklich einsetzen kann. Gut, also ich sehe schon, das Thema regt zur intensiven Diskussion an. Ach, ich möchte noch anmerken übrigens, es wird dann auch nächste Woche Teilpakete für alle Regionen der Welt auf dem Geofabrik Download-Server geben.
Ah ja, das ist doch gut zu hören. Dann kann man das gleich mal bei sich ausprobieren.