Tile Server: Fertige OSM Daten aus dem Netz nutzen
Es ist eine alte Forderung vieler Nutzer von GNavigia, dass das Programm Karten so darstellen können sollte, wie es Google- oder Bing-Maps tun. Das Problem mit diesen Kartenservices ist, dass die Nutzung stark eingeschränkt ist, dass man insbesondere Ärger bekommen kann, wenn man davon abgeleitete Karten auf der Homepage veröffentlicht. Daher wird es diesen Kartenhintergrund in diesem Programm nicht geben, zumindest nicht von mir programmiert. Das könnten Sie selber tun, da die Hintergrundbilder auf definierte Art und Weise vom Programm entgegengenommen werden, wie auf anderen Seiten dieser Dokumentation hinlänglich beschrieben steht.
Zwar sehe ich ein, dass die meisten Vorschläge meinerseits, wie man das Programm mit einem hübschen Hintergrundbild versieht, relativ exotisch
sind, aber die WMS-Services liegen ja nun nicht weit von einer solchen Lösung entfernt. Das gilt umso mehr,
seit sich das Bundesamt für Kartografie und Geodäsie (BKG) als Diensteanbieter eingeschaltet hat.
Um die ansprechende Karte des BKG nutzen zu können, haken Sie im Dialog Auswahl der OSM-Layer die Karte mit der ID 900
an. (Für die Darstellung der Schummerung in großen Maßstäben müssen Sie ID 8080 zuschalten. Wir haben aufgeschrieben,
wie Sie frei zugängliche EU-DEM-Daten in das dazu benötigte SRTM-Format umwandeln.)
Wenn man aufmerksam die Dokumentation liest, kommt man auch mit WMS-Services mit vertretbarem Aufwand zum Ziel. Ich konnte mich trotzdem (und/oder gerade deshalb) bisher nicht dazu durchringen, die im Netz verfügbaren OSM-Daten, die bereits fertig gezeichnet sind und in Form von Kacheln abgerufen werden können, als Kartengrundlage zu verwenden. Das hat Gründe, die auch heute noch gelten. Fertige Kacheln (engl. Tiles), die von sogenannten Tile Servern geliefert werden,
- liegen stets in einem unrunden Maßstab vor,
- haben eine von UTM abweichende Projektion,
- können nur entlang von Längen- und Breitengraden abgefragt werden und
- erzeugen einen hohen Datendurchsatz für die beteiligten Server.
Tatsächlich begrenzt der zweite Punkt die Einsatzmöglichkeiten, insbesondere den sinnvoll nutzbaren Maßstabsbereich. Andererseits sind die Kacheln von guter Qualität und ergeben einen ansprechenden Duktus, sodass ich mich mit der Frage beschäftigt habe, wie man die Kacheln für nutzbar machen kann. Das Ergebnis ist der TileServerBackgroundProvider, ein sperriger Name zwar, aber ein durchaus brauchbarer Ansatz, wie die Bildschirmfotos auf dieser Seite beweisen werden.
OSM: Features des Tile Server Clients
Damit alles ein bisschen einfacher wird, fast so wie ein Zugriff auf die bekannten Kartendienste, andererseits aber auch den runden Maßstab und die ´ aktuell verwendete UTM-Abbildung beibehalten zu können, sowie der Bitte der OSM-Gemeinde nachzukommen, das Datenaufkommen gering zu halten, habe ich die folgenden Punkte zum Ausgangspunkt der Entwicklung gemacht. Danach soll für den Tile Server Client (TileServerBackgroundProvider) gelten:
- Der Tile Server kann nur mit Cache (Zwischenspeicher) betrieben werden,
- Der Maßstabsbereich soll eine Entzerrung der Karte auf die UTM-Abbildung zulassen,
- Der Maßstab soll von vorgegeben werden, nicht von den Kacheln,
- Eine beliebige Anzahl von Overlays muss erlaubt sein, um die Möglichkeiten der OSM-Server bestmöglich zu nutzen.
Datenzugriffe minimieren
Wegen des enormen Datentransfers verwundert es nicht, wenn die OSM-Gemeinde
darauf hinweist, dass keine flächendeckenden Downloads erwünscht sind. Es kann passieren, dass man bei zu großem Datenaufkommen im Download
gebremst und schließlich komplett von der Lieferung ausgeschlossen wird. Wegen der ungeklärten Frage übermäßiger Nutzung sendet
das Programm eine Kennung, die eindeutig als User-Agent identifiziert.
Eine OSM-TileServer-Kachel ist 256x256 Pixel groß und liegt, verlustfrei komprimiert, als PNG-Datei vor. Die erste Kachel liegt in der Zoomstufe 0. Sie bildet die ganze Welt ab. Ich habe diese Kachel einmal extrahiert. Sie ist nur 23KB groß. Danach wird die Kachel in Zoomstufe 1 in 4 Teile geteilt, die 2. Stufe hat 16 Kacheln, die 3. bereits 64 und die 18. 68719476736.
Das nachfolgende Bild, das die Halbinsel von Quibéron an der französischen Bretagneküste zeigt, gehört zur Stufe 12. Schauen Sie sich unbedint denselben Ausschnitt im BGK-Duktus (mit ID=8080 Schummerung) an! Nicht alle Server, die Sie im Laufe dieser Seite noch kennenlernen werden, verdichten die Daten bis zur Stufe 18, die eine ordentliche Darstellung im Maßstab 1:1000 erlaubt. Für die Schummerung (neudeutsch hill shading), die meist bis 15 reicht, ist darüber hinaus kein Gewinn an Informationsgehalt mehr möglich. Die eindrucksvolle räumliche Wirkung ist dann nicht mehr erzielbar. Wenn Sie mit Daten bearbeiten, werden Sie immer wieder scrollen und den Maßstab ändern, so oft, dass es illusionistisch wäre, eine moderate Menge an Datenzugriffen anzunehmen. Daher sind im Programm Maßnahmen implementiert, die die Zugriffe reduzieren sollen. Die eine gleicht einem Browser-Cache und die andere hindert Sie daran, das Caching zu umgehen: Es gibt keine Bilder ohne Cache! Allerdings können Sie ab Version 3.8 weiterarbeiten: Das Hintergrundbild wird asynchron geladen.
Die asynchrone Anforderung betrifft immer das ganze Bild. Anders als im Browser werden die Kacheln synchron geladen,
zu einem Bild zusammengesetzt und dieses dann zurückgegeben, weshalb Sie bei vielen neuen Kacheln zwar weiterarbeiten können, aber ggf. erst einmal
ohne Hintergrundbild. Erst wenn sich die Kacheln im Cache befinden, ist das Bild ohne merkliche zusätzliche Verzögerung da. Zudem können Sie
offline arbeiten, auch wenn dann ggf. einige zuvor nicht abgefragte Kacheln fehlen. bietet keine Möglichkeit,
Kacheln für die spätere Nutzung automatisiert abzufragen. Das ist so gewollt. Wenn Sie in einem bestimmten Maßstab Kacheln nutzen wollen,
dann müssen Sie halt von Hand das Gebiet abwandern.
Der Cache und wie er funktioniert
Das Caching funktioniert ganz einfach. Mit dem Programm zum Abrufen der Kacheln wird eine Konfigurationsdatei mitgeliefert, die Sie bearbeiten können. Darin kann das Verzeichnis angeben werden, das den Cache aufnimmt. Dieser Eintrag wird aber bei einer neuen Installation gelöscht. Daher hat die Setzung der Variablen «GNAVIGIA_GTS_CACHE» im Environment (wie setzen?) absoluten Vorrang:
GNAVIGIA_GTS_CACHE=C:\Cache\GTS
Sie können ab Version 3.17 optional auch den gewünschten Festplattenspeicherplatz angeben mit:GNAVIGIA_GTS_CACHESIZE=2000MB
Sie können die Angabe «MB» weglassen, aber das ist dann schon sehr cool und außerdem schlecht lesbar. Wenn Sie weder dort noch in der Datei einen Eintrag machen, wird der Cache im %TEMP% oder %TMP% Verzeichnis angelegt. Aber das ist unbefriedigend. Der Tipp des Tages: Setzen Sie ein Verzeichnis für alle Benutzer! Dann kann jeder, der dasselbe Gebiet bearbeitet oder betrachtet, auf die Daten zugreifen, was geringeren Traffic und kürzere Antwortzeiten mit sich bringt. Ab Version 4.4.2 können Sie statt der Größe auch einen Stern (*) angeben, dann unterbleibt der Test auf Größe und es werden keine Daten mehr gelöscht. Ab Version 5.0 ist der Stern Standard. Ohne Angabe einer Begrenzung wächst der Cache unbegrenzt an.
Für das Neuladen kaputter Kacheln ist aber auch gesorgt. So hatte ein besonders eifriger Mitarbeiter des OSM-Projekts einen Rechner so falsch eingestellt, dass die Beschriftung keine Umlaute enthielt sondern Fragezeichen. Besonders Frankreich war von dieser Misere betroffen. Manchmal werden einzelne Kacheln auch einfach nur schwarz ausgeworfen, sodass sie völlig unbrauchbar sind. Für diesen Fall gibt es das Nachladen per Klick in die Statuszeile, genauer gesagt mit «Strg»+Klick auf «TileServer-Info».
Pro Server wird ein Verzeichnis angelegt, damit man nicht auf die falschen Daten zugreift. Pro Verzeichnis wurden früher maximal 1000 Unterverzeichnisse angelegt, die durch einen vom Betriebssystem bereitgestellten Hashalgorithmus bestimmt wurden. Wechselte man das Verzeichnis auf ein anderes System, also von Windows 7 auf 8, so konnte der Hash ggf. ein anderer und damit im herkömmlichen Sinn ungültig sein. Man merkte das daran, dass Gebiete, die zuvor immer gecached wurden, signifikant mehr Darstellungszeit erforderten. Dann blieb nur das Löschen des Caches.
Heute werden die Verzeichnisse so angelegt, wie sie auch auf den OSM-Servern angelegt werden. Der alte Cache ist aber noch durchaus brauchbar. Er wird durchsucht, sobald im neuen Cache nichts gefunden wird. Eine gefundene Datei wird in den neuen Cache verschoben. Da diese Operationen unterhalb der Verzeichnisebene der Servernummern ablaufen, ist der Benutzer nicht davon betroffen. Nur die Verschiebeaktionen brauchen ein klein wenig länger, was man wegen der wenigen Dateien aber eher nicht bemerkt. Im Laufe der Zeit wird, vor allem bei einem in der Größe begrenzten Cache, der alte Cache nach und nach geleert.
Die Namen der zuvor erwähnten «pro Server»-Verzeichnisse sind vierstellige Zahlen. Sie werden aus dem gnav-Attribut der Map-Knoten der Konfigurationsdatei ermittelt, die daher eindeutig sein müssen und für eigene Einträge den Bereich 9xxx vorsehen. In diese Datei kann, Schreibrechte vorausgesetzt, jeder Tile Server eingetragen werden. Im Hauptprogramm öffnet man das Menü Ansicht und wählt Darstellung der Layer konfigurieren aus. Der nachfolgende Dialog zeigt die verfügbaren Karten an, die in der Konfiguration hinterlegt wurden. Dabei wird zwischen Basiskarten und Overlays unterschieden. Von den Basiskarten kann genau eine Karte angezeigt werden, in der Liste der Overlays ist eine Mehrfachauswahl möglich. So kann man thematische Karten, z. B. Rad- oder Reitweitwanderwege über die Schummerung legen. Ein Bemerkungsabschnitt ist optional. Er kann dazu benutzt werden, Erläuterungen oder auch Nutzungsbedingungen der jeweiligen Karte anzuzeigen. Der Knoten TileServer/Zoom begrenzt den Zugriff auf bestimmte Zoomstufen. Eine Schummerung macht für die Stufen 16 bis 18 keinen Sinn und würde tausende nicht existenter Kacheln abrufen. Das ärgert Sie und den Anbieter. Das muss nicht sein!
Neu und sicherlich noch verbesserungsfähig ist der Algorithmus zum Aufräumen älterer Dateien. Das Alter wird beim Programmstart bestimmt
und das, zumindest in der aktuellen TileServer-Version V2 oder ab , innerhalb von 5 Tagen nur ein Mal.
Dabei werden die Dateien nach Datum aufsteigend sortiert. Innerhalb eines Tages ist die Löschreihenfolge willkührlich:
- Wenn eine bestimmte Menge an Daten auf der Festplatte abgelegt wurde, wird geprüft, wann Dateien zuletzt benutzt wurden. Dazu wird das Änderungsdatum der Datei im Moment der Anfrage auf das aktuelle Datum gesetzt. Daher kann es dazu kommen, dass der Cache erscheint, als wären die meisten Dateien neu, was aber nicht der Fall sein muss.
- Karten, für die keep ungleich 0 gesetzt wird, werden nicht gelöscht. Dadurch kann man sinnloses Nachladen verhindern, wenn sich die Kacheln nicht ändern. Die SRTM Höhendaten, die der Schummerung zugrunde liegen, sind ein gutes Beispiel für fortwährende Aktualität. Der Parameter keep kann daher an der Benutzeroberfläche auch nicht nicht geändert werden.
- Wenn eine Kachel im Sinne des Erzeugungsdatums älter ist als ein vorgegebener Zeitpunkt (Parameter AgedOut), soll sie in dem Moment neu angefordert werden, da sie benötigt wird. So bleiben auch veraltete Kacheln für die Offline-Nutzung erhalten.
Der Dialog zur Auswahl der OSM-Layer zeigt aber auch statistische Daten. Die aktuelle Anzahl von Kacheln wird für die Beurteilung des Status herangezogen, die Geamtzahl ist eher etwas für jene Gestalten, die wissen möchten, wie viele Kacheln sie seit der Installation des Programms abgerufen haben. Aber auch ich finde es interessant, wie viele Zugriffe nicht über die OSM-Server gelaufen sind. Es gibt zwar dafür keine Orden, aber es könnte passieren, dass freie Dienste am Ende ganz abgeschaltet werden, weil Traffic halt immer Geld kostet! Und wenn Sie gerade keine Onlineverbindung haben, werden Sie den Cache über alles schätzen lernen. Wie Sie sich die aktuell im Cache befindlichen Kacheln anzeigen lassen können, ist weiter unten im Text beschrieben.
Wenn Sie versuchen, den Cache auszutricksen, werden Sie wenig Spaß haben, denn der Hintergrundserver registriert die
Zugriffe auf den Cache und die Anzahl der zurückgelieferten Kacheln. Wenn Sie 500 Kacheln abgerufen haben, ohne dass der Cache einen erfolgreichen Zugriff
registriert 
hat, werden sie eine Meldung sehen, die Ihnen erklärt, dass Sie nun keine weiteren Kacheln mehr abrufen können. Und
tatsächlich schaltet der Server in den Offline-Modus, aus dem es kein entrinnen gibt. Speichern Sie die Datei und starten Sie neu. Wie konnte es dazu kommen?
Nun, das Programm sucht Kacheln zunächst im Cache und greift dann auf den OSM-Server zu. Danach vergleicht es, wenn mindestens 500 Kacheln abgerufen wurden,
das Verhältnis von angeforderten zu aus dem Cache erhaltenen Kacheln. Ist dieses größer als 10, bricht das Programm ab. Der danach auf Offline
eingestellte Zugriff liefert nur noch Kacheln aus dem Cache und nicht mehr vom Server. Daher sehen Sie vielleicht immer noch Bilder, aber nur noch die, die der
Cache enthält. Damit sich Ihre Verwunderung in Grenzen hält, wird ein Offline-Status in der Statuszeile signalisiert.
Sie haben zudem immer eine Übersicht über das aktuelle Verhalten des Programms, denn die drei zurzeit möglichen Quellen für Kacheln werden zusammen mit der Zoomstufe und der Bezeichnung GTS in der Statuszeile dargestellt. Allein der lokale Zugriff mit selbst erstellten Kacheln dürfte eher etwas für Experten sein, zumal die Stufe 14 für Deutschland etwa 450000 Kacheln erfordert.
Im Prinzip ist der Faktor 10 für das Verhältnis gut bemessen, denn wenn nur 100 Kacheln aus dem Cache kommen können Sie 1000 vom
Server abrufen, bei 500 5000 und so weiter. Es gibt nur zwei Situationen, die aus dem Ruder laufen:
- Sie haben den Cache ausgeschaltet.
- Sie haben eine Basiskarte und mehrere Overlays geladen, haben einen Full-HD-Bildschirm, betreiben das Programm im Vollbildmodus (was ich auch immer tue) und scrollen direkt nach dem Start mehrere Zoomstufen durch. Dabei werden pro Stufe und Kartenwerk etwa 30 Kacheln abgerufen.
Probleme mit der Projektion
Die Projektionsunterschiede zwischen UMT32/33 (EPSG:25832/33) und EPSG:3857 (historisch EPSG:900913), der Projektion, die den Kacheln zugrunde liegt, sind schon in mittleren Breiten relativ groß. Hintergrund ist, dass die Erde zwar nicht, wie oft behauptet, als Kugel gesehen wird, aber die Tatsache, dass man versucht, die Längengrade zu parallelisieren, führt auf zu den Polen hin ansteigende Maßstabsfaktoren. Daher passen die auf dem Ellipsoid berechneten UTM-Koordinaten, zurückgerechnet in Länge und Breite, nicht zu den Positionen auf den Kacheln, die nominell dieselbe Länge und Breite besitzen. Dieser Unterschied führt zu Verzerrungen, deren Zusammenhänge von der OpenLayers-Gemeinde recht ordentlich erklärt werden, wenn auch in englischer Sprache. Seit Version 4.3 werden die Kacheln so gut entzerrt, dass man praktisch ganz Europa in UTM-Koordinaten darstellen kann, wobei man dann eine feste Zone angeben muss! Das grafische Ergebnis ist überzeugend und bis in die großen Maßstäbe hinein, wie sie bei der Visualisiserung von Skigebieten auftreten, erstmals vollumfänglich gebrauchbar, da jede Kachel individuell entzerrt wird.
Transformation der Koordinaten nach EPSG:3857
Die Projektionsunterschiede lassen sich wegen der mit der geografischen Breite schnell zunehmenden Maßstabsänderung allerdings nur bis zu einem gewissen Grad durch
Entzerrung ausgleichen. Deshalb wurde für die Möglichkeit geschaffen, die Koordinaten auf ein beliebiges Koordinatensystem
zu beziehen, de facto ist zurzeit aber nur EPSG:3857 verfügbar (früher und inoffiziell als EPSG:900913 bezeichnet). Dadurch passen GPS-Daten und Hintergrundbild praktisch verzerrungsfrei zusammen, wie 
das Bild von der Radtour zum Nordkapp eindrucksvoll zeigt. Um das Koordinatensystem umzuschalten wählen Sie aus dem
Menü Extras/Koordinatensystem ändern und dann im Dialog den Eintrag EPSG:3857.
Dass man nach dem Bestätigen mit OK eine Warnung sieht, die darauf hinweist, dass ein Undo (Rückgängig) nach der
Transformation nicht mehr möglich sei, liegt daran, dass das Programm in rechtwinkligen Koordinaten arbeitet und erst zum Schluss oder bei Bedarf in das System
geografischer Koordinaten transformiert. Sind noch keine Daten geladen, sieht man auch keine Warnung.
Einen wichtigen Hinweis kann ich heute streichen: Wenn Sie zwischen UTM und EPSG:3857 umschalten, müssen Sie nicht mehr unbedingt die Hintergrundserver neu auswählen. Die allermeisten WMS-Dienste und auch der ursprünglich nur für UTM ausgelegte OSM-Backgroundprovider können heute mit EPSG:3857 umgehen. Mit Version 5.0 ist diese Funktionalität zugesichert, es sei denn, der WMS-Dienst unterstützt das Koordinatensystem nicht.
Kacheln im Cache verfolgen - Ein Dienst für Koordinaten, die in EPSG:3857 vorliegen
Wenn
Sie das Koordinatensystem auf EPSG:3857 umgeschaltet haben, können Sie sich grafisch anzeigen lassen,
welche Kacheln im Cache liegen. Dazu müssen Sie zwingend unter Extras/Koordinatensystem ändern
auf das Koordinatensystem der Kacheln umschalten, falls es nicht aktiv sein sollte. Danach können Sie im Dialog zur Auswahl der OSM-Layer
im Gruppenfeld Zeige für EPSG:3857 die Option Cache
Stufe X aktivieren. Wird ein UTM-Koordinatensystem benutzt, sind die Einstellungen wirkungslos.
Für alle Stufen, im Beispiel Stufe 11, die von der Zahl her kleiner oder gleich der Stufe sind, die beobachtet werden soll, wird die ausgewählte Stufe mit einer transparenten, roten Fläche überdeckt, deren Transparenzgrad stufenlos zwischen 0 und 95 eingestellt werden kann. Allerdings müssen dafür alle Kacheln im Bereich der Anzeige untersucht werden, was auf langsamen Rechnern sehr schnell langweilig werden kann. Daher gibt es einen Grenzwert von zurzeit 100.000, der besagt, dass die Untersuchung unterbleibt, wenn mehr Kacheln zu untersuchen wären. Je nach Geschwindigkeit der Festplatte kann die Prüfung 2 bis 10 Sekunden dauern. SSD Festplatten sind da sicher etwas schneller.
Nun verstehen Sie vielleicht auch die Einschränkung auf das Koordinatensystem, für das die Kacheln erzeugt werden. Sie wollen nicht wirklich darauf warten, dass tausende kleiner Kacheln individuell entzerrt werden!
Gitternetzlinien nach UTM und mittlerer Maßstab der Projektion
Eine Wanderung in Nordschottland (1980, mittlere geogr. Breite 56°30'), ausgewertet über die Längenberechnung als Objekt, zeigt im EPSG:3857 eine Strecke von 248 km an, während diese in UTM 136 km lang ist. Der Maßstabsfaktor, der dem UTM-System zugrunde liegt, wirkt sich im Mittelmeridian mit 40 cm/km aus, beim aktuellen Abstand vom Mittelmeridian ist der Fehler nur halb so groß. Daher kann man 136 km als gegeben ansehen. Daraus folgt im Umkehrschluss, dass die Längenangaben im System EPSG:3857 korrigiert werden müssen, bevor sie zur Anzeige gebracht werden. berichtigt die aus Koordinaten berechneten Strecken daher jeweils mit dem Cosinus Hyperbolicus der mittleren geografischen Breite und erzielt damit ein nur noch um 200 Meter abweichendes Ergebnis. Diese Differenz ist zu vernachlässigen. Ebenso werden, sofern eingeschaltet, die Gitternetzlinien auf das UTM-System in Bildmitte bezogen da die Zahlenwerte der EPSG:3857-Koordinaten ohne praktische Bedeutung sind.
Feste Maßstäbe gibt es in einem EPSG:3857-Koordinatensystem nicht, vielmehr variiert die Maßstabszahl sehr stark mit der Position innerhalb des Bildes. Daher ist es sinnvoll, den Maßstab auf die mittlere geografische Breite zu beziehen, was dann auch für die Darstellung des Maßstablineals gilt. Dabei tritt ein Effekt auf, der zunächst für Verwunderung sorgen mag: Hat man im Verwaltungsfenster unter Kartendarstellung die Option Maßstabszahl gerundet eingeschaltet, liefert das Ändern des Maßstabs mittels Mausrad einen runden Zahlenwert im Bild. Verschiebt man dann aber das Bild um einen geringen Betrag in Nord-Süd-Richtung, wird die Maßstabszahl unrund, weil sie auf die nun veränderte Bildmitte bezogen wird. Daraus folgt, dass, wer dann immer noch einen runden Wert sehen will, das Mausrad noch einmal in beiden Richtungen um eine Raste drehen muss, damit der Maßstab gerundet, registriert und das Bild neu angefordert wird. Wie immer vergehen 3-4 Sekunden, bevor das Bild aufgefrischt wird.
