Ich begrüße alle Anwesenden ganz herzlich zu dem vorletzten Vortragsslot. Schön, dass es parallel zum laufenden OSM-Quiz einige noch geschafft haben. Es geht heute um den Leidensweg von Hartmut, wie er es geschafft hat,

verschiedene Kartenstile parallel laufen zu lassen und ich wünsche viel Spaß dabei. Dankeschön. Mein Name ist Hartmut, ich komme aus Bielefeld tatsächlich, gibt es wirklich.

Ich bin Informatiker und aus dem früheren Leben auch noch Elektroingenieur, aber ich praktiziere nicht. Ich bin Open-Street-Mapper seit 2007, wo ich erst wenig aktiv angefangen habe zu mappen, in 2009. Und ich verdiene meine Brötchen überhaupt nicht mit Geothemen, sondern ich bin supporter bei MariaDB für MariaDB und MySQL-Datenbanken.

Aber darum geht es heute nicht. Und zwar habe ich in 2016 angefangen, eine eigene MapBuzzMatic-Instanz zu hosten. Erstmal nur für meinen eigenen Bedarf.

Nachdem das original MapBuzzMatic-Projekt irgendwann oft lang gegangen ist, dann auch als allgemeine Alternative dafür. Und wenn man sich das heute anguckt, dann sieht man, dass man jede Menge Kartenstile aussuchen kann, schon so viele, dass ich mittlerweile das Ganze nach Kategorien ordnen musste.

Aber das hat am Anfang noch ganz anders ausgesehen. Und zwar ganz am Anfang gab es nur drei Kartenstile zur Ausmalung bei MacroBuzzMatic. Das war einmal der Standard-Open-Street-Map-Stil, dann ein MapBuzzMatic-eigener-Stil, den Sie besonders für Druckausgaben optimieren wollten, der aber nicht mehr weiter gepflegt wird. Und dann haben Sie noch die alten Open-Source-Stile von MapQuest mit angeboten.

Das war dann auch meine Erstausstattung. Das lief alles ganz wunderbar. Aber hatte auch den Vorteil, dass alle drei Stile genau die gleiche Datenbank brauchten. Und dann sind mit der Zeit immer mehr Sachen dazugekommen.

Also irgendwann später, in 2016, habe ich dann als erstes mal die Software so erweitert, dass man über die Basiskarte noch Overlays drüber legen kann, die dann über die eigentliche Hintergrundkarte gedruckt werden. Das erste, was ich da selber gemacht habe, war ein Stil, der ein bisschen so aussieht, wie der Open-Fire-Map-Stil, auf dem man Feuerwachen auf den Randen sehen kann.

Und ich habe als Open-Source-Stil ein Overlay gefunden, das speziell noch mal Golfplätze rendert. Also wo ist der Abschlag, wo ist das Grün und das Fähnchen, wo der Ball in das Loch muss, wo sind Sandbunker und alle solche Sachen.

Dann ging es weiter, dann kam die Open-Topo-Map dazu, die Humanitarian-Map, die Hike-and-Bike-Map. Und mittlerweile bin ich bei fast 50 verschiedenen Kartenstilen und Overlays. Und was ich anbieten kann, ist, da die ganze MAPersmatic-Software auf MAPNIC als Renderer basiert,

brauche ich entweder ein MAPNIC.xml-Stil-File, um eine Karte zu rendern, oder einen Carto.css-Stil, den man direkt in MAPNIC.xml umwandeln kann. Was ich leider nicht immer rendern kann, sind MAP.css-Karten.

Da gibt es einfach keinen Konverter von dem einen Format in das andere. Es gibt nur MAPNIC nach MAP.css, aber leider nicht in die andere Richtung. Dann wird immer wieder gefragt, ob ich auch Seekarten von der Open-C-Map drucken kann. Das geht leider nicht, weil die einen komplett eigenen Render geschrieben haben, der mit überhaupt nichts anderem kompatibel ist.

Und ich kann auch keine Web-Dotals verarbeiten, einfach weil ich als Ausgabeformat zum Schluss auch einfache Rasterbilder erzeugen will. Und je mehr Stylecheats dazugekommen sind, war immer wieder das Problem, zum einen, alle erwarten andere Datenbank-Zugangsdaten

und auch teilweise andere Datenbank-Layout. Dazu kommen wir später noch mal im Detail. Dann ist es oft so, dass an Schriftarten, in dem Fall eine Riesenlatte, möglichen Fonds aufgelistet ist und der MAPNIC-Renderer kann dann sagen,

ok, diese Schriftart finde ich nicht, dann nehme ich die nächste. Oder diese passt genau zu dieser Sprache am besten, dann nehme ich die. Das Problem dabei ist nur, alle, die er nicht findet, dafür druckt er wahrlich nichts in seinem Log-File. Das ist, wenn man mal eine Karte rendert, ist nicht immer wild. Aber wenn man so mal schauen will, was am Laufe eines Tages schiefgegangen ist,

dann stören natürlich die ganzen Fonds an, von denen man weiß, die Schriftart habe ich nicht, weil es die Verlienung nicht gibt oder warum auch immer. Deshalb ist einer der Schritte, die ich mache, wenn ich einen neuen Stil installiere, dass ich einmal durchbrase, welche Fonds werden da drin benutzt, von welchen weiß ich, dass ich sie nicht zur Verfügung habe,

aber eine Alternative, die ich zur Verfügung habe. Und dann fliegen die, von denen ich weiß, dass ich sie nicht habe, einfach aus dem Stil raus, damit ich keine Erwarnungen kriege, Ähnlich habe ich das auch bei den Kato-CSS-Stilen. Es gibt mittlerweile ältere Stile, die immer noch Attribute benutzen,

die als veraltet gelten. Die werden zwar noch unterstützt, aber da gibt es bei der Verarbeitung auch jedes Mal Warnungen. Also Attributname in Tag so und so, wie man unterstützt. Weiß ich auch, dass es so ist. Ist kein Fehler, interessiert mich nicht. Möchte ich eine Log-Datei nicht haben. Also schreibe ich die Stilpfeile einmal so um, dass diese Texte nicht mehr drin sind.

Das sind beide Sachen, die automatisch einfach gehen. Und dann hatte ich bis vor kurzem auch noch als dritten Vorverarbeitungsschritt. Es gibt in MAPNIC die Möglichkeit, wenn man mehrere Layer hat, die mit sogenannten Comp-Operationen verschmelzen.

Also bestimmte Überblenden, Funktionen zu spezifizieren. Und solche Dinge, das hat dazu geführt, dass das zwar bei den Bitmap-Formaten, die ich exportiere, wunderbar aussieht. Das war bei den PDFs und SVGs, die eigentlich den Sinn haben, dass man sie vielleicht noch mal nachbearbeiten kann. Das ganze File, genauso groß war wie das Bitmap-File.

Und wenn man sich dann angeguckt wird, was steht da drin? Da war halt nur noch ein SVG-File. Ich bin ein SVG-File. Und hier ist ein riesengroßes Bild drin. Und das sind die Pixel-Daten dafür. Also Nachbearbeiten mit einem Vektor-Programm war nicht mehr möglich. Deswegen habe ich gesagt, okay, diese verschiedenen Comp-Operatoren,

die ignoriere ich einfach. Sieht dann zwar nicht mehr ganz so schön aus, aber dafür kann man es wenigstens nachbearbeiten. Mittlerweile hat sich herausgestellt, das war nur ein ganz einfaches Problem. Und zwar, dass der Renderer standardmäßig versucht, ein möglichst altes, rückwärtskompatibles SVG zu erzeugen. Und neuere Features hat mich unterstützt.

Und ich sage, ich möchte ein SVG nach aktuellem Standard. Ich glaube, das ist Regulation 1.3 im Augenblick. Dann funktionieren diese ganzen Operationen auch wieder. Und es kommt ein ganz sauberes Vektor-File raus, dass man es nachbearbeiten kann. Wie ich sagen möchte. Deswegen ist der letzte Punkt mittlerweile zum Glück weggefallen.

So, das sind so die Kleinigkeiten, die man erstmal in den Kartenstilen an sich machen muss. Aber dann kommt eben noch das große Problem, was eben mein Punkt Nummer 1 war. Datenbankzugang. Um eine Karte zu ändern, brauche ich zum einen den Stil, wie soll die Karte aussehen. Aber ich brauche natürlich auch die Daten, was soll überhaupt auf der Karte da sein. Also welchen Kartenausschnitt will ich zeigen.

Da könnte man im Prinzip für kleine Kartenausschnitte auch direkt USM-Daten als XML benutzen. Aber wenn man das wirklich weltweit anbieten will, dann skaliert das nicht. Deswegen hat man immer erstmal den Schritt, dass man die USM-Daten in der PostGIS-Datenbank importiert und dann von da aus weiterarbeitet.

Da gibt es drei verschiedene Importmöglichkeiten. Es gibt einmal das USM2PGSQL-Tool. Das ist das Tool, das zum Beispiel der OpenStreetLab-Standards-Stil einsetzt. Dann gibt es als Alternative nochmal Impossum.

Und nochmal als Spezialfall die Waymark Trails. Da hat Sarah einen Poison-Trip geschrieben, das mit Poison und SQL Alchemy tatsächlich Wanderwegrelationen ganz gezielt aus dem OpenStreet mit Daten herausfiltert und genau für diesen einen Einsatzzweck in einer speziellen Datenbank hinterlegt.

Das USM2PGSQL unterstütze ich. Die Waymark Trails unterstütze ich als Spezialfall, weil ich die Wanderwege auch unbedingt für meine eigenen Karten haben wollte. Aber Kartenstile, die auf ein Impossum-Schema aufsetzen, kann ich leider nicht unterstützen. Dafür fehlt mir mittlerweile einfach der Plattenplatz, um das alles vorzuhalten.

Und auch wenn man einen Stil hat, der ein USM2PGSQL-Schema voraussetzt, gibt es immer noch Varianten davon. Ganz am Anfang war es so, die drei Stile, die bei MatBosMatic standardmäßig dabei waren und unterstützt waren, die haben alle mit demselben Import funktioniert. Die haben alle dieselben Spalten in den Datenbanktabellen haben wollen.

Aber dann gab es Leute, die ihre eigenen speziellen Interessen hatten, wie zum Beispiel die Golfplätze. Oder es gab auch einzelne nationale Kartenstile, die dann noch wieder irgendwelche Features dabei haben wollten, die im Standardstil nicht drin sind. Und da kann man beim USM2PGSQL beim Import sagen,

dieses USM-Tech möchte ich mit in der Datenbank haben als eigene Spalte. Das heißt, noch mit der Zeit divergieren die Stile alle ein bisschen auseinander. Jeder fügt noch ein bisschen was dazu. Die Basissatz, den alle benutzen, also Straßen, Reusachhausnummern, das benutzt natürlich alle. Aber es sind immer so spezielle Sachen dabei, wie Golfplätze, Hydranten,

was auch immer, die nur einzelne Stile oder nur genau einen Stil benutzen, die im Standardimport eigentlich nicht drin sind. Das heißt, ich habe in jedem der Stile eigentlich einen anderen Satz von Attributsstaubten, die der Stil haben will, mit denen er arbeiten will.

Und das Ganze ist möglich entweder, indem man wirklich eigene Spalten dafür anlegt, oder indem man eine HaarStore-Spalte in der Datenbank anlegt. HaarStore ist im Endeffekt ein Hash, wo ich Schlüsselwertpaare habe, genauso wie bei der Umstieg mit Techs auch, nur in einem speziellen Datenbanktyp.

So sahen ursprünglich die Tabellen dann aus. Wir haben immer das eigentliche Geoobjekt als Geometrie drin, also Punkte, Linien oder Polygone. Dann haben wir noch einen Tech, das einfach die vertikale Reihenfolge beschreibt, das ist immer da.

Und alles, was hier oben steht, von Axis bis Wood in diesem Fall, mit ganz vielen Zeilen dazwischen, das sind ja als eigene Datenbankspalten, die jeweils für einen Open-Street-Map-Tech da sind, wo zum Teil die Stile jeweils andere Vorstellungen haben, was da alles da sein soll.

Also haben wir einen gemeinsamen Sockelsatz von Techs, die sie alle benutzen, und dann kommt alles dazu, was sie noch speziell haben wollen. Wie ich schon sagte, am Anfang war das noch einfach, aber je mehr neue Stile dazukamen, desto mehr Sonderfälle hatte ich und musste immer wieder neue Spalten dazu fügen,

was am Anfang bedeutet hat, ich habe die Datenmark einmal komplett weggeschmissen, neu importiert, war okay, solange ich nur Karten für Deutschland rendern wollte, aber in dem Moment, wo ich angefangen habe und genug Platz hatte, um die ganze Welt zur Verfügung zu stellen, hat das immer bedeutet, einmal ganze Datenmark wegschmeißen, ein bis zwei Tage warten,

wenn irgendwas schief gegangen ist, vielleicht nur noch länger, bis es wieder weitergehen kann. Also habe ich dann gesagt, okay, es gibt die Möglichkeit, in dieser Haarstrausspalte wirklich alle Techs, die ein OSM-Objekt hat, zu importieren. Da sind zumindest die Daten schon einmal an der Datenmark da, wenn auch nicht unbedingt das eigene Spalte.

Und wenn ich jetzt einen neuen Stil zufüge, der ein bestimmtes Feld hat, das ich gar nicht habe, kann ich in den SQLer-Fragen in dem Stil das Ganze so umschreiben, dass er stattdessen diese Haarstrausspalte benutzt. Beleuchtet aber auch, für jeden Stil, den ich so angepasst habe, pflege ich im Endeffekt einen eigenen Fork, und immer wenn sich das Stil etwas ändert,

muss ich auch wieder gucken, ob ich das so nachpflegen kann, direkt merken kann, oder ob ich wieder Text umschreiben muss. Das ist natürlich nicht schön, das arbeite ich eigentlich nicht machen will. Und deshalb läuft das mittlerweile so, dass ich den gleichen Ansatz benutze, den Sven Gäggos auch für den deutschen Kartenspiel und seinen Render-Server benutzt.

Und zwar ist in der eigentlichen Tabelle, die jetzt importiert wird von OSM2PQ SQL, ist neben den speziellen Feldern für die Geometrie usw., ist für die Text wirklich nur noch ein Haarstorffeld drin, wo die alle drin sind und gar keine expliziten Spalten mehr.

Und die Kartenstiele greifen aber jetzt nicht direkt auf die importierte Tabelle zu, sondern darüber wird nochmal eine View gelegt, die alle Felder, die direkt angesprochen werden, nochmal wieder explizit als View-Spalte zur Verfügung stellt.

Das sieht dann so aus, die eigentliche Datenbank-Tabelle sieht nur noch so aus, ich habe nur noch die Textspalte hier, und dann brauche ich eine View, die aussieht wie die ursprünglichen Tabellen, wo dann doch wieder einzelne Elemente der Textspalte auf Spalten,

die dann im View-Ergebnis direkt zugreifbar sind, abgebildet werden. Da fehlt noch was. Der Vorteil ist jetzt, ich muss, wenn ich einen Stiel habe, der eine Spalte benutzt, die ich noch nicht habe,

nicht mehr den Stiel editieren, um direkt auf die Textspalte zuzugreifen, ich muss auch nicht komplett neu importieren, ich muss nur einmal diese View wegwerfen und neu anlegen, mit dem zusätzlichen Tag, was jetzt dazu gekommen ist. Damit habe ich schon mal erreicht, dass sich alle Stiele aus demselben Datenbank importieren.

Jetzt habe ich nur noch das kleine Problem, dass jeder Stylefile-Autor am Anfang seine eigene Vorstellung davon hatte, wie der Datenbank-User heißen soll, was für ein Passwort er hat und wie die Datenbank heißt. Das muss also auch noch einmal nachgearbeitet werden, damit das klappt. Bei manchen der Stiele ist das so, dass die eine eigene XML-Include-Datei haben,

wo das drin steht. Dann ersetzt man die einfach mit der entsprechenden Variante, wo die eigenen Zugangsdaten drin sind. Dann passt das schon. Beim anderen ist das einfach hard codiert in den Stylefiles drin. Da muss ich nochmal drüber gehen und muss überall mit Suchen ersetzen, den Datennamen, den Usernamen und das Passwort ersetzen.

Das geht aber zum Glück bis hierzu, dass alle Stiele so formatiert sind, dass das alles auf eigenen Zeilen steht und einfach mit dem Stream-Editor ersetzt werden kann, ohne dass ich erst in die Tiefen des XML-Passings dafür absteigen muss. Damit habe ich dann das Thema Datenbanken schon mal erledigt.

Jetzt kriege ich alle Kartenstiele aus demselben Datenbank-Import generiert. Muss die Datenbank noch einmal vorhalten. Da die mittlerweile über 800 Gigabyte groß ist, habe ich auch gar nicht Platz, die mehrfach vorzuhalten. Dann haben wir aber nebenbei als Datenquelle auch noch Shapefiles. Die benutzen wir zum Beispiel für so Sachen wie Küstenlinien,

weil wir da nicht sicherstellen können, dass die in den Open-Street-Mitdaten selber immer in einem korrekten Zustand sind. Da kann schon mal irgendwo eine Lücke sein, in der fies das Wasser bis tief in die Kontinente hier rein. Und da benutzen auch wieder die meisten Stiele eine gewisse Menge an Shapefiles,

die allgemeinsam ist. Aber jeder Stiel bringt dafür ein eigenes Installationsscript mit, das die Dinger runterlädt, auspackt, vorbereitet. Das heißt, ich habe sowohl ein Download von vielen Dateien, der immer wieder angestoßen wird, obwohl ich ihn eigentlich nur brauche, und ich habe da auch identische Kopien der Dateien auf meinem File-System.

Da geht es dann auch um Größenordnung von Downloads um die 2,7 Gigabyte, ausgepackt um die 3,5 Gigabyte. Das möchten wir natürlich nur einmal haben ohne Renodanzen. Zum Glück ist das bei den meisten Stiefel so,

die erwarten entweder alle Shapefiles zusammen in einem Verzeichnis, das in der Regel World Boundaries heißt, oder es gibt ein Verzeichnis-Data, wo dann für jeden Stiel noch einmal ein Unterverzeichnis drin ist. Und dann gibt es noch ganz ab und zu dass dasselbe Shapefile unter verschiedene Namen angesprochen wird.

Also hier zum Beispiel einmal unter 10 Meter irgendwas und dasselbe noch mit der Präfix NE von Natural Earth. Das ist die Datenquelle, wo die Shapefiles herkommen. Und dann kommt erst der Rest des Namens. Die sind wahrscheinlich in der Vergangenheit irgendwann mal umgenannt worden und der Stiel, den ich hatte, ist noch so alt, dass er das noch nicht mitgeführt wird.

Dem spricht habe ich jetzt für eine große Liste aller Shapefiles für verschiedene Stielen benutzt werden. Ich lade jeden davon noch einmal runter und packe den aus und baue mir dann einmal die Variante mit dem Data-Verzeichnis,

wo jeder Stiel sein eigenes Verzeichnis drin hat und mache dann nochmal ein neues Verzeichnis auf für das World-Boundaries-Format, wo alle ausgepackten Stiele zusammen drin sind und will den einfach mit dem Linksteren ab. Damit habe ich die Files zwar noch einmal auf der Platte, aber jeder Stiel kriegt hier in dem Format, in dem Enteilsystem layout, wie er es erwartet.

Und in den einzelnen Stielen muss ich ja nur noch auf das eine oder das andere Zeichniss verlinken. Dann passt das auch wieder, ohne dass ich hier einen Danzen habe. Das heißt, ich spare Wandbreite, ich spare Plattenplatz, ich kann das Ganze in einem Rutsch zentral aktualisieren und ich kann auch noch, weil ich jetzt selber die Dateinunterlage auch lokal cache,

ohne dass ich noch einen Caching-Proxy dazwischen brauche, um doppelte Downloads zu vermeiden. Nachteil ist, wenn ein neuer Stiel dazukommt, muss ich mir immer erst einmal wieder das Installationsfall angucken, was installiert er vielleicht noch, was ich noch nicht habe, meine Liste erweitern oder auch wenn ein Stiel mit sich was ändert, ein neues Shapefile dazukommt,

aber das passiert so selten, dass das nicht wirkliche Arbeit ist. Das ist immer die Liste der verschiedenen Shapefiles, die im Augenblick genutzt werden. Die geht noch ungefähr bis hier, passt ja nicht mehr auf den Bildschirm. Dann habe ich als drittige Datenquelle noch Höhen-Daten. Die sind mir freundlicherweise von der OMSNorma zur Verfügung gestellt worden.

Die haben sehr viel Arbeit reingesteckt aus verschiedenen Höhen-Datenquellen, gutes einheitliche Höhenlinien und geländere Schummerungen zu machen. Das sind für die Höhenlinien, wenn das Ganze importiert ist, nochmal 500 GB Datenbank. Damit ist der Rechner auch wirklich schon ziemlich voll.

Wird genutzt bisher eigentlich nur vom Open-Topo-Map-Stil und ich habe das nochmal extraiert, dass man das als eigenes Overlay auch über andere Stile drüberblenden kann. Dann kommen wir zu der einen Baustelle, die ich noch habe, nämlich das Hill-Shading, das man als Geländeschummerung, Geländekonturen besser erkennen kann.

Die kann ich im Prinzip auch von der OMSNorma bekommen, aber die sind leider in einem anderen Format, als die Open-Topo-Map die möchte. Deswegen habe ich das im Augenblick in der Open-Topo-Map einfach ausgeschaltet. Dann habe ich noch die Pista-Map, die Ski-Pisten rendet.

Die erwarte ich nochmal in einem anderen Format, die hat aber auch die entsprechenden Skripte, um die zu erzeugen. Damit erzeuge ich im Augenblick aber nur Hill-Shading-Files ungefähr für den Bereich Deutschland, Österreich, Schweiz, damit ich die Alpen abgebildet habe. Für die ganze Welt habe ich weder die Rechenpower noch den Plattenplatz, um das alles zu machen.

Das war es dann auch. Wenn da irgendwer gute Ideen hat oder noch einen Kartenstil hat, den ich noch nicht habe, immer her damit.

Was sind denn die Formatunterschiede bei den Höhenlinien, von denen du gesprochen hast? Wollen die eines als Shapefile in der Datenbank haben? Nein, sie wollen beide TIFF-Dateien haben. Aber ich habe es nicht hinbekommen, dass ich die Open-Topo-Map-Dateien mit den Renderregeln von der Open-Topo-Map verheiratet kriege.

Du hast gesagt, dass du das alles mit Fuse machst. Wie ist denn das da mit den Indexes? Ich weiß zumindest, dass Open-Topo-Map Kratos hat einige, um das Rendering schneller zu machen.

Wie löst du das? Da habe ich auch erstmal die entsprechenden Indexe, die Sven für seinen deutschen Stil anlegt. Die entsprechen ja im Wesentlichen von dem Standardstil. Und für den Rest muss ich natürlich auch hergehen, dass ich nicht auf der eigentlichen Spalte indiziere, sondern dann auf der entsprechenden Hard-Store-Untermenge.

Das ist auch noch ein bisschen Handarbeit, aber das ist auch das meiste durch die Indexe, die von Sven kommen, schon abgedeckt. Gibt es noch Fragen? Sonst hätte ich noch eine kleine. Du hattest erwähnt, dass die Zugangsdaten immer ganz wüst aus dem XML bearbeitet werden müssen.

Ist es die Bearbeitung im MAPNIC-XML? Ja. Viele Styles haben ja auch MML-Files, in denen das ja eben parametrisiert wird. Wäre das vielleicht eine Erleichterung, wenn du es da zentral bearbeitest und dann erst das MAPNIC-XML erzeugst?

Bei den ersten, die ich angeschaut habe, da war es nicht zentral unterlegt, sondern es war in jeder Regel einzeln. Da war es einfacher, das in den MAPNIC-Dateien zu machen, als in den Carto-Files. Aber das war eher Zufall, dass es da einfacher war.

Es ist auch zum Glück so, dass ich da nicht wirklich mit dem XML-Parser rangehen muss. Und es reicht einfach mit SED, wenn da steht DBNAME OSM, dann ersetzt du das durch DBNAME GISS und dann passt das. Das wird irgendwann wahrscheinlich auch kaputt gehen, aber bis jetzt funktioniert das. Gut, dann herzlichen Dank für deinen Vortrag. Jetzt wissen wir mal Bescheid, wie es mit mehreren Kartenzielen auf einem Server geht.

Und jetzt geht es weiter mit einer kurzen Pause.