Webseite offline auf mobilen Geräten

Download
Offline-Webseite

Ich hatte ursprünglich die Idee, eine abgespeckte Offline-Version der Webseite zum Download anzubieten, die auf einer SD-Karte in einem Smartphone/Tablet gespeichert werden kann, um dieses wie ein GPS-Gerät zu verwenden, aber mit weitaus größerem Informationsgehalt und unabhängig von einer Netzverbindung.

Leider hat es sich erwiesen, dass die Datenmengen, um die es dabei geht, so gewaltig sind, dass sie nur mit größerem (finanziellen) Aufwand auf einem externen Server zum Download angeboten werden könnten. Insbesondere das Kartenmaterial, das ja nicht online herangezogen werden kann, sondern auf einer lokalen SD-Karte im Mobilgerät untergebracht werden muss, umfasst mehr als hundert Gigabyte!

Aus diesem Grund habe ich mich entschlossen, für jedes Land eine eingedampfte Offline-Webseite (ohne Fotos) zu erstellen, bei dem das Kartenmaterial noch fehlt und in Eigenregie hinzugefügt werden muss. Bei den Versuchen, so etwas zu realisieren, ist mir aber sehr schnell klar geworden, dass diese Aufgabe für Normalcomputersterbliche deutlich zu kompliziert ist. So habe ich den gesamten Vorgang von vorne bis hinten automatisiert. Beim Download, aber auch beim Starten der Kartenproduktion dürfte (nein, sollte) die Firewall und/oder der Virenscanner Alarm schlagen. Um die benutzten Programme freizugeben, sollte man zunächst die Test-Webseite ausprobieren, die sich auf ein kleines Gebiet beschränkt und nach wenigen Minuten (statt erst nach vielen Stunden) abgeschlossen sein sollte.

Die folgenden drei Anleitungen, wie man zu einer Offline-Webseite im Mobilgerät kommt, richtet sich an Computer-Dummies, mäßig Interessierte und solche, die sich näher mit dem interessanten Thema Landkartenproduktion auseinandersetzen wollen.

Als absoluter Technik-Dummi möchtest du nichts über das Wie und Was wissen, sondern dass alles auf Knopfdruck funktioniert. Allerdings solltest du sicherstellen, dass dein Computer die Mindestvoraussetzungen erfüllt, um eine Offline-Version der Webseite zu erzeugen. Dein Computer sollte:

- ein Rechner mit 64-bit-Windows sein und
- mindestens 8 GB Arbeitsspeicher besitzen.

Diese beiden Angaben findest du unter:
Start->Systemsteuerung->System und Sicherheit->System

- JAVA muss installiert sein (bei dieser Gelegenheit direkt updaten) und auch das
- Microsoft-.NET-Framework 4 (mit diesem Progrämmchen testen)

Sind alle diese Punkte geklärt, klickt man oben auf "Download Offline-Webseite", lädt die Datei hinunter, platziert sie auf dem Desktop und entpackt sie.
Es ist unbedingt darauf zu achten, dass sich die entpackten Dateien in einem eigenen Ordner (Offline_Website) befinden!
In diesem Ordner gibt es zwei Unterordner und eine Datei namens Offline_Website.cmd zu sehen. Jetzt musst du noch für ein paar Minuten die Firewall und den Virenscanner abschalten und dann auf diese Datei doppelklicken.

Ein schwarzes Fensterchen öffnet sich, in dem man zunächst das Land auserwählt, für das man die Offline-Karte erzeugen möchte. Nach der Bestätigung sieht man irgendwelche kryptischen Zeichen vorbeihuschen. Jetzt kannst du einen Kurzurlaub antreten, denn die Produktion der Offline-Version der Webseite wird mehrere Stunden bis mehrere Tage (und Nächte) dauern. Keine Sorge, solange du das schwarze Fensterchen siehst, ist alles in Ordnung, auch wenn sich scheinbar darin nichts tut.

Erst nach dem Abschluss aller Arbeiten verschwindet das schwarze Fenster. Es gibt jetzt nur noch einen Ordner, dessen Inhalt du auf eine auf eine SD-Karte oder einen USB-Speicherstick (16 GB) verschieben musst, was nochmals erheblich Zeit in Anspruch nehmen dürfte.

Die SD-Karte mit der Offline-Webseite wird im Smartphone versenkt bzw. in das Tablet gestöpselt. Die Offline-Webseite läuft nur unter Firefox (nicht Chrome). Um zu der Webseite auf der SD-Karte zu kommen, gibst du in die Adresszeile des FF-Browsers "file:///sdcard/main.html" (tatsächlich, mit drei /) ein.

Manche Leute interessieren sich doch dafür, was Software auf dem Computer so alles anstellt, besonders, wenn es nicht zu sehen ist. Die cmd-Datei im Download ist eine so genannte Batch-Datei, wie man sie zu Computersteinzeiten noch unter DOS gebrauchte. Batch-Dateien laufen in der Kommandozeile, die bei moderneren Windows-Versionen cmd.exe heißt. Batch-Dateien können nicht nur Dateien manipulieren, sondern enthalten unter anderem Anweisungen für Programme, die sich weitgehend unsichtbar verhalten (können).

Vier solcher Kommandozeilen-Programme sind in dem Download (im Ordner pgm) schon enthalten, nämlich der Download-Manager "wget", das Entpackprogramm "unzip", der Stream-Texteditor "sed" und die OSM-Schere "osmconvert". Die ersten beiden sind natürlich von Anfang an notwendig, weil man ohne wget nichts herunterladen und man mit wget zwar unzip herunterladen, aber dessen komprimiertes Download-Paket nicht entpacken kann. Das fünfte Programm "Maperitive" ist schließlich dafür zuständig, das Kartenmaterial zu zeichnen.


Offline-Webseite herunterladen
Die cmd-Datei lädt zunächst alle Bestandteile der Webseite heruntergeladen, zunächst die Dateien, die bei allen Ländern gleich sind und dann die länderspezifischen. An einigen Dateien werden durch "sed" kleinere, aber notwendige Änderungen vorgenommen. Durch diese Vorgehensweise ist es möglich, die originalen Dateien der Website zu verwenden (anstatt eine zweite modifizierte Version vorrätig zu halten), so dass ich Änderungen, Korrekturen oder neue Inhalte nicht zweimal einpflegen muss.

"wget" speichert die heruntergeladenen Dateien so, dass direkt die letztendliche Verzeichnis-Hierarchie erzeugt wird. Tatsächlich gibt es nur drei Javascripts mit stark veränderten Inhalten, die nicht auf diese Weise heruntergeladen und modifiziert wurden, sondern schon im Download im Ordner "website" vorhanden waren.Der letzte Download, den die Batch-Datei veranlasst, ist ein Paket mit einer weiteren, länderspezifischen Batch-Datei, die nun das Kommando übernimmt.


Karten zerlegen mit osmconvert
Zunächst wird das OSM-Kartenmaterial vom Server der Geofabrik heruntergeladen, in der Regel für ein ganzes Land oder - wo möglich - für einzlene Bundesländer. Obwohl die Datensätze beschränkt sind, sind sie für unsere Bestimmung immer noch viel zu groß und müssen mit der OSM-Schere osmconvert weiter unterteilt werden.

Im letzten Download befanden sich auch mehrere *.poly-Dateien, die nichts mit der Webseite zu tun haben, sondern die Koordinaten für das Programm osmconvert enthalten. Osmconvert liest die große Datei ein und schneidet einen oder mehrere Abschnitte heraus. Eine Besonderheit ist die Datei land_track.poly: Der Ausschnitt aus den Kartendaten beschränkt sich auf wenige hundert Meter rechts und links der E8-Route. Damit soll die Datenmenge bei der Erzeugung der Kartenkacheln in den beiden höchsten Zoomstufen in Grenzen gehalten werden. Zum Abschluss hat osmconvert einige unkomprimierte *.osm-Datensätze erzeugt, die, wie man sehen kann, nicht gerade winzig sind.


Aus Text werden Bilder
Die OSM-Daten sind eine Art Vektorgrafik, die man in ein Grafikformat (Kacheln oder Tiles genannt) umwandeln muss, damit Sie im Browser angezeigt werden können. Dies ist die Aufgabe des Renderers Maperitive. Jetzt kommt die kleine Datei land.txt zum Einsatz, die bisher überhaupt nicht erwähnt wurde. Sie ist auch eine Art Batchdatei, aber speziell für das Programm Maperitive. Sie sieht vor, dass die OSM-Daten in einem bestimmten Stil in Kartenkacheln verwandelt werden, der auch Höhenlinien und eine Schummerung enthält.
Zunächst werden deshalb die Höheninformationen (.hgt-Dateien) des jeweiligen Gebietes heruntergeladen, entpackt und in den dafür vorgesehenen Ordner in Maperitive verschoben. Dann wird Maperitive gestartet und land.txt als Script angegeben. Der Renderer erzeugt in stunden- bis tagelanger Arbeit die Kartenkacheln und legt sie direkt in den richtigen Ordner der Webseite ab. Bei den beiden höchsten Zoom-Stufen sind (leider) weder Höhenlinien noch Schummerung möglich. Der Grund dafür ist, dass Maperitive die Kacheln, die zwar mit Höhenlinien und Schummerung versehen sind, aber sonst keinen Inhalt haben, nicht aus dem Nutzmaterial herausfiltern kann. Es würde statt dessen ein riesenhafter Datensatz für das gesamte vom Track aufgespannte Rechteck erzeugt.


Aufräumen
Wenn Maperitive seine Arbeit abgeschlossen hat, bleibt nur noch, den Inhalt des Ordners auf eine SD-Karte oder einen USB-Speicherstick zu schieben.
Ist das gelungen, kann der gesamte ursprüngliche Ordner gelöscht werden. Damit das nicht zeitaufwändig über den Papierkorb passiert, klickt man rechts auf den Ordner und drückt beim Löschen zu Beginn auf die Shift-Taste.


Die automatische Produktion einer Offline-Version der Webseite hat etliche interessante Probleme aufgeworfen und noch interessantere Lösungen hervorgebracht, insbesondere den Einsatz von altertümlich anmutenden UNIX-Programmen ohne grafische Oberfläche, die aus einer Batch-Datei heraus gesteuert werden. Die etwa 400 GNU-Programme sind vom Projekt GnuWin32 auch auf Windows portiert worden.

Wenn man sich ein wenig an die Anwendung dieser Programme gewöhnt hat, wird man feststellen, dass sie zwar wenig komfortabel, aber extrem schnell und auch sehr vielfältig, ja einzigartig in ihren Möglichkeiten sind. Für die Offline-Website benutze ich das Downloadprogramm wget, den Dekomprimierer unzip und den Stream-Texteditor sed. Ich habe ein solchen Gefallen daran gefunden, dass ich mittlerweile die gesamte GNU Compiler Collection (GCC) auf meinem Computer installiert habe.

Es würde hier zu weit führen, auf die speziellen Optionen und Kommandos dieser drei Programme einzugehen. Statt dessen wollen wir uns um die Erzeugung einer Webkarte aus den OSM-Rohdaten beschäftigen.


Slippy Map – Eine kurze Einführung
Sich auf einer Webseite unter dem Cursor bewegende Karten werden Slippy Maps genannt. Bekannteste Beispiele solcher Karten sind GoogleMaps und OpenStreetMap. Damit Slippy Maps in einem Gerät angezeigt werden können, ist normalerweise eine Internet-Verbindung erforderlich. Steht aber, was vor allem bei einem mobilen Gerät (Tablet, Smartphone) der Fall sein kann, eine solche Verbindung nicht oder nicht in ausreichender Qualität zur Verfügung (oder möchte man sich die daten/kostenintensive Kommunikation mit dem Kartenserver ersparen), bleibt die Mattscheibe dunkel. In einem solchen Falle hilft nur, die Karte offline im Gerät mit sich zu führen.

Eine Slippy Map ist nichts anderes als ein aktives JavaScript in einer Webseite, das eine verschieb- und zoombare Karte anzeigt. Das Script ermittelt die Geokoordinaten des im Bildschirm dargestellten Kartenbereichs und gibt diese Daten an den externen Kartenserver weiter. Dieser Server liefert kleine Kartenkacheln oder Tiles in einem Grafikformat an die Webseite zurück. Für jede Zoomstufe steht auf dem Server ein eigener Kartensatz zur Verfügung. Bei jedem Verschieben und bei jedem neuen Maßstab erfolgt dieser Vorgang von neuem beziehungsweise werden für das Fenster fehlende Tiles ergänzt.

Alles, was man für eine Offline-SlippyMap tun muss, ist also, die Kartenschnipsel lokal zu erstellen/zu sammeln und in dem Slippy-Map-Script die lokale Adresse statt der des entfernten Tile-Servers einzutragen.

Nun sind die meisten Betreiber von Tile-Servern alles andere als begeistert von der Idee, dass die Tiles massenweise heruntergeladen werden, nicht, weil sie eifersüchtig über ihre Daten wachen, sondern weil dieser Missbrauch die Server dermaßen überlastet, dass diese ihre eigentliche Funktion, das Liefern von Slippy Maps für Online-Karten nicht mehr wahrnehmen können. Es gab (und gibt immer noch) Programme, die einen Massendownload ermöglichen, aber die meisten Server verweigern folgerichtig die Zusammenarbeit mit solchen Programmen, gleichzeitig sind in den noch existierenden Programmen Sperren oder Bremsen gegen solche Massendownloads eingebaut.


Download von Kartenrohdaten
Natürlich gibt es auch einen ehrenhaften (und deshalb steinigeren) Weg, um an Kartenkacheln für eine lokale Slippy Map zu kommen. Alle Informationen, die in OpenStreetMap-Karten stecken, sind aber nicht in Grafik-, sondern in reinen Textdateien (im XML-Format) auf den OSM-Servern gespeichert. Jeder Punkt, jedes Symbol, alle Linien, alle Informationen, die auf der Karte erscheinen, sind hier mit ihren Geokoordinaten aufgeführt.

Die Rohdaten können legal und guten Gewissens heruntergeladen werden. Die Rohdateien sind zwar lange nicht so umfangreich wie ihre figürlichen Entsprechungen im Grafikformat, aber auch nicht gerade klein. Deshalb sollte man auch nur den Bereich herunterladen, den man wirklich benötigt. Die Daten stehen bei den diversen Stellen in diversen Formaten zu Verfügung. Das normale Format von OSM-Dateien ist .osm, aber normalerweise arbeitet man mit komprimierten Dateien wie .pbf oder .bz2.

Hier sind die Adressen von wichtigen Servern, die OSM-Daten zur Verfügung stellen:

OpenStreetMap für kleine Bereiche
OpenStreetMap für mittlere Bereiche (OSM-Overpass-API)
Erde komplett
Geofabrik (Kontinente, Länder, Regionen)

Bei der deutschsprachigen Webseite der Geofabrik finden sich auch einige interessante Werkzeuge, zum Beispiel die Möglichkeit, für ein vorgegebenes Gebiet den Umfang der Rohdaten und der Kartenkacheln zu ermitteln. Wie man sehen kann, sind die Datenpakete nicht gerade klein, erst recht nicht, wenn die Komprimierung (notwendigerweise) aufgehoben wird.


Rohdaten mit Osmcovert zerlegen
Bei ganzen Ländern mit vielen Karteninformationen sind die Dateien so groß, dass sie in Teile zerlegt und verarbeitet werden müssen, ansonsten schmiert der nachfolgend beschriebene Renderer Maperitive ab. Die Grenze lag bei meinen Versuchen mit den Daten von Irland bei etwa 150 MB im komprimierten pbf-Format, was ungefähr 250 MB im komprimierten bz2-Format, aber 3 GB (!) einer unkomprimierten OSM-Datei entspricht. Zum Vergleich: Die Rohdaten von Deutschland im pbf-Format sind schon mehr als 3 GB groß, was - ich habe es nicht ausprobiert - unkomprimierten 60 GB entspricht. Damit lässt sich natürlich an einem normalen PC mangels Arbeitsspreicher nichts ausrichten, das Datenpaket muss aufgeteilt werden.

Leider sind die meisten Programme, die sich mit Kartenbearbeitung beschäftigen, alles andere als benutzerfreundlich und wurden für Linux entworfen. Das heißt leider meist, dass sie über kein grafisches Benutzerinterface verfügen und wie in der Computersteinzeit über die Kommandozeile bedient werden müssen.

Eine geeignete "Schere", um die großen OSM-Datensätze zu zerlegen, heißt Osmcovert und ist ein solches Kommandozeilentool. Es erfordert das Java Runtime Environment, dessen Speicherfreigabe auf 4GB erhöht werden sollte.

Osmconvert ist recht einfach anzuwenden, wie die deutschsprachige Bedienungsanleitung zeigt. Es kann mit dem kompaktesten Eingangsformat (pbf) umgehen, die Eingangsdatei gemäß so genannter Polygon-Dateien zerlegen und ist zudem rasend schnell!

Möchte man Osmconvert dauerhaft auf dem Rechner verwenden, so empfiehlt es sich, das Java-Programm in den Gruppenrichtlinien anzumelden. Wie das funktioniert, wird auf der Learnosm-Webseite für das Programm Osmosis beschrieben, funktioniert aber für Osmconvert genau so. Der deutsche Eintrag in die Windows-Eingabezeile heißt übrigens "system pfad".

Ein kleiner Nachteil von Osmconvert soll nicht verschwiegen werden: Die Eingangsdateien dürfen bei der 32-bit-Version von Osmconvert nicht größer als 2 GB sein! Bisher erreichen aber nur die größten Länder Europas, Frankreich, Deutschland und Russland solche Ausmaße. Wenn die Quelldatei das erlaubte Maß überschreitet, muss man die Ausschnitte der Sub-Regionen dieser Länder verarbeiten, die bei der Geofabrik zur Verfügung stehen.


Polygon-Dateien und andere Parameter
Ein möglicher Befehl, um mit Osmconvert einen durch zwei diagonale Eckkordinaten (-b=...) aufgespannten Bereich aus der Quelldatei germany.pbf auszuschneiden, lautet beispielsweise:
osmconvert germany.pbf -b=10.5,49,11.5,50 -o=nuernberg.osm
Nach -o= legt man den Namen und das Format der Ausgangsdatei fest.

Es gibt eine Möglichkeit, auch ein nicht rechteckiges Polygon zu definieren. Die geschieht durch kleine externe Textdateien, die Geokoordinaten für einen bestimmten Bereich enthalten und auf die im Osmconvert-Befehl verwiesen wird. Diese Polygon-Dateien sind nach einem bestimmten Muster aufgebaut. Die Koordinaten für rechteckige Bereiche kann man ganz einfach zum Beispiel auf der OSM-Seite ermitteln. Auf der Webseite der Geofabrik befinden sich brauchbare Polygon-Dateien für einzelne Länder, aber teilweise auch für untergeordnete Verwaltungsbereiche wie Bundesländer oder Regierungsbezirke.

Die Methode mit den Polygon-Dateien wird auch hier verwendet.Es gibt für jedes Land mehrere Polygon-Dateien für rechteckige Bereiche und eine Datei .._track.poly, die ein Multipolygon rund um den E8-Track enthält. Warum dies so ist, wird erst klar, wenn man sich mit der Arbeitsweise des Renderers beschäftigt.

Ich habe lange, aber vergeblich nach einem geeigneten Tool zur Erstellung einer Poly-Datei gesucht. JOSM kennt ein solches Addon namens along_gpx, das die OSM-Daten in einer einstellbaren Distanz zu einem GPX-Track ausstanzt, aber leider streikt der OSM-Server, wenn man längere Trackumgebungen herunterladen möchte. Deshalb habe ich den Bereich um die Tracks mit GoogleEarth gezeichnet, als .kml abgespeichert und in Notepad++ die Datei kurzerhand umgeschrieben.

Die Polygon-Dateien werden in Osmconvert als Parameter (-B=nuernberg.poly) angegeben:
osmconvert germany.pbf -B=nuernberg.poly -o=nuernberg.osm
Der Bereich kann rechteckig, aber auch anders geformt sein, eben auch als Trackumgebung oder Bundesland oder Stadtgrenzen von Nürnberg.

Legt man ein Polygon sehr dicht an einen Track, ist der Bereich also sehr schmal, werden Wege und Multipolygone (zusammenhängende Flächen in OSM), die über die Grenzen des Polygons reichen, nicht berücksichtigt. Um dies zu verhindern, weist man Osmconvert mit der Option --complete... an, diese OSM-Daten mit einzubeziehen. Der vollständige Befehl sähe dann so aus:
osmconvert germany.pbf -B=nuernberg.poly --drop-author --complete-ways --complete-multipolygons -o=nuernberg.osm
Da der Gebrauch dieser Optionen sehr speicherintensiv sein kann, solle man ihn nur auf das Track-Polygon für die beiden höchsten Zoom-Stufen anwenden.

Um zu vermeiden, dass die ausgegebenen Dateien zu groß werden, bleibt bei Osmconvert das pbf-Dateiformar erhalten. Damit kann auch der Renderer gut umgehen. Eine Ausnahme machen die Daten für die beiden deutschen Webseiten. Die komplette OSM-Datei ist so groß, dass sie von einem 32-bit-System (und der Renderer ist ein 32-bit-Programm) nicht verarbeitet werden kann. Aus diesem Grund wird nicht der geamte Deutschland-Download der Geofabrik verwendet, sondern Ausschnitte der einzelnen Bundesländer oder Regierungsbezirke, die dann von Osmconvert zusammengesetzt werden. Dabei ist eine verübergehende Formatumwandlung in .o5m erfoderlich, da Osmconvert keine .pbf-Dateien zusammensetzen kann. Zum Abschluss dieses Vorgangs wird aber wieder eine .pbf-Datei gebildet, die all die einzelnen Teile enthält. Als Resultat der Arbeit mit Osmconvert hat man nun mehrere kleinere Datensätze erzeugt, die vom Renderer weiter verarbeitet werden können. Der Parameter --drop-author sorgt übrigens dafür, dass die für unsere Anwendung nicht erforderlichen Angaben zum Autor und zur Zeit der Erstellung der Daten im OSM-Datensatz nicht berücksichtigt werden. Dadurch wird der resultierende Datensatz etwas kleiner und die Rechnerzeit verkürzt.


SRTM: Höheninformationen von der NASA
In den OSM-Daten stecken keine Höheninformationen. Glücklicherweise stellen die NASA und auch die DLR Höhendaten zur Verfügung, die auf der Shuttle Radar Topography Mission im Jahre 2000 gesammelt wurden. Die Daten stehen in zwei verschiedenen Auflösungen von drei Bogensekunden (SRTM-3) und seit einiger Zeit auch von einer Bogensekunde (SRTM-1) bereit.

Bisher brauchte man sich nicht besonders um die Daten zu bemühen, denn der Renderer Maperitive war in der Lage, sie bei der Erstellung der Kartenkacheln auf Knopfdruck von der NASA abzurufen und hinzuzufügen. Dies ist nicht mehr möglich, weil die NASA (und auch die DLR) solchen anonymen Massendownload gesperrt hat. Man muss sich im EarthData-Netzwerk (kostenlos) registrieren und anmelden, was nicht so einfach zu automatisieren ist. Diese Plattform ist übrigens äußerst interessant und bietet weit mehr Informationen als nur Höhenlinien!

Es gibt einige andere Quellen, um die Höhendaten einzusammeln, aber ich habe keine gefunden, die die hochaufgelösten SRTM1-Daten für den Massendownload anbietet. Ich habe deshalb die relevanten Dateien gesammelt und auf meiner Webseite untergebracht, wovon das cmd-Programm natürlich Gebrauch macht. Diese Dateien im .hgt-Format, die jeweils 1 Grad x 1 Grad umfassen, heißen zum Beispiel "N53W001.SRTMGL1.hgt", wobei die genannten Geokoordinaten immer die linke untere Ecke bezeichnen. Für Versuchszwecke habe ich eine KML-Datei für Google Earth erstellt, in der die relevanten SRTM-Datenbereiche, die oben beschriebenen Polygon-Dateien und die E8-Route eingezeichnet ist.

Wenn man selber Polygone definiert, sollte man darauf achten dass sie stets innerhalb der zur Verfügung stehenden SRTM-Abdeckung liegen und dass man die Polygonkanten nicht genau auf den Längen- oder Breitengrad setzen soll, wenn auf der anderen Seite des Grades keine SRTM-Abdeckung gegeben ist. Statt dessen sollte man einen kleinen Abstand von zum Beispiel einer Bogensekunde einhalten. Der wahrscheinliche Grund: Windows hat mit Fließkommaberechnungen so seine Problemchen und verfälscht die Werte ein klein wenig, so dass es dann passieren kann, das man mit dem Polygion in den "SRTM-freien" Bereich rutscht. Das hätte negative Folgen, der Renderer würde abstürzen!


Der Renderer Maperitive
Programme, die die Rohdaten von OpenStreetMap in Kartenkacheln in einem Grafikformat (*.png) verwandeln, werden Renderer genannt. Die meisten Renderer sind ähnlich Kommandozeile-Tools für Linux, ich habe aber ein einigermaßen leicht bedienbares Windows-Programm gefunden, das sogar über eine grafische Benutzeroberfläche verfügt, einige "Bequemlichkeitsfeatures" bietet und zudem kostenlos ist.

Das englischsprachige Programm Maperitive wurde/wird von Igor Brejc entwickelt. Maperitive ist im Download der Offline-Website schon enthalten und muss (wie alle hier verwendeten Programme) nicht installiert werden. Das heißt, dass nach der Erzeugung der Offline-Website der Rechner keinerlei Spuren dieser Programm zurückbehält. Maperitive kann statt mit dem GUI auch per Kommandozeile betrieben werden, was die Batch-Datei auch so macht ist. Wenn man dem Renderer bei der Arbeit zusehen möchte, kann man in der .cmd-Datei das Kommando "Maperitive.Console.exe" einfach durch "Maperitive.exe" ersetzen.

Maperitive kennt zwei Arten der Einflussnahme auf den Prozess der Kachelerzeugung. Mit den "Commands" samt ihren Optionen steuert man, was Maperitive tut (Quelldateien auswählen, Dateipfade setzen, Tiles generieren und so weiter), die "Rendering Rules" entscheiden darüber wie das Kartenbild aussehen soll. Die "Commands" können in der Batch-Datei, aber auch in einer externen Textdatei angegeben werden, für die "Rules" muss eine Textdatei geschrieben (und mit einem "Command" eingebunden) werden. Hier ist als Rendering Rule der Mapnik-Stil von OSM vorgegeben (angereichert von Höhenlinien und Schummerung), der nur eine Änderung für die beiden höchsten Zoomstufen erfährt. Dabei wird der Eintrag "map-background-opacity : 1" auf "map-background-opacity : 0" geändert, was bewirkt, dass der Hintergrund der Kartenkacheln auf transparent gestellt wird und sich so bei sich überlappenden Kacheln zweier Datensätze keine unschönen Ränder ergeben.

Der (ein) Renderer kann die Kartenkacheln immer nur in einem rechteckigen Bereich erzeugen, wie sie praktischerweise schon von Osmconvert ausgeschnitten wurden. In der externen Textdatei werden zunächst alle rechteckigen Bereiche geladen und sukzessive mit Höhenlinien und Schummerung versehen. Man kann Maperitive so einstellen, dass die Höheninformationen (die ja über den rechteckigen bereeich hinausragen) quasi ausgestanzt werden. Setzt man anschließend mehrere rechteckige Bereiche zusammen, sind nur diese Bereiche mit Höhenlinien und Schummerung versehen, der Rest nicht.

Zwar werden die Kartenkacheln zwar für den gesamten durch die Rechtecke aufgespannten Bereich erzeugt, sie lassen sich aber in inhaltsleere (die also weder OSM-Daten noch Höheninformationen enthaltende) und informationstragende Kacheln allein aufgrund der Dateigröße filtern. Die inhaltsleeren werden verworfen, die informativen gespeichert. Auf diese Weise werden Kartenkacheln bis zur Zoomstufe 16 erzeugt.

Dieses Ausstanzen ist aber für ein Multipolygon nicht möglich. Es würden bei den höchsten Zoomstufe 17 und 18 Kartenkacheln für den gesamte rechteckigen Bereich erzeugt, den der Track aufspannt. Zwar wären die OSM-Daten nur in dem Trackbereich enthalten, aber die Höhenlinien/die Schummerung bei allen Kacheln im Rechteck. Eine Filterung aufgrund der Dateigröße wäre nicht mehr möglich. Aus diesem Grund werden in den beiden höchsten Zoomstufen, die mit dem Track-Polygon erzeugt werden, keine Höheninformationen verarbeitet.

Ich habe für das folgende Beispiel die südliche Hälfte von Irland gerendert und wurde mit einer Tile-Sammlung knapp 10 GB belohnt. Während der Download und die Modifikation der Webseite nur wenige Sekunden, der Download der Höheninformationen sowie der OSM-Kartendaten und das Ausschneiden mit Osmconvert wenige Minuten und das Rendern der Zoomstufen bis 16 nur wenige Stunden dauert, beansprucht das Rendern und (größtenteils) Verwerfen von abermillionen Tiles der Zoomstufen 17 und 18 mehrere Tage. Wie zu sehen, ist das Datenvolumen in den beiden höchsten Zoomstufen eher gering, der Rechner ist aber lange Zeit damit beschäftigt, inhaltsleere Tiles zu verwerfen. Die Verarbeitungszeit hängt nicht wesentlich von der Fläche des Track-Polygons ab, sondern stark davon, wie groß das durch den Track aufgespannte Rechteck ist.
to be continued...


ZoomTilesDatenvolumenRechnerzeit
2-9822,6 MB2 min
10-16430.000 8,2 GB2 h
1777.250414 MB12 h
18190.123920 MB38 h




  • Irland: 9,5 GB
  • England: GB
  • Holland: GB
  • Deutschland 1: 4,4 GB
  • Deutschland 2: 5,6 GB
  • Deutschland 3: 5,2 GB
  • Deutschland 4: 8,2 GB
  • Österreich: 4,2 GB
  • Slowakei: 7,8 GB
  • Polen: 1,9 GB
  • Ukraine: 5,3 GB
  • Rumänien Nord: 3,8 GB
  • Rumänien Ost: 7,0 GB
  • Rumänien Süd: 11,2 GB
  • Serbien: 4,4 GB
  • Bulgarien: 7,4 GB
  • Türkei: 4,5 GB

PopupFramedCloud
ein tiefer Einblick ins Layout

Ich war immer unzufrieden mit der Darstellung der Popups in der Karte, weil die Fotos im Portrait-Format in den Popups durch Scroll-Balken beschnitten wurden, obwohl dies offensichtlich gar nicht erforderlich war.

Ich habe bei der alten Version der Webseite einen „Workaround“ eingesetzt und die Höhe des Map-Divs um einige Pixel erhöht. 2016 habe ich der Site ein neues und responsives Gesicht gegeben und prompt tauchte das Problem erneut auf, als ich für große Viewports auch schöne große Fotos einsetzen wollte.

Ich habe das gesamte Internet durchgelesen und dabei einerseits festgestellt, dass etliche Leute mit dem gleichen Problem zu kämpfen haben und andererseits keiner eine befriedigende Lösung gefunden hat. Da ich mich als Javascript-Unwissender beim Relaunch notgedrungen doch mit JS auseinandersetzen musste (und nach der Trial&Error-Methode (viel trial, viel error!) irgendwie alles auch so hinbekommen habe, was ich wollte), habe ich also den Mut gefasst, um der Sache mit den ol-Scripts auf den Grund zu gehen.

Vorbereitungen

Natürlich würde ich kein Howto verfassen, wenn es mir nicht gelungen wäre. Vorab gesagt, es funktioniert nur, wenn man den kompletten Satz OpenLayers-Scripts zunächst lokal auf seinem Computer speichert und später, nachdem die Entwicklung abgeschlossen ist, kompiliert. Das erfordert schon etwas Arbeit, ist allerdings weder ehrenrührig noch technisches Teufelswerk, verbraucht nur wenig Speicher auf dem Server und ist zudem noch schneller, da beim Betrachten der Webseite keine Verbindung mehr zum ol-Server aufgenommen werden muss.

  1. Zuerst lädt man die aktuelle ol2-Master-Version von Github und entpackt selbige. Ein Blick in das Verzeichnis ol2-master zeigt unter anderem (was wir später noch brauchen werden) drei Ordner namens lib, img und theme. In lib steckt das OpenlLayers-Script, auf das sich der Verweis im Kopf der Webseite nun beziehen muss (statt auf das gleichnamige Script auf dem ol-Server). In diesem Script steht zunächst nur wenig mehr als die Pfade zu den OpenLayer-Scripts für alle Klassen im Ordner OpenLayers.

  2. Noch etwas muss heruntergeladen und installiert werden, nämlich der Python-Interpreter 2.7 (kann auch 3 sein). Python ist eine moderne, einfache Programmiersprache, die ein wenig an C, ein wenig an JavaScript erinnert. Keine Sorge, wir kommen ohne Programmierkenntnisse aus, wir benötigen am Ende nur den Interpreter, um mit dem Build-Programm aus dem ol2-Paket ein komprimiertes Openlayers-js zu erstellen. Das ist nicht besonders kompliziert und hat bei mir schon im zweiten Versuch geklappt.

  3. Als Hilfsmittel kann ein gutes Pixel-Grafikprogramm nicht schaden. Ich habe dazu Photoshop verwendet, es funktioniert natürlich auch mit beispielsweise dem kostenlosen GIMP (ich weiß nur nicht wie).

Aufbau der Framed-Popups

Schaut man sich ein beispielhaftes FramedCloud-Popup



im Entwicklerwerkzeug des Browsers (z.B. Inspector in Firefox) an, so sieht man, dass es im Div "OpenLayers_Feature_82_popup" definiert ist. Die Größe des gesamten Popups ist im Beispiel mit "width: 400px" und "height: 224px" angegeben.

Das Popup besteht aus sieben Div-Elementen:
  1. featurePopup_contentDiv:   mit dem Inhalt, den man selber in seinem Script in das Popup steckt

  2. featurePopup_close:   der Close-Box, dieses rote Abschaltknöpfchen, das oben rechts im Popup erscheint (wenn aktiviert).

  3. featurePopup_FrameDecorationDiv_0...4
Die FrameDecorationDivs setzen das Popup zusammen. In den Style-Angaben befinden sich jeweils die Größe des Divs (width, height) und der Abstand vom oben definierten Popup-Rand (left, right, top, bottom).

Der Inspector zeigt, welches Div für welchen Bereich des Popups zuständig ist.


Die unterschiedlichen Bereich sind nur notwendig, weil das Popup abgerundete Ecken besitzt. Jede Decoration ist für eine dieser runden Ecken verantwortlich, abgesehen von Decoration_4, die sich um die Nase kümmert.

Jedes Decoration-Div enhält immer der gleiche Grafik "cloud-popup-relative.png", in den Style-Angaben der Grafik sind aber (neben ihrer Größe von 736x1276 px) verschiedene Abstände zum linken und oberen Rand des Popups angegeben.

Der Bastelbogen

Diese gewöhnliche PNG-Datei stellt eine Art Bastelbogen dar, der durch die Offsets so verschoben (und durch die Eigenschaft overflow: hidden der Decoration-Divs quasi auf Maß zerschnibbelt) wird, dass er einen Rahmen inklusive Zeiger um das Content-Div erzeugt. So sieht die originale Datei cloud-popup-relative.png aus:



In der (nur hier) grün umrandeten Grafikdatei ist eine große weiße Fläche zu sehen und darunter vier weiße "Nasen" (engl. stem), die später in der Karte auf den Ortspunkt zeigen sollen. Die grünen Bereiche sind in Wirklichkeit transparent.

Die Offsets in jedem Decoration-Div so gewählt sind, dass die entsprechende runde Ecke (in Decoration_4 die Nase) an die richtige Stelle im Popup gerückt wird. Da sich ein Popup links und rechts, über und unter dem Ortspunkt eingeblendet werden kann, muss es auch vier Nasen geben, die allesamt unterschiedliche Offsets aufweisen.

Die Grafik cloud-popup-relative.png wird aber nicht nur von den Decorations-Divs hin- und hergeschoben, ihr kommt auch eine wichtige, ja entscheidende Rolle zu, was die maximale Größe des Popups betrifft. Es ist ja leicht einzusehen, dass das Popup nicht korrekt dagestellt werden würde, wenn die Grafik kleiner ist als der Inhalt des Popups.

Vergrößern der Grafikdatei

Erste Maßnahme ist also, die Grafik mit den originalen Abmessungen von 1276x736 px zu vergrößern. Es sollte kein Problem sein, mit einem Grafikprogramm die Größe des Bildes nach Wunsch anzupassen, nur sollte man wirklich pixelgenau arbeiten (anders als der Mensch, der die ursprüngliche Grafikdatei für oL entworfen hat).

Die Nasen sollten dabei an Ort und Stelle verbleiben und die runden Ecken bleibehalten werden. Ich habe einfach die Grafik in der Höhe zerschnitten und ein zusätzliches Stück eingefügt.



Wer sich gar nicht mit Grafikprogrammen auskennt, darf meine quadratische Vorlage (1276 x 1383 px inklusive unterer Rand mit den Nasen) von meiner Webseite abholen. Die Datei wird im oL-Ordner img gespeichert beziehungsweise ersetzt.

Wie groß die Grafikdatei letztendlich sein muss, hängt von der gewünschten Content-Größe ab (wobei man für die diverse Borders, Paddings und Margins noch einige Pixel hinzufügen muss), andererseits von dem Monitor beziehungsweise dem Browser-Fenster. Ich verwende auf meiner Webseite Fotos mit 800x800 px Breite beziehungsweise Höhe. Immerhin wird das Popup damit etwa halb so breit wie mein großer Monitor. Mit einer quadratischen Fläche lassen sich Fotos im Landscape- wie im Portrait-Format gleich gut einpassen.

Bei einem Portrait-Foto mit einer Höhe von 800px erreicht das Popup knapp 950px, was sich sogar auf meinem „kleinen“ Bildschirm (1280x1024px) ohne Scrollbalken darstellen lässt, wenn man den Browser im Vollbildmodus betreibt. Lange Rede, kurzer Sinn: Mach dir vorab Gedanken über die von dir gewünschte maximale Popupgröße und wie sie auf welcher Bildschirmgröße dargestellt werden kann!

Anpassen des FramedCloud.js

Was im Firefox-Inspektor an Abmessungen und Abständen zu lesen war, findet seine Entsprechung beziehungsweise seinen Ursprung im OpenLayers-Script FramedCloud.js, die unter lib\OpenLayers\Popup\ zu finden ist. Zu Beginn des Scripts wird in Zeile 46 in der Eigenschaft
46 imageSize: new OpenLayers.Size(1276, 736),
die Größe der Grafik cloud-popup-relative.png angegeben. Diese Werte muss man für die obige quadratische Grafik auf (1276,1383) ändern.

Unten im Script sind die minimale und die maximale Popup-Größe eingetragen:
196 minSize: new OpenLayers.Size(105, 10),
202 maxSize: new OpenLayers.Size(1200, 660),

Hier reicht es, die maximale Größe auf (1200,1200) zu ändern.





Den meisten Raum im Script nimmt die Eigenschaft positionBlock in Anspruch. Sie gelten für die Positionen, die das Popup relativ zum Ortspunkt einnehmen kann: oben links (tl), oben rechts (tr), unten links (bl) und unten rechts (br). Jede Position besitzt drei Parameter, nämlich
offset: Horizontaler und vertikaler Abstand der unteren linken Ecke Popups zum Ortspunkt
padding: Innerer Abstand des Popup-Divs zum Content-Div (links, unten, rechts, oben). Um Platz zu sparen, kann man das Padding etwas verringern.
blocks: Abmessungen,... der fünf Decoration-Divs (oben links, oben rechts, unten links, unten rechts und stem)
Jedes Decoration-Div ist dabei mit einem Satz (size, anchor und position) von Abmessungen beziehungsweise Abständen vertreten. Exemplarisch werfen wir einen Blick auf die Position "tr" rechts über dem Ortspunkt.
size(w,h) wird automatisch eingestellt
anchor Abstand der Grafik vom (linken, unteren, rechten, oberen) Rand des Decoration-Divs (left, bottom, right, top)
position pixel(x,y)

Bei position müssen die Werte für die modifizierte Grafik eingetragen werden. Die vertikale Position 1238px ergibt sich aus der Bildbreite von 1276px minus der Breite des transparenten Streifens rechts (17px) und minus der Breite einer runden Ecke (21px). Bei der Höhe 1275px ist es ähnlich, aber der transparente Streifen unten mit den Stems ist 87px hoch. Die runden Ecke á 21px muss ebenfalls von der Bildhöhe von 1383px abgezogen werden.

Stem-Höhe => Bildhöhe - Stemspitze Abstand vom unteren Rand Stem-Breite => Bildbreite - Stemspitze Abstand vom linken Rand

Zum Abschluss:
Kompilieren der OpenLayer-Scripts

Alles klappt lokal und auch auf dem lokalen Server, aber wenn man versuchsweise die ganze Webseite inklusive des modifizierten ol2-master-Pakets auf den Server des Providers lädt und die Webseite aufruft, wird man feststellen, dass zwar alles funktioniert, aber man der Webseite beim Aufbau quasi zusehen kann.

Der Grund ist, dass das ganze ol2-Paket bei jedem Seitenaufbau mit geladen wird und die Unzahl von Scripts die Leitung verstopft. Abhilfe schafft, wie eingangs erwähnt, das Kompilieren, die Beschränkung der für sein eigenes Script notwendigen Classes. Eine Anleitung in der ol2-Dokumentation gibt es dafür auch.

Kurz gesagt, durchforstet man sein eigenes Script nach allen eingesetzten Classes (alles, was „new OpenLayers.ClassName()“ heißt) und trägt die entsprechenden Scripts inklusive des Pfads in der Datei „full.cfg“ unter [include] ein. Bei mir sah die Datei „zweiterversuch“ so aus:

# This is the full build with all files:
# this includes the vector-related files
# like Renderers and Formats.

[first]
[last]

[include]
OpenLayers/Map.js
OpenLayers/Control/Navigation.js
OpenLayers/Control/PanZoom.js
OpenLayers/Control/LayerSwitcher.js
OpenLayers/Control/ScaleLine.js
OpenLayers/Control/MousePosition.js
OpenLayers/Control/Attribution.js
OpenLayers/BaseTypes/Bounds.js
OpenLayers/Projection.js
OpenLayers/Layer/OSM.js
OpenLayers/Layer.js
OpenLayers/Layer/Vector.js
OpenLayers/Renderer/SVG.js
OpenLayers/Renderer/Canvas.js
OpenLayers/Renderer/VML.js
OpenLayers/Renderer/Elements.js
OpenLayers/Strategy/Fixed.js
OpenLayers/Protocol/HTTP.js
OpenLayers/Format/GPX.js
OpenLayers/Format/KML.js
OpenLayers/Control/SelectFeature.js
OpenLayers/Popup/Anchored.js
OpenLayers/Popup/FramedCloud.js
OpenLayers/BaseTypes/LonLat.js

[exclude]
Firebug
OpenLayers.js
OpenLayers/Lang
deprecated.js


Man beachte die vier Renderer, die immer dann aufgenommen werden müssen, wenn man einen Vector-Layer verwendet. Später sind bei mir übrigens noch die Klassen für die Geolokalisierung hinzugekommen.

Und nun passiert es: Man geht im Windows-Explorer in den build-Ordner, trägt in der Adresszeile den Pfad zu diesem Ordner ein (in W7 klickt man dazu einfach auf das kleine Ordner-Symbol links in der Zeile), fügt \build.py zweiterversuch an und drückt auf Enter. In einer aufpoppenden Konsole kann man kurz beobachten, wie das Python-Programm arbeitet, dann erscheint wie von Geisterhand die neue Datei OpenLayers.js (Dateigröße ca. 340 kB) in dem Ordner.

Diese Datei verschiebt man an eine beliebige Stelle (am besten dort, wo auch das eigene Script liegt), zusammen mit den Ordnern theme und img. Diese Ordnerstruktur wird von oL vorgegeben. Also so zum Beispiel:
meinScript.js. OpenStreetMap.js OpenLayers.js theme/... img/...

Wahrscheinlich muss man in der HTML-Datei noch den Verweis zum Script richtigstellen. In der Anleitung werden noch andere Maßnahmen genannt, um das ol2-Paket weiter kleinzukriegen. Aber das ist ein anderes Thema.