[PostNAS] ALKIS-WMS cachen ueber MapProxy
"Jäger, Frank (KRZ)"
F.Jaeger at KRZ.DE
Mon Sep 19 06:21:32 EDT 2011
Hallo,
der ALKIS-WMS ist wegen zahlreicher Tabellen/Layer nicht der schnellste. Allein der Layer (Gruppe) "Nutzung" muss ja 28 Tabellen abklappern.
In der täglichen Praxis braucht man aber nicht immer die Möglichkeit jeden (Sub-) Layer einzeln zu schalten. Oft reicht eine "Standard-Karte" für Suche und Positionierung und für die Kombination mit anderen Themen.
Wir setzen seit einigen Wochen den "MapProxy" ein, der diese Standardkarte cached und somit bedeutend schneller ausliefern kann. http://mapproxy.org/
Einige unserere Mapbender-Oberflächen verfügen nun wahlweise über den Original-WMS *und* den gecachten WMS. Viele kommen auch nur mit der Cache-Version aus.
Bei der Konfiguration des MapProxy muss man einen Kompromiss finden zwischen Aufwand und Qualität. Je mehr Maßstäbe man konfiguriert oder sogar auf Vorrat rendern lässt (seeding), um so besser wird die Qualität, aber es steigt auch der Aufwand (mit seeding) oder es wird wieder langsamer (ohne seeding, beim ersten Aufruf).
Maßstäbe zwischen den im "Grid" festgelegten Maßstäben werden durch Dehnen oder Stauchen des Kartenbildes erzeugt. Linienbreiten oder Schriftgrößen werden dann nicht mehr ganz genau eingehalten. Auch sieht eine Linie dann schon mal etwas zackelig aus. Das ist also nichts für Kataster-Pedanten, aber als Hintergrund für die meisten kommunalen Anwendungen ist das brauchbar.
Ich habe Teile unserer MapProxy-Konfiguration für die Musterkarte Rheinland-Pfalz als Beispiel ins PostNAS-SVN eingecheckt. Dies kann als Basis für eine eigene Konfiguration dienen:
http://trac.wheregroup.com/PostNAS/browser/trunk/data/mapproxy
Folgende Überlegungen liegen dem zugrunde:
Es wird ein Cache-Layer "ALKIS" mit der Strichzeichnung gebildet, der im Wesentlichen die Layer-Gruppen "Flurstück", "Gebäude" und "Präsentation" (Texte) enthält. Dieser Layer hat große transparente Anteile und eignet sich für die Überlagerung von Luftbildern oder anderen Themen.
Ein zweiter Cache-Layer enthält nur die Nutzungsarten. Diese sind dann nicht mehr einzeln zuschaltbar. Man kann nur die gesamte flächendeckende Ebene einschalten. Themen (WMS) darunter sind nicht mehr sichtbar.
Es wurde keine Maßstabs-Reihe mit festem Faktor verwendet (üblich ist Faktor "Wurzel 2") sondern es wurden im Grid genau die Maßstäbe konfiguriert, die im Client auch direkt auswählbar sind (Element "ScaleSelect" des Mapbender) bzw. die zum Positionieren aus dem Programmteil "Navigation" verwendet werden (1:500, 1:1000, 1:2500, ...).
Für diese "runden" Maßstäbe, die häufiger aufgerufen werden, kann das Kartenbild aus dem Cache direkt verwendet werden. Das ist am schnellsten und man hat keinen Qualitätsverlust.
Für die Nutzungsarten (Flächen) reichen weniger Maßstäbe (6) als für die Strichzeichnung (8).
Die häufig verwendeten Maßstäbe (um die 1:1000) werden für unsere produktiven Bestände flächendeckend auf Vorrat generiert. Somit kann man schon beim ersten Aufruf den Geschwindigkeitsvorteil genießen.
Für selten verwendete Maßstäbe wie "1:250" scheint dieser Aufwand nicht gerechtfertigt. Dieser Maßstabsbereich füllt sich im Cache erst bei der ersten Benutzung und nur in den Gebieten wo dies auch tatsächlich angefordert wird.
Der Layer "Nutzung" wird anders als im Beispiel (Musterkarte) für die produktiven Bestände derzeit noch nicht vorgeneriert. Ich gehe davon aus, das dieser Layer nur selten benutzt wird.
Unser Mapproxy ist als MultiMapProxy konfiguriert. http://mapproxy.org/docs/1.1.1/deployment.html#id12
Ein ALKIS-Bestand (im Ordner /projects/) stellt sich also als eigener WMS dar, der an beliebiger Stelle im Themenbaum eingehängt werden kann.
Weitere Erfahrungen müssen noch zeigen, ob die derzeitige Konfiguration in der Praxis tauglich ist.
Ich könnte mir vorstellen, dass für eine sensible Karte wie ALKIS, die Stufen der Maßstäbe im Grid noch etwas verdichtet werden müssen. Derzeit liegt die Abstufung eher bei Faktor 2 als bei der empfohlenen Stufe 1,4 (Sqrt2).
Mit freundlichen Grüßen
Frank Jäger