HBUMNMapServer ger Capter 3

From OSGeo
Jump to: navigation, search

User:Astrid Emde (SLD, WMC, Filter Encoding, OWS Clients)
Jörg Thomsen (OGC-Konformität, Warum macht man das?, Wie macht man das? )

Inhaltsverzeichnis


OGC-Konformität

--Jtmapmedia 13:52, 10 January 2009 (UTC) (1)\index{OGC}

Das Open Geospatial Consortium~\cite{http:website:ogc}, kurz OGC, ist ein internationaler Zusammenschluß von '368 Unternehmen, Regierungsorganisationen und Universitäten' (Eigendarstellung auf der Website, die Zahl ändert sich beinahe wöchentlich). Ziel des OGC ist es, gemeinsame Standards (Protokolle, Formate etc.) für Austausch, Verarbeitung und Speicherung von Geodaten zu erarbeiten.

Die Standards, die uns bei der Erstellung von OGC-konformen MapServern im Internet interessieren können, sind vielfältig. Für den MapServer sind die folgenden Standards relevant bzw. implementiert:

  • OGC Web Map Service Specification (WMS), für den Transfer von Rasterkarten und eventuelle Anfragen auf diese Daten,
  • OGC Web Feature Service Specification (WFS), was das gleiche für Vektordaten und eventuelle Anfragen auf diese Daten ist.
  • OGC Web Coverage Service Specification (WCS), regelt den Zugriff auf hochaufgelöste Rasterdaten wie Luft- und Satellitenbilder und deren Bereitstellung.
  • OGC Sensor Observation Service (SOS), der den Austausch von Sensordaten, wie z.B. Wasserpegel oder Temperaturmessungen spezifiziert.
  • Map Context Specification, ermöglicht das Speichern und Laden von WMS-Zuständen wie Zoomstufe, sichtbare Layer usw..

Darüber hinaus werfen wir auch noch einen raschen Blick auf

  • OGC Filter Encoding (FE), damit können Geodaten, beispielsweise für Klassifizierungen, gefilter werden.
  • OGC Styled Layer Descriptors (SLD), eine Spezifikation, die es ermöglicht die Kartengestaltung eines entfernten WMS zu beeinflussen.

Die Website des OGC ist unter~http:website:ogc zu erreichen. Zu allen genannten Diensten, und zu vielen weiteren, finden Sie dort auch die Spezifikationen als PDF-Dateien. Sehen Sie sie sich ruhig einmal an. Nachdem Sie die ersten 20 bis 30 Seiten überblättert haben, finden Sie vor dem Anhang die interessanten Informationen auf meist wenigen Seiten zusammengefasst.

Warum macht man das?

--Jtmapmedia 13:56, 10 January 2009 (UTC)

Eine berechtigte Frage ist natürlich, warum man diese Funktionalität überhaupt haben wollen könnte. Die Antworten sind vielfältig. Hier einige Beispiele:

\subsubsection* {Kein Zugang zu den Originaldaten}

Die wenigsten Besitzer von Geodaten rücken diese umsonst, oder überhaupt heraus. Manche sind allerdings durchaus gewillt, Karten auszuliefern; ihre Originaldaten kommen dabei nicht an die Öffentlichkeit. Durch die Bereitstellung von Karten nach den Kriterien des WMS sind darüberhinaus nicht nur Sie, sondern auch andere in der Lage, Karten aus der 'schwierigen Quelle' zu beziehen. Die Existenz eines Standards kann also schon zur Verbreitung von Kartenmaterial beitragen.

\subsubsection*{Lastenverteilung}

Ähnlich wie bei Datenbankanbindungen -- siehe auch Kapitel~\ref{text:database} -- kann beispielweise ein WMS-konformes zur Verteilung von Rechenlast beitragen, indem einzelne Layer der Karte einfach auf verschiedene Rechner verteilt werden.

\subsubsection*{Herstellerunabhängigkeit}

Durch ein standardisiertes Kommunikationsprotokoll sind Sie in der Lage, sich den Hersteller Ihrer Software auszusuchen. Umgekehrt bedeutet das auch, dass Sie nicht auf die Software eines bestimmten Herstellers angewiesen sind, wenn beispielsweise auf einen WMS-konformen Server zugegriffen werden soll. Die Wahl der Software kann also eher an anderen Kriterien (z.B. dem Preis) ausgerichtet werden. Heutzutage gibt es eine große Zahl OGC-konformer Programme, die sich nahezu beliebig miteinander verknüpfen lassen, so kann eine als WMS konfigurierter UMN MapServer seine Karte problemlos an verschiedene Klienten sowohl im Browser (z.N. Mapbender, OpanLayers) als auch auf dem Desktop (z.B. Quantum GIS, gvSIG) ausliefern und einen wichtigen Teil zur Geodateninfrastruktur beitragen.

Auf der Website des OGC finden Sie eine Liste von Herstellern und Produkten~http:website:ogcnetwork:impl und eine Beschreibung, welche Standards in welcher Version von ihnen unterstützt werden.

\subsection*{Existenz von Evaluationskriterien}

Häufig steht man vor der Frage, welches Produkt man für einen besonderen Zweck einsetzen soll. Das richtige Vorgehen ist natürlich, sich klarzumachen, welche Eigenschaften und Möglichkeiten die Software bieten soll, und anhand einer daraus hervorgehenden Liste kann man dann verschiedene Produkte evaluieren.

Solch ein Evaluationsvorgang kann zeitlich und finanziell sehr aufwändig sein. Weithin anerkannte Standards helfen dabei, Entscheidungen anhand fertig vorliegender Kriterienkataloge zu treffen.

Wie macht man das?

--Jtmapmedia 18:00, 10 January 2009 (UTC)

Eine UMN MapServer-Anwendung OGC-konform zu gestalten ist keine Hexerei, Sie benötigen nicht einmal eine Erweiterung und müssen auch nichts neu kompilieren - es sind lediglich einige Erweiterungen im Mapfile notwendig. Bevor wir uns aber wieder dem Mapfile zuwenden, ein paar Sätze das grundsätzliche Verständnis der Funktionsweise von OGC-Diensten fördern.

Der Aufruf eines WMS-Servers erfolgt ganz ähnlich dem Aufruf des UMN MapServers, nämlich über einen URL mit den gewünschten Parametern, Sie werden im Folgenden bemerken, dass auch andere Aufrufe, wie WFS oder WCS, dem gleichen Muster folgen. Die Benennung der Parameter, ihr Verhalten und ihre Wirkung unterscheiden sich jedoch mehr oder weniger stark von dem, was Sie bisher von ihrem MapServer gewohnt sind.

Schauen Sie sich einmal einen Aufruf für eine Karte als Beispiel an. Um die Generierung solcher URLs müssen Sie sich im Detail nicht kümmern; wenn Sie einen Server betreiben, dann sowieso nicht, weil der Aufrufende die URLs kennen muss, und nicht Sie; und wenn Sie MapServer als Client betreiben, dann müssen Sie zwar einige Angaben im Mapfile zwingend machen, aber alle dynamischen Parameter werden von MapServer aufgefüllt.

\subsubsection*{Hinweis}
In der Version 4.x war MapServer sehr tolerant, einige würden sagen nicht voll OGC-konform, weil er nicht alle Aufrufparameter verlangte, die die Spezifikation vorschreibt. Wenn Sie beim Aufruf eines WMS ab UMN Version einen laut Spezifikation erforderlichen Parameter weglassen, wird das nun mit einer Fehlermeldung quittiert.


Nun aber ein Beispiel für einen WMS-konformen URL des MapServers:

FIXME: Beispielaufruf dem aktuellen OSM/Hamburg-Beispiel anpassen.

 http://www.example.com/cgi-bin/mapserv
    ? SERVICE=WMS
    & VERSION=1.1.1
    & REQUEST=GetMap
    & FORMAT=image/png
    & LAYERS=gruenflaechen,fluesse,bebauung
    & SRS=EPSG:4326
    & BBOX=5.0,45.0,15.0,55.0
    & WIDTH=500
    & HEIGHT=500
    & STYLES,,,
 #hier enden die Pflichtparameter, Auftritt zweier optionaler Parameter:
    & TRANSPARENT=TRUE
    & EXCEPTIONS=application/vnd.ogc.se_inimage


Sie werden sich jetzt fragen, wo denn der Hinweis auf das Mapfile geblieben ist, den Sie bisher immer mit angeben mussten. Ein Parameter map ist in der WMS-Spezifikation allerdings nirgends erwähnt. Wie man sich dieses Parameters entledigen kann, erfahren Sie weiter unten auf Seite~\pageref{text:wms:mapfilename}.

Der erste Parameter SERVICE gibt an, welche Spezifikation genutzt werden soll. Wir möchten eine Karte im PNG-Format abrufen, die im Browser angezeigt werden soll, also benutzen wir den Web Map Service.

Als nächstes wird mit VERSION angegeben, in welcher WMS-Version man die Kommunikation wünscht. Laut Spezifikation soll dabei im Hintergrund eine Aushandlung der Version stattfinden, falls eine Seite eine angegebene Version nicht kennt; Client und Server handeln sich dann gegenseitig herunter, bis sie auf eine Version treffen, die sie beide verstehen.

Der Parameter REQUEST gibt die Art der Anfrage an. Die in MapServer implementierten Modi sind bereits weiter oben in Abschnitt~2 genannt worden. Beachten Sie, dass die Schreibweise von GetMap bezüglich der Klein- und Großbuchstaben irrelevant sein sollte. Das gleiche gilt auch für die Namen der Parameter wie VERSION, REQUEST und so weiter. Die Großschreibung erfolgt hier nur wegen der besseren Lesbarkeit. Es gibt aber auch Dienste, die diese Schreibweise ewarten.

Die Angabe FORMAT wird als sogenannter MIME type gemacht, eine standardisierte Notation für die Art von über das Netz geschickten Daten. Bildformat folgen prinzipiell dem Muster image/ plus angehängtem Namen des Bildformats, also zum Beispiel image/jpeg für JPEG-Bilder. Mehr über MIME-Typen inklusive Links zu den diversen zuständigen RFCs finden Sie auf~http:homepage:mime.

Es folgen die Layer, die angezeigt werden sollen. Anders als beim 'klassischen' MapServer, wo die Layernamen einzeln jeweils mit layer notiert werden, wird bei WMS-konformen Servern eine Liste der gewünschten Layer benötigt, wobei die einzelnen Layer durch Kommata voneinander getrennt werden. Dabei ist die Reihenfolge wichtig: der zuerst genannte Layer wird als erste Ebene in die Karte gezeichnet, liegt also zuunterst. Die im Mapfile festgelegte Reihenfolge spielt keine Rolle mehr.

Mit SRS wird das spatial reference system definiert, also die gewünschte Projektion angegeben. WMS verlangt EPSG-Codes für die Notierung der Projektion, wobei das Schlüsselwort EPSG und die dazugehörige Zahl durch einen Doppelpunkt voneinander getrennt werden. Mehr zu diesem Thema, das oft zu schwer identifizierbaren Fehlern führt und einige Nerven kosten kann, finden Sie im Anhang FIXME: Verweis auf den noch zu erstellenden Anhang.

BBOX: Ähnlich wie die anzuzeigenden Kartenebenen werden auch die gewünschten Extents durch mehrere Werte angefordert, die in einer Liste durch Kommata voneinander getrennt sind. Achten Sie immer darauf, dass die Werte der BBOX mit dem SRS korrespondieren.

WIDTH und HEIGHT geben die Größe in Pixeln vor, die die fertige Karte haben soll. Beachten Sie, dass diese Werte mit der BBOX korrelieren müssen; eine quadratische BBOX in Verbindung mit ungleicher Höhe und Breite führt zu einer Verzerrung des Kartenbildes.

Der Parameter STYLES gibt für jeden Layer eine Darstellungsoption an (sofern der Provider des Service dieses mit den sog. Named Styles vorbereitet hat). Sie müssen keine Styles angeben, der Parameter im GetMap-Aufruf ist jedoch Pflicht.

Mit TRANSPARENT wird die Hintergrundfarbe der Karte transparent geschaltet. Das will man offensichtlich dann haben, wenn man unter dieser Kartenebene noch andere Layer anzeigen möchte.

Schließlich und endlich wird dem WMS im obigen Beispiel mitgeteilt in welcher Form Fehlermeldungen ausgegeben werden, in unserem Fall soll die Fehlermeldung in resultierende Rasterbild gerendert werden. Wenn Sie eine XML-formatierte Fehlermeldung bevorzugen verwenden Sie application/vnd.ogc.se_xml.

Das Ergebnis dieses Aufrufes ist also eine 500 mal 500 Pixel große, auf EPSG-Code FIXME: 4326</span> projizierte Karte im PNG-Format mit den angegebenen Extents und transparentem Hintergrund. Der aufrufende URL dieser Karte kann entweder so bei Ihnen im Webbrowser erscheinen, oder aber von MapServer dynamisch für die Anzeige als Rasterlayer generiert worden sein.

Als nächstes schauen wir uns an, wie aus einem bestehenden Mapfile eines gemacht werden kann, das für WMS-konformes Verhalten nach außen sorgt.

Web Map Service (WMS)

UMN als WMS Server

Von besonderem Interesse ist die OpenGIS Web Map Server Interfaces Implementation Specification , im folgenden kurz WMS-Standard genannt. Diese Spezifikation liegt inzwischen in der Version 1.1.1~pdf:spec:ogc111 vor. MapServer unterstützt aber auch die zurückliegenden Standards 1.0.0~pdf:spec:ogc100 und 1.1.0~pdf:spec:ogc110.

Sinn der WMS-Spezifikation ist es, ein offenes, definiertes Interface sowohl für Clients als auch für Server zur Verfügung zu stellen, die Karten und Daten über diese Karten miteinander austauschen wollen. Zur Kommunikation zwischen den Servern und Clients wird das HTTP-Protokoll verwendet. Über das Protokoll werden Daten im XML-Format übertragen\footnote{Für Exceptions sind auch andere Formate möglich.}. Parsen und weiterverarbeiten läßt sich XML in fast jeder bekannten Programmiersprache. Auf diese Weise ist man nicht an Webapplikationen gebunden, wenn man ein Programm entwickeln möchte, das mit einem WMS-Mapserver 'redet'. Die dazugehörige DTD\footnote{Die sogenannten document type definitions dienen der Validierung von Dokumenten. Sie können ein DTD also benutzen, um zu testen, um ein Dokument einem bestimmten Rahmen an Vorgaben genügt.} ist vom OGC zu beziehen und in der Spezifikation beschrieben. Gedruckt lernen Sie mehr über XML durch die Lektüre von~ray:2001:xml, online finden Sie die Spezifikationen unter~http:homepage:xml.

\subsubsection*{Hinweis}

Eine zentrale Rolle bei der Verwendung von WMS spielt die Umprojizierung von Daten. Da bei WMS Rasterdaten zum Einsatz kommen\footnote{Die Datenquelle für den Server kann natürlich ein Vektorformat haben. Produziert werden aber ausschließlich Rasterdaten, wie wir es bisher immer beim MapServer gesehen haben.}, und MapServer Rasterdaten ausschließlich unter Zuhilfenahme der Bibliothek GDAL umprojizieren kann, sollten Sie MapServer mit der Unterstützung für GDAL kompiliert haben.

==Servermodi==(2)

Die genannten Spezifikation in ihrer letzten Version verlangt: es müssen zwei Arten von Anfragen implementiert sein, zwei weitere sind optional und können implementiert sein. Die beiden folgenden Anfragen (weiterhin auch Requests genannt) müssen vorhanden sein:


  • =getCapabilities= : Diese Anfrage muss ein XML-Dokument zurückliefern, das die Fähigkeiten des Mapservers beschreibt.
  • =getMap= : Auf diese Anfrage wird eine Karte als Rasterbild zurückgeliefert.

Entsprechend der Anforderung sind diese beiden Anfragen auch im MapServer implementiert.

Die beiden Fähigkeiten, die implementiert sein können , sind:


  • =getFeatureInfo= : auf diese Anfrage liefert der Mapserver Informationen über einen bestimmten Punkt in einer Karte zurück. Diese Informationen können entweder in einer reinen Textdarstellung oder in GML (einem XML-Format) zurückgegeben werden.
  • =describeLayer= liefert ein XML-Dokument mit detaillierten Informationen über einen Layer zurück. Dieser Modus wäre für einen SLD\footnote{Styled Layer Descriptor}-konformen MapServer interessant, aber dieser Standard hat bisher noch keine Umsetzung im MapServer erfahren.

Das einzige Feature, das im MapServer zurzeit nicht implementiert ist, ist demnach =describeLayer= . Es gibt noch einige andere Modi; mehr dazu in Abschnitt~7

==WMS-Metadaten im Mapfile==\index{Metadaten}

Zuallererst benötigt ihr Mapfile einen Namen. Im Header muß also der Parameter =NAME= definiert sein.

Einen 'minimalen' WMS-Server erhalten Sie zum einen durch Metadaten in der =WEB= -Sektion des Mapfiles, zum anderen durch Metadaten in den einzelnen Layern. Einige davon sind zwingend erforderlich, andere optional. Wie die Notation von Metadaten im Mapfile generell erfolgt, haben Sie bereits in Abschnitt~\ref{text:mapfile:web:meta} erfahren.



WEB
  ...
  METADATA
    "wms_title" "Ein WMS-Server"
    "wms_onlineresource" \
       "http://www.example.com/cgi-bin/mapserv?map=mapfile.map&"
    "wms_srs"  "EPSG:31464 EPSG:4326"
  END
END



Der =wms_title= ist der Titel für die Karte, dieser muß angegeben werden. Der zweite Parameter gibt an, unter welchem URL der Server aufzurufen ist.

Beachten Sie dabei, das =\&= anzugeben, bzw. ein Fragezeichen, wenn Sie nach dem eigentlichen CGI-Programm keinen Parameter zu stehen haben.

=wms_srs= steht für die Projektion, in der die Karten angeboten werden können. Die Spezifikation schreibt vor, dass hier immer mindestens EPSG-Code 4326 angeboten werden muß. Mehrere Projektionen werden einfach durch Leerzeichen voneinander getrennt. Mehr zu EPSG und Projektionen im allgemeinen haben Sie schon in Abschnitt~\ref{text:map:projections} erfahren.

Sie benötigen =wms_srs= nicht, wenn Sie für die Karte einen Projektionsblock mit EPSG-Angabe definiert haben; die =WEB= -Sektion 'erbt' dann diese Projektion als Vorgabe.

Was machen Sie, wenn Ihre Daten allesamt in einer Projektion vorliegen, für die es keinen EPSG-Code gibt? Dann können Sie einen =PROJECTION= -Block definieren, der Parameter für die Projektionsbibliothek proj.4 enthält (das Beispiel stammt direkt aus der MapServer-Dokumentation):


PROJECTION
  "proj=lcc"
  "ellps=GRS80"
  "lat_0=49"
  "lon_0=-95"
  "lat_1=49"
  "lat_2=77"
END


Wenn Sie nun EPSG-Codes in =wms_srs= nach außen anbieten, werden die Daten automatisch umprojiziert.

\subsubsection*{Notwendige Metadaten in den Layern}

Des weiteren müssen nun in jedem Layer zusätzliche Angaben nach folgendem Muster gemacht werden:


LAYER
  NAME "einlayer"
  ...
  METADATA
    "wms_title" "Titel fuer den Layer"
    "wms_srs"  "EPSG:31494"
  END
END


Daneben muß auch in jedem Layer ein Name gesetzt und eine Projektion definiert sein. Als Standardvorgabe erbt jeder Layer die Projektionen aus der =WEB= -Sektion, sodass sie nicht noch einmal neu notiert werden müssen.

Sie benötigen natürlich immer noch eine Projektionsangabe im Layer in Form eines =PROJECTION= -Blocks, um zu definieren, in welcher Projektion die Datenquelle vorliegt, damit MapServer im Zweifelsfall korrekt projizieren kann. Das gilt natürlich insbesondere dann, wenn Sie mehr als nur eine Projektion anbieten wollen.

MapServer geht im übrigen davon aus, dass sie tatsächlich alle Layer im Mapfile nach außen zur Verfügung stellen wollen. Layer, die sie nicht nach außen geben wollen, haben also in diesem Mapfile nichts verloren. Es gibt bisher keinen Mechanismus, mit dem man einzelne Layer (oder alle) in einem Mapfile von der Auslieferung per WMS ausschließen kann.

\subsubsection*{Metadaten in der Web-Sektion}

Im folgenden sind alle Metadaten beschrieben, die Sie für einen WMS-konformen Server in der =WEB= -Sektion des Mapfiles notieren können. Alle Angaben sind optional, falls nicht anders angegeben.


  • =wms_abstract= Eine elaborierte Zusammenfassung dessen, was der Server soll und ist.
  • =wms_accessconstraints= Gibt Zugangsbeschränkungen für den MapServer an. Beachten Sie bitte, dass ein Eintrag hier lediglich eine Absichtserklärung ist. Ein Text wie 'Dieser Server darf nur im Intranet unserer Firma verwendet werden' ist natürlich schön und gut, aber die entsprechenden Zugriffsbeschränkungen sind selbtsverständlich nur durch die entsprechende Konfiguration der Systeme zu erreichen.
  • =wms_addresstype= Art der Adresse. Für dieses und die folgenden fünf Felder gilt, dass bei Angabe eines der Felder auch die anderen fünf mit Inhalt gefüllt werden müssen.
  • =wms_address= Die Adresse.
  • =wms_city= Adressbestandteil: Stadt
  • =wms_country= Adressbestandteil: Land
  • =wms_postcode= Adressbestandteil: Postleitzahl
  • =wms_stateorprovince= Adressbestandteil: Staat oder Provinz
  • =wms_contactelectronicmailaddress= Emailadresse einer Kontaktperson für diesen Server
  • =wms_contactoraganization= Organisation der Kontaktperson
  • =wms_contactperson= Name der Kontaktperson für diesen Server
  • =wms_contactposition= Position der Kontaktperson innerhalb ihrer Organisation
  • =wms_contactvoicetelephone= Telefonnummer der Kontaktperson
  • =wms_fees= Art und Umfang der Gebühren, die für die Nutzung dieses Servers fällig werden. Genau wie bei =wms_accessconstraints= ist dies lediglich eine Absichtserklärung; wenn Sie Gebühren für die Verwendung des Servers erheben möchten, müssen Sie die Zugriffskontrolle durch eine geeignete Systemkonfiguration und ein passendes Geschäftsmodell herbeiführen.
  • =wms_keywordlist= Eine Liste von Schlüsselworten, die auf den Server zutreffen. Dieser Parameter ist mit dem Blick darauf geschaffen worden, dass es eines Tages in einer eigens dafür geschaffenen Datenbank eine Sammlung von Capabilities-Dokumenten geben könnte, die dann die Schlüsselwortlisten durchsuchen kann. Bisher gibt es keine solche Datenbank. Es sind auch keine Standardschlüsselwörter definiert.
  • =wms_onlineresource= Der URL, mit dem der Server aufgerufen wird. Beinhaltet beim UMN MapServer meistens:
    http://www.example.com/cgi-bin/mapserv?
    und gegebenenfalls daran angehängt noch das Mapfile. Wenn ein Mapfile über =map== angehangen wird, darf nicht das abschließende =\&= vergessen werden! Dieser Parameter ist zwingend notwendig.
  • =wms_resx= Horizontale Auflösung der Karte in Pixeln.
  • =wms_resy= Vertikale Auflösung der Karte in Pixeln.
  • =wms_srs= Projektion(en), in der die Karte angeboten werden kann. Dieser Parameter mit mindestens einer Projektion ist zwingend notwendig.
  • =wms_title= Titel der Karte. Dieser Parameter ist zwingend notwendig.

\subsubsection*{Metadaten in den einzelnen Layern}

Im folgenden die Metadaten, die Sie für einen WMS-konformen MapServer in den einzelnen Layern im Mapfile definieren können. Alle Parameter sind optional, sofern nicht anders angegeben.


  • =wms_abstract= Elaborierte Zusammenfassung dessen, was dieser Layer soll und ist.
  • =wms_extent= Die Bounding Box des Layers.
  • =wms_keywordlist= Eine Liste von Schlüsselworten, die auf diesen Server zutreffen.  %
  • =wms_opaque= FIXME: was ist das?
  • =wms_srs= Projektion(en), in der die Karte angeboten werden kann.
  • =wms_title= Titel des Layers. Dieser Parameter ist zwingend erforderlich.

\subsubsection*{Das Mapfile als Parameter}(4)

Der Name des Mapfiles in der URL-Zeile ist nicht Bestandteil eines OGC-konformen Aufrufs des Mapservers. Unter Sicherheitsaspekten kann es darüber hinaus eventuell nicht angebracht sein, dem Client etwas über die Verzeichnisstruktur des Server-Systems zu verraten.

Im Moment gibt es zwei verschiedene Wege, den Ort des Mapfiles vor Außenstehenden zu verbergen:


  • Verwenden eines Wrapper-Skripts : Anstatt des CGI-Binaries wird ein kleines Skript aufgerufen, das die Umgebungsvariable = MS_MAPFILE = setzt und dann seinerseits das CGI-Programm aufruft. Ganz primitiv könnte ein solches Skript für die Shell =bash= etwa wie folgt aussehen:
    #!/bin/sh MS_MAPFILE=/usr/local/there/is/my.map export MS_MAPFILE /usr/local/httpd/cgi-bin/mapserv
    Beachten Sie bitte, dass dieses Beispiel nur für Unix-Systeme funktioniert, auf denen die Shell =bash= installiert ist. Für andere Shells kann die Notation abweichen.
  • Webserver-Konfiguration : Der Webserver ist unter Umständen in der Lage, für bestimmte aufgerufene URLs spezifische Umgebungsvariablen zu setzen. Im Apache sähe ein Eintrag in der Datei httpd.conf dann beispielsweise folgendermaßen aus (wegen der Zeilenlänge für das Drucklayout umgebrochen, muß in der Konfigurationsdatei eine Zeile sein):
    SetEnvIf Request_URI "/cgi-bin/mapserv" \ MS_MAPFILE=/usr/local/there/is/my.map
    Dieser Eintrag funktioniert nur im Apache und kann für andere Webserver vollkommen anders aussehen. Konsultieren Sie Ihre Dokumentation.


\subsubsection*{getCapabilities}(5)

Nachdem man zufrieden mit seinem Setup ist, möchte man es natürlich ausprobieren. Dazu ruft man als erstes das Capabilities -Dokument ab:


http://server/cgi-bin/mapserv?VERSION=1.1.0&REQUEST=getCapabilities \
     &map=mapfile.map 


Dabei müssen Sie bei =getCapabilities= nicht auf Groß- oder Kleinbuchstaben achten. Ebensowenig bei allen anderen Parametern, die vor einem Gleichheitszeichen stehen.

Der Webserver sollte Ihnen nun eine Datei des Typs =application/vnd.ogc.wms_xml= zurückliefern. Diese Textdatei können Sie abspeichern und in einem beliebigen Texteditor öffnen. Eventuell ist Ihr Webbrowser auch von sich aus in der Lage, XML-Dateien automatisch in einem ansprechenden Layout darzustellen.

Schauen Sie sich nun den Inhalt der Datei genau an. Wo immer Sie auf Zeilen treffen, die



beinhalten, gilt es, etwas zu bereinigen. Beispielsweise erfahren Sie aus einer Warnung wie dieser:



dass Sie einen Meta-Tag für den Titel der entsprechenden Sektion vergessen haben.

Sobald Sie keine Warnungen dieser Art mehr in Ihrem Capabilities-Dokument finden, ist ihr MapServer WMS-konform und voll einsatzbereit.

\subsubsection*{getMap}

Wenn die Capabilities wie erwartet geliefert werden, ist der nächste logische Schritt natürlich, sich eine Karte von Hand abzuholen. Dafür konstruieren Sie sich in Ihrem Webbrowser einen Aufruf, der etwa so aussieht, wie das Beispiel in Abschnitt~3. Dabei machen Sie sich dann auch gleich mit der Benennung der Parameter vertraut.

Das beste was Ihnen passieren kann, ist natürlich, dass Sie gleich ihre gewünschte Karte bekommen. Dann sind Sie natürlich fertig. Sobald Sie jedoch Ihren ersten Fehler machen, müssen Sie sich mit Fehlermeldungen auseinandersetzen, den so genannten Exceptions.

==Exceptions==\index{Exceptions}\index{WMS!Exceptions}

Exceptions sind Meldungen, die von einem WMS-konformen Mapserver im Fehlerfall ausgegeben werden müssen. Das entspricht in etwa dem Expcetions-Konzept diverser Programmiersprachen wie z.B. Java. Der Sinn ist es, dem aufrufenden Client -- sei es nun eine menschliche Person, sei es eine Software -- anhand des Typs und des Inhalts der Fehlermeldung eine Entscheidung über das weitere Vorgehen treffen zu können. Eine solche Art der Fehlerbehandlung verhindert natürlich unter anderem, dass ein Programm seine Durchführung im Fehlerfall einfach beendet.

Wenn Sie bei einem WMS-konformen Aufruf einen Fehler machen, indem Sie beispielsweise einen Parameternamen wie =REQUEST= absichtlich falsch schreiben, wird Ihnen MapServer eine Datei in einem XML-Format zurückliefern:


  • =application/vnd.ogc.se_xml= Ein WMS-konformer Mapserver muß mindestens diese Art der Vermittlung von Exceptions beherrschen. Solch eine Datei kann beispielsweise folgenden Inhalt haben:
    <?xml version='1.0' encoding="ISO-8859-1" standalone="no" ?> <!DOCTYPE ServiceExceptionReport SYSTEM "http://www.digitalearth.gov/wmt/xml/exception_1_1_0.dtd"> <ServiceExceptionReport version="1.1.0"> <ServiceException> msWMSDispatch(): WMS server error. Incomplete WMS request: REQUEST parameter missing </ServiceException> </ServiceExceptionReport>

\begin{figure} \begin{center} \mmfig{0.6}{wms-exception-inimage}{Exception vom Typ application/vnd.ogc.se_inimage.} \end{center} \end{figure}

Des weiteren kann ein Mapserver Exceptions in den folgenden MIME-Typen zur Verfügung stellen:


  • =application/vnd.ogc.se_inimage= Die Exception wird als Text in das auszuliefernde Bild eingefügt.
  • =application/vnd.ogc.se_blank= Die Spezifikation geht von der Idee, dass ein leeres Bild etwas ist, dass man grundsätzlich nicht haben möchte, und somit nie bekommt. Daher kann ein 'leeres' Bild als Fehlermeldung angesehen werden. Als 'leeres' Bild ist ein Bild definiert, das ganz mit der Hintergrundfarbe der Karte ausgefüllt ist.

Im URL des Aufrufs wird die gewünschte Art der Exception mit dem Parameter =EXCEPTIONS= notiert. Wollen Sie Exceptions also im Bild notiert haben, schreiben Sie in Ihrem URL:


... & EXCEPTIONS=application/vnd.ogc.se_inimage & ...


Beachten Sie bitte, dass nur die XML-Variante implementiert sein muß. Wenn Sie von einem Server Exceptions im Bild verlangen, er aber nur XML kann, dann wird er XML liefern.

Beachten Sie außerdem, dass das Handling von Exceptions insbesondere bei Kaskaden von WMS-konformen Servern eine Rolle spielt. So kann es Ihnen passieren, dass Sie sich einen Layer von einem Server holen, der sich wiederum sein Bild von anderen entfernten Quellen heranholt, und von dort im Fehlerfall eine Exception in das Bild eingetragen bekommt. Dadurch haben Sie die Fehlermeldung dann natürlich auch im Bild zu stehen.

Hinweis

Viele Kartenanbieter tendieren dazu, ihre fertigen Karten mit Schriftzügen, Logos, Nordpfeilen, Wasserzeichen und so weiter auszustatten. Denken Sie immer daran, dass der Kunde, der Ihren Service wiederum als Datenquelle benutzt, eventuell auf die Idee kommt, die von Ihnen bezogene Karte umzuprojizieren! Das kann dann zu interessanten Effekten führen, wenn dann Dritte den Schriftzug mit der URL Ihrer Firmenwebsite quer über die ganze Karte gekrakelt bekommen. Entwickeln Sie im Vorhinein zusammen mit den Benutzern des Service ein Konzept, dass solche häßlichen Effekte verhindert.

getFeatureInfo

Sich Karten einfach nur anzusehen, ist selbstverständlich nur die Hälfte des Reizes eines WMS-konformen Servers. Man möchte selbstverständlich auch Queries auf die Daten durchführen können. Zu diesem Zweck gibt es den =REQUEST= mit dem Namen =getFeatureInfo= .

Zuerst einmal gilt es, Queries überhaupt erst einmal zuzulassen. Wie schon bei den 'klassischen' Queries (siehe Abschnitt~\ref{text:mapfile:queries}) kann man in MapServer eine Query nur auf einem Layer durchführen, der ein =TEMPLATE= definiert.

Wenn man das tut, und sich die capabilities anschaut, wird man für den Layer auf ein Attribut der folgenden Art treffen:


Layer definitions are only valid on pages of namespace "Layer"