Mapproxy - das Chamäleon unter den Tile Servern

Unsere Firma wurde vor kurzem von einem französischen Kunden beauftragt, einige kleine funktionale Verbesserungen an mapproxy vorzunehmen. Wir arbeiten eher selten mit dieser Software, konnten dem Kunden aber in kurzer Zeit eine zufriedenstellende Lösung anbieten.

Die Wahl des Tools

Geschieht dies nicht häufig? Man will für ein neues Projekt einen Tile Server installieren und muss sich für eine der verfügbaren Möglichkeiten entscheiden. Meistens fällt die Wahl auf die Software, mit der wir am besten vertraut sind, und man lebt in ständiger Furcht, dass diese Lieblingssoftware irgendwann nicht mehr aktualisiert wird.

Wollen wir ein paar Optionen vergleichen, mit denen wir bei camptocamp häufig arbeiten:

Mapcache: funktioniert bestens mit mapserver und ist der de-facto Standard, guter support, viele features, zuverlässig
GeoWebCache (als Teil von GeoServer, oder als stand-alone): ein weiteres “old-school” tool mit begrenzten Cache Möglichkeiten
ArcGIS: sehr umfangreiche server software mit allen erdenklichen Varianten, aber keine freie Software, wir arbeiten nun mal im OpenSource Bereich
QGIS server + cache Plugin: vielseitig und benutzerfreundlich, aber sehr viel Overhead

Vorhang auf für mapproxy, einen Tile Server in python mit verschiedenen Backends.

	Backends für Quelldaten	Backends für den Cache
Verfügbarkeit	WMS sources (1.0.0–1.3.0), WMTS/TMS sources, Mapserver and Mapnik configurations, any TileCache, Google Maps or Bing compatible source, ArcGIS REST servers and compact cache files	Filesystem, MBTiles/SQLite, ArcGIS Compact Cache, S3, Redis, Riak, CouchDB

Wer schon mal versucht hat, den Source Code von mapserver anzupassen, hat sich einen großen Pott Kaffee verdient. Dieser extrem optimierte C code lädt zu einer Reise in die Vergangenheit ein und ich hatte immer große Angst, mit einer kleinen Code Änderung Alles kaputt zu machen.

Dagegen war die Programmierung in mapproxy ein ziemliches Vergnügen. Die Software ist komplett in python geschrieben, man verfügt über einen sehr lesbaren und wartungsfreundlichen Quellcode. Die Module sind gut strukturiert und die Tests decken die Funktionen sehr gut ab.

Aufbau des Tile Cache

Zweck

Ein Tile Cache befindet sich zwischen einer Quelle von Geodaten und den Endnutzern.

Dem Server für Geodaten wird Last abgenommen
Der Server muss nicht mehrmals die gleichen Daten erstellen
Komplexere Aufgaben wie Projizierung in ein anderes Koordinatensystem oder Bereitstellung von Daten in mehreren verschiedenen CRS; auch Bildbearbeitung wie Hinzufügen von Wasserzeichen kann gemacht werden

Die Software führt hauptsächlich 2 Aufgaben durch: Vorausberechnung (seeding) und Bereitstellung (serving)

Beim Seeding werden definierte Daten vom Geodaten-Server angefordert und in optimaler Weise als Cache zwischengespeichert
- Einerseits muss ein Basisdatensatz generiert werden, andererseits ein bestehender Datensatz aktualisiert werden
- Seeding kann einmalig manuell oder regelmäßig automatisch ausgeführt werden.
Beim Serving werden Anfragen der Endnutzer beantwortet und die Daten gemäß dem gewählten Protokoll aus dem Cache geholt. Daten, welche sich (noch) nicht im Cache befinden, können optional direkt abgefragt und gespeichert werden.

Konfiguration

Mapproxy lädt zwei Setup-Dateien:

mapproxy.yaml
seed.yaml

In diesen Konfigurationsdateien wird das Verhalten des Cache festgelegt:

Datenquellen
Gittergröße
Cache Details (Art und Speicherort, lokal oder im Netzwerk)
Gültigkeitsdauer der Cachedaten
Default Werte (bei fehlenden Kacheldaten)
etc.

Leistungsoptimierung

Die Leistung des mapproxy servers kann durch Installation in einem robusten Web Server gesteuert werden (apache + mod_wsgi, NGINX, gunicorn, etc.)

Ein vorberechneter Datensatz kann auch als Kachel-Pyramide lokal von einer front-end Anwendung geladen werden, oder aber als statische Dateien über einen leistungsstarken File Server direkt bereitgestellt werden.

Einzelheiten der Code-Anpassung

Wir wollten die Verwaltung der Cache Daten etwas feiner gestalten, und Optionen hinzufügen für abgelaufene Daten und Aktualisierung der Kacheln.

Die wichtigsten Punkte im Projekt waren:

Reduzierung der Belastung der Server für die Original-Daten
Verringerung des Speicherbedarfs für Cache-Daten
Umgang mit unzuverlässigen Upstream Servern

Aufbau des Quellcodes

Der Code ist modular aufgebaut, jeder wichtige Baustein hat eine virtuelle Basisklasse, in der einige gemeinsame Funktionen definiert sind. Die abgeleiteten Klassen implementieren dann die spezielle Funktionsweise (z.B.: Basis = MapLayer; Abgeleitet in [WMSSource, TiledSource, ArcGISSource, etc.])

Die Hauptbestandteile sind:

Cache Verwaltung
Bezug der Quelldaten
Veröffentlichte Dienste des Servers
Seeding
Etc.

Dank dieser modularen Struktur ist es recht einfach, eine neue Option aus der Konfiguration an die verschiedenen funktionellen Klassen weiterzuleiten.

Neue Optionen

Update abgelaufener Kacheln bei aktivem Server-Betrieb
Verbesserungen des Seeding
1. Aktualisierung ausschließlich bereits gecachter Kacheln (falls der Cache nur bei Anfragen der Endnutzer erstellt wird)
2. Kein Löschen abgelaufener Kacheln, solange der Quellserver nicht erreichbar ist

Diese sehr speziellen Verbesserungen erforderten ein tiefes Eintauchen in den Quellcode. Hierbei stellte sich heraus, dass der Code äußerst robust aufgebaut ist und nur punktuelle Codeanpassungen notwendig waren, es gab keinerlei Bedarf für eine größere Refaktorierung.

Punkt 1 konnte sehr punktuell umgesetzt werden:

Anpassung der Konfigurationslogik
Änderung im internen Dienst, der Kacheln aus dem Cache bezieht
Kleinere Änderungen für Fehlverhalten (leere Kacheln)

https://github.com/mapproxy/mapproxy/pull/518

Punkt 2 erforderte nur die Weiterleitung einiger bereits bestehender Parameter, so dass man die Standardwerte aus der Kommandozeile dem persönlichen Bedarf anpassen kann.

https://github.com/mapproxy/mapproxy/pull/515

Ohne weiter ins Detail zu gehen, war bei dieser Arbeit klar zu erkennen, wie leicht Codeanpassungen in sehr verschiedenen Modulen ohne Nebeneffekt auf bestehende Funktionen möglich waren.

Zusammenfassung

Der Cache in mapproxy kann bereits äußerst fein gesteuert werden. Falls aber die bestehenden Einstellungen nicht ausreichen, hat es sich erwiesen, dass zusätzliche Einstellungen leicht neu hinzu programmiert werden können.

Mapproxy ist die Software der Wahl, wenn in einem Projekt sehr feine Einstellungen des Cache notwendig sind und wenn man gerne am internen Verhalten des Servers schraubt. Die Entwickler von mapproxy sind ebenfalls offen für Weiterentwicklungen, auf diese Weise können die neuen Funktionen vielen Benutzern zur Verfügung gestellt werden.

Mapproxy wird daher sicher zu einem festen Bestandteil der Tools, welche von camptocamp genutzt und an Kunden weiterempfohlen werden. Die Arbeit an mapproxy hat wirklich Spaß gemacht.

Kurz gesagt: sehr empfehlenswert!