Master Thesis
im Rahmen des
Universitätslehrganges „Geographical Information Science & Systems“
(UNIGIS MSc) am Zentrum für GeoInformatik (Z_GIS) der Paris Lodron-Universität Salzburg
zum Thema
„OGC Filter Encoding Standard“
Analyse und Umsetzung zur Erstellung von personalisierten Karten
vorgelegt von
Dipl. Ing. (FH) Isabel Honikel
Teilnehmerkennzahl U1550, UNIGIS MSc Jahrgang 2010
Zur Erlangung des Grades
„Master of Science (Geographical Information Science & Systems) – MSc(GIS)”
Gutachter:
Ao. Univ. Prof. Dr. Josef Strobl
Karlsruhe, 30.06.2013
1
OGC Filter Encoding Standard
A
NALYSE UNDU
MSETZUNG ZURE
RSTELLUNG VON PERSONALISIERTENK
ARTEN2
Ich versichere, diese Master Thesis ohne fremde Hilfe und ohne Verwendung anderer als der angeführten Quellen angefertigt zu haben, und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat. Alle Ausführungen der Arbeit die wörtlich oder sinngemäß übernommen wurden sind entsprechend gekennzeichnet.
Ort und Datum eigenhändige Unterschrift
3 1 Inhaltsverzeichnis
1 Inhaltsverzeichnis ... 3
2 Zusammenfassung ... 5
3 Einleitung ... 6
4 Der OGC Filter Encoding Standard ... 8
4.1 Open Geospatial Consortium (OGC) ... 8
4.2 Der Filter Encoding Standard ... 9
4.2.1 Filtertypen... 9
4.2.2 Logik Operatoren ... 10
4.2.3 Vergleichsoperatoren ... 11
4.2.4 Zeit Operatoren ... 12
4.2.5 Raum Operatoren / Geographische Operatoren ... 13
4.2.6 Object Identifiers (ID) ... 22
4.3 Anwendung der FE nach aktuellem Stand der Technik ... 22
4.3.1 WFS Filter Encoding im MapServer 6.2 ... 22
4.3.2 ArcGIS ... 24
4.3.3 OpenPOIMap ... 25
5 Analyse des Standards anhand personalisierter Karten ... 26
5.1 Personalisierte Karte ... 26
5.2 Web Feature Service ... 26
5.3 Analyse der Filterfunktionen anhand der Anwendungsbeispiele ... 28
5.3.1 Anwendungsbeispiel 1: Radfahrer POI im Umkreis um Route ... 29
5.3.2 Anwendungsbeispiel 2: Tankstellen vor der Grenze ... 32
5.3.3 Anwendungsbeispiel 3: Toiletten bei Sehenswürdigkeiten ... 35
4
6 Konzeptionelle Umsetzung der Filter in einem Web Client ... 38
6.1 Architektur des Web Clients ... 38
6.2 Design des User Interface ... 39
6.3 Grenzen des QueryBuilders ... 43
7 Schlussfolgerung / Ausblick ... 44
8 Abbildungsverzeichnis ... 45
9 Tabellenverzeichnis ... 46
10 Abkürzungsverzeichnis ... 47
11 Literaturverzeichnis ... 48
5 2 Zusammenfassung
Ziel dieser Arbeit war es den OGC Filter Encoding Standard (FE) zu analysieren.
Anhand von Anwendungsbeispielen wurde überprüft, in wie weit sich der Standard für die personalisierte Kartenerstellung eignet und welche Funktionalitäten dem Filter Encoding Standard in der Version 2.0 fehlen um die Anwendungsbeispiel vollständig abbilden zu können.
Anschließend wird ein Design eines Web Clients beschrieben, der den Filter Encoding Standard unterstützt. Er soll es dem Benutzer ermöglichen anhand eines QueryBuilders die Filteroperatoren für seinen persönlichen Anwendungsfall zu kombinieren.
Zusammenfassend kann der OGC Filter Encoding Standard als ein Werkzeug beschreiben werden das zur Filterung von Daten universell einsetzbar ist. Er hat seine Grenzen, wenn es um die Filterung von topologischen Zusammenhängen geht.
Dennoch kann er auch für komplexe Abfragen die auf Vergleichen oder räumlichen Beziehungen beruhen angewendet werden.
Weitere sinnvolle Erweiterungen für den Filter Encoding Standard wären das iterative bearbeiten von einer Menge von Objekten und eine Sortierfunktion für die Entfernung von der Ausgangsgeometrie.
6 3 Einleitung
Im Zeitalter von GoogleMaps, BingMaps und OpenStreetMap (OSM) ist es Quasistandard geworden für jede Gelegenheit eine Karte parat zu haben.
Allerdings sind die meisten Karten mit Information überladen, weil eine sinnvolle Filterung nach den eigenen Bedürfnissen nicht möglich ist. Es müsste eine Möglichkeit geben, nur genau die Information in die Karte zu laden, welche für die aktuelle Situation interessant sind. Eine Möglichkeit eine personalisierte/themenspezifische Karte selbst zu Generieren.
Grundlage für diese personalisierte/themenspezifische Karte können frei zugänglich Daten, wie die aus OSM, sein. Durch eine effiziente Filterfunktion werden die interessanten Informationen aus einer Datenbank über einen Web Feature Service zugeschaltet.
Beispiel: Ein begeisterter Fahrradfahrer möchte eine Karte mit seiner geplanten Tour durch Points of Interrest (POIs) veredeln. Dazu möchte er alle POIs im Abstand von 2 Km zu seiner geplanten Route, ausgenommen Tankstellen die benötigt er als Fahrradfahrer nicht, anzeigen lassen. Die POIs müssen allerdings auch mit dem Rad erreichbar sein. Deshalb sollten die topologischen Zusammenhänge daraufhin geprüft werden, ob die POIs über Wege mit dem Rad erreichbar sind. Demnach werden Verbindungen über Autobahnen, Schnellstraßen und Schienen ausgeschlossen. In dieser Master Thesis gilt es zu analysieren, welche Filterfunktionen des OGC Filter Encoding Standards benötigt werden und wie diese umgesetzt werden können, um personalisierte/themenspezifische Karten in einem Web Client mit Zugriff auf einen WFS zu generieren.
Nach der Aufarbeitung der Theoretischen Grundlagen gilt zu analysieren, welche Fragestellungen im Kontext der personalisierten Kartengenerierung auftreten können.
Wie könnten solche Karten genutzt werden.
Was soll in den Karten dargestellt werden.
Welche Daten können verwendet werden.
Anhand dieser Fragestellungen werden Anwendungsfälle / Falldefinitionen aufgestellt, anhand derer, die Analyse des Standards durchgeführt wird.
7
Der Hauptteil der Arbeit ist die Analyse des OGC Filter Encoding Standards. Es wird überprüft, welche Filterfunktionen des Standards in welcher Zusammensetzung und in welcher Reihenfolge für den entsprechenden Anwendungsfall verwendet werden können. Außerdem gilt es zu erarbeiten und zu definierten wie diese zusammengesetzten Filterfunktionen in einem Client umgesetzt werden können, um eine benutzerfreundliche Generierung der personalisierten/themenspezifischen Karten zu ermöglichen.
Mit den in meiner Thesis erarbeiteten Grundlagen/Definitionen kann ein Web Client implementiert werden, welcher dem Nutzer ermöglicht seine eigene personalisierte auf seine Interessen zugeschnittene Karte zu erstellen. Ziel der Arbeit ist es hierfür die Theoretischen Grundlagen zu erarbeiten, die zur Implementierung eines Clients zur Erstellung von themenspezifischen Karten genutzt werden können.
8 4 Der OGC Filter Encoding Standard
Der OGC Filter Encoding Standard ist ein vom Open Geospatial Consortium (OGC) definierter Standard, anhand dessen eine Filterfunktionalität in einem Produkt oder Service implementiert werden kann.
4.1 Open Geospatial Consortium (OGC)
Das Open Geospatial Consortium beschreibt sich auf seiner Webseite als "[...] an international industry consortium of 476 companies, government agencies and universities participating in a consensus process to develop publicly available interface standards." [1]
Das OGC entwickelt Standards in einem Konsensprozess aller Mitglieder und stellt dadurch sicher, dass die Standards in den entsprechenden Produkten auch umgesetzt werden. Das OGC arbeitet außerdem eng mit anderen Standardisierungs- und Normungsgremien wie ISO und DIN zusammen.
Grundsätzlich sind zwei Typen von OGC-Standards zu unterscheiden:
(1) Die Abstract Specification als Referenzmodell oder konzeptionelles Fundament für die Entwicklung von OGC-Standards und
(2) die Implementation Standards, die Schnittstellen von Systemen und Sprachen definieren und insbesondere nicht plattformunabhängig formuliert sind.
Der normative Teil der Implementation Specifications besteht aus Regeln und Beschreibungen in Klartext, begleitet von Dokumenttyp-Definitionen (DTD) und XML-Schemata. Bei Spezifikationen von Diensten legen XML-Schemata die Syntax für Anfragen, Antworten und Operationen fest. Der nicht-normative Teil besteht aus Erläuterungen und Beispielen für das bessere Verständnis der Spezifikation.
9 4.2 Der Filter Encoding Standard
Der Filter Encoding Standard (FE) war ursprünglich ein Teil der Web Feature Service (WFS) Implementation Spezifikation. [2] In 2001 wurde daraus einen eigener Standard erstellt, denn die darin beschriebenen Filter sind allgemeingültig und neben dem Web Feature Services auch von anderen Services genutzt werden.
Das Ziel des Filter Encoding Standard ist es mit Hilfe eines wohldefinierten XML Schemas eine systemunabhängige Beschreibung von Filterausdrücken zu bieten.
„Der OGC® Filter Encoding Standard (FE) definiert ein XML Encoding zur Definition von Filtern für räumlich Abfragen, um räumliche Objekte aufgrund angegebener Attribute auszuwählen.“ [3]
Die Verwendung des neutralen XML Filter Encoding ermöglicht es die Filterausdrücke zu analysieren und zu validieren bevor sie in die von der Implementierung abhängige Zielsprache wie z.B. SQL übersetzt werden.
Das interessante am Filter Encoding Standard ist, dass er allgemeingültig auf die verschiedenen Services, wie Web Feature Service, Catalogue, Web Coverage Service und Gazetter Service, angewendet werden kann.
4.2.1 Filtertypen
Die Version 1.0 des Filter Encoding Standards unterstütze in der originären Version, nach der Ausgliederung aus dem WFS, über die logischen, vergleich und räumlichen Operatoren. In der ersten Version wurde die Unterstützung von Funktionen, arithmetischen Ausdrücken und XPath Ausdrücken hinzugefügt. [4]
Nach der ersten Überarbeitung, in der Version 1.1, wurde die Sortierfunktionalität, das abstrakte ID Encoding und die Nutzung von gml:id eingefügt. [5]
In Version 2.0 komplettiert die Ergänzung um die zeitlichen Operatoren den aktuell geltenden Filter Encoding Standard. [6]
10 4.2.2 Logik Operatoren
Ein logischer Operator kann verwendet werden, um eine oder mehrere bedingte Ausdrücke zu kombinieren. Logische Operatoren arbeiten im FE auf den Wahrheitswerten TRUE und FALSE. Der logische Operator AND wird als TRUE ausgewertet, wenn alle kombinierten Ausdrücke als TRUE ausgewertet werden.
Der Operator OR wird als TRUE ausgewertet, wenn jede der kombinierten Auswertung TRUE ist. Der Operator NOT kehrt den logischen Wert eines Ausdrucks um. [4]
Die im aufgezählten logischen Operatoren sind seit der Version 1.0 Bestandteil des Filter Encoding Standards:
4.2.2.1 And
A B A ˄ B
TRUE TRUE TRUE
TRUE FALSCH FALSE
FALSE TRUE FALSE
FALSE FALSE FALSE
Tabelle 1: Wahrheitswerte von AND
4.2.2.2 Or
A B A ˅ B
TRUE TRUE TRUE
TRUE FALSE TRUE
FALSE TRUE TRUE
FALSE FALSE FALSE
Tabelle 2: Wahrheitswerte von OR
11 4.2.2.3 Not
Der Not Operator ist eine Negation, also eine unmittelbare Umkehrung des Wahrheitswertes auf den er angewandt wird. Wird er auf TRUE angewendet gibt er FALSE zurück, wird er auf FALSE angewendet gibt er TRUE zurück.
4.2.3 Vergleichsoperatoren
Ein Vergleichs Operator wird verwendet, um zwei Argumente mathematisch miteinander zu Vergleichen. Wenn die Argumente dem Vergleich entsprechen liefert der Operator TRUE zurück, wenn die Argumente dem Vergleich nicht entsprechen liefert er FALSE zurück. [4]
Die folgenden Vergleichsoperatoren sind Bestandteil seit der Version 1.0:
Operator Beschreibung Mathematik
4.2.3.1 equal to
gleich =4.2.3.2 not equal to
ungleich ≠4.2.3.3 less than
kleiner als <4.2.3.4 less than or equal to
kleiner oder gleich ≤4.2.3.5 greater than
größer als >4.2.3.6 greater than or equal to
größer oder gleich ≥4.2.3.7 like is null
Ist NULL NULL4.2.3.8 like is nill
Ist NILL LEER4.2.3.9
between
Zwischen Є […]Tabelle 3: Vergleichsoperatoren
12 4.2.4 Zeit Operatoren
Ein zeitlicher Operator vergleicht, ob ein zeitliches Argument einer zeitlichen Bedingung entspricht. Der zeitliche Operator ist TRUE, wenn die zeitliche Anforderung erfüllt ist, anderenfalls ist der Operator FALSE. [4]
Die Zeitlichen Operatoren werden für den in dieser Arbeit untersuchen Anwendungsbeispiele nicht benötigt. Deshalb sind diese hier nur der Vollständigkeit wegen aufgeführt.
Die folgenden Operatoren sind Bestandteil seit der Version 2.0:
Operator Beschreibung des Operators
4.2.4.1 After
Nach einem Zeitpunkt4.2.4.2 Before
Vor einem Zeitpunkt4.2.4.3 Begins
Begin einer Zeitspanne4.2.4.4 BegunBy
Zeitpunkt ist Beginn einer Zeitspanne4.2.4.5 TContains
Zeitspanne enthält Zeitspanne4.2.4.6 During
Zeitpunkt ist während einerZeitspanne
4.2.4.7 TEquals
Zeitspannen sind gleich4.2.4.8 TOverlaps
Zeitspannen überlappen sich4.2.4.9 Meets
Zeitspannen trifft Zeitpunkt4.2.4.10 OverlappedBy
Zeitspanne wir von Zeitspanne überlappt4.2.4.11 MetBy
Zeitpunkt trifft Zeitspanne4.2.4.12 EndedBy
Zeitpunkt ist Endpunkt einer Zeitspanne4.2.4.13 AnyInteracts
Jede Art von Interaktion von Zeitspannen und Zeitpunkten Tabelle 4: Zeitliche Operatoren13 4.2.5 Raum Operatoren / Geographische Operatoren
Ein räumlicher Operator bestimmt, ob seine geometrischen Argumente die angegebene räumliche Beziehung befriedigen. Der Operator gibt TRUE zurück, wenn die räumliche Beziehung erfüllt ist. Andernfalls gibt der Operator FALSE zurück. [4]
Es gibt 2 Typen von räumlichen Operatoren, der Binary Spatial Operator und der Distance Operator.
Dem Binary Spatial Operatoren wird eine Geometrie übergeben anhand derer das Filterkriterium auf die Datenbasis angewandt wird. Das kann in Form einer Geometrie (gml:Geometry) oder eines Umschlages (gml:Envelope) realisiert werden.
Die Distance Operatoren benötigen neben der Geometry außerdem einen MeasureType der die in den Operator einfließende Distanz repräsentiert.
Zu den Distance Operatoren gehören die Operatoren DWithin und Beyond die anderen im Filter Encoding Standards spezifizierten Operatoren gehören zu den Binary Spatial Operatoren.
Im Folgenden sind die räumlichen Operatoren aufgelistet, die seit der Version 1.0 Bestandteil des Filter Encoding Standards sind. Die in den Abbildungen visualisierten oder in den Beispielen dargestellten räumlichen Filteroperatoren geben den Wahrheitswert TRUE zurück:
14
4.2.5.1.1 Equal
Abbildung 1: Operator Equal
Der Equal Operator gibt den Wert TRUE zurück, wenn die Search Geometrie und die Target Geometrie übereinstimmen.
4.2.5.1.2 Disjoint
Abbildung 2: Operator Disjoint
Der Disjoint Operator gibt den Wahrheitswert TRUE zurück, wenn sich die Geometrie Objekte nicht weder schneiden noch berühren.
15
<Filter>
<Disjoint>
<PropertyName>Geometry1</PropertyName>
<gml:Envelope
srsName="http://www.opengis.net/gml/srs/epsg.xml#63266405">
<gml:lowerCorner>13.0983 31.5899</gml:lowerCorner>
<gml:upperCorner>35.5472 42.8143</gml:upperCorner>
</gml:Envelope>
</Disjoint>
</Filter>
4.2.5.1.3 Touches
Abbildung 3: Operator Touches
Der Touches Operator gibt den Wert TRUE zurück, wenn sich die Search und Target Geometrie berühren.
16
4.2.5.1.4 Within
Abbildung 4: Operator Within
Der Within Operator gibt den Wahrheitswert TRUE zurück, wenn die Search Geometrie die Target Geometrie vollständig umschließt.
Zu beachten ist ein Spezialfall, wenn bei der Verwendung von primitiver Objekt Geometrie [7] der Equal Operator den Wahrheitswert TRUE zurück gibt, dann gibt auch Within den Wahrheitswert TRUE zurück. Bei der Verwendung von komplexer Objekt Geometrie gibt der Within Operator FALSE zurück, obwohl Equal Operator den Wahrheitswert TRUE zurückgibt.
<Filter>
<Within>
<PropertyName>WKB_GEOM</PropertyName>
<gml:Polygon name="1" srsName="EPSG:63266405">
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:posList>-98.5485,24.2633 ...</gml:posList>
</LinearRing>
</outerBoundaryIs>
</Polygon>
</Within>
</Filter>
17
4.2.5.1.5 Overlaps
Abbildung 5: Operator Overlaps
Der Overlaps Operator gibt den Wahrheitswert TRUE zurück, wenn sich die Search und Target Geometrie überlappen.
“This example encodes a spatial filter that identifies all features that overlap a polygonal area of interest.” [4]
<Filter>
<Overlaps>
<PropertyName>Geometry</PropertyName>
<gml:Polygon srsName=
"http://www.opengis.net/gml/srs/epsg.xml#63266405">
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:posList> … </gml:posList>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</Overlaps>
</Filter>
[4]
18
4.2.5.1.6 Crosses
Abbildung 6: Operator Crosses
Der Crosses Operator gibt den Wahrheitswert TRUE zurück, wenn sich Search und Target Geometrie kreuzen.
4.2.5.1.7 Intersects
Abbildung 7: Operator Intersects
Der Intersects Operator gibt den Wahrheitswert TRUE zurück, wenn sich die Se- arch Geometrie und Target Geometrie schneiden.
19
4.2.5.1.8 Contains
Abbildung 8: Operator Contains
Der Contains Operator gibt den Wahrheitswert TRUE zurück, wenn die Target Geometrie die Search Geometrie einschließt.
<Filter>
<Contains>
<PropertyName>iso:BoundingBox</PropertyName>
<gml:Envelope>
<gml:lowerCorner>9.2 48</gml:lowerCorner>
<gml:upperCorner>13.2 50</gml:upperCorner>
</gml:Envelope>
</Contains>
</Filter>
20
4.2.5.1.9 DWITHIN (within a specified distance)
Abbildung 9:Operator DWithin
Der Dwithin Operator gibt den Wahrheitswert TRUE zurück, wenn sich die Target Geometrie innerhalb der angegebenen Distanz zur Search Geometrie befindet.
<fes:Filter
xmlns:fes="http://www.opengis.net/fes/2.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/fes/2.0 http://schemas.opengis.net/filter/2.0.0/filterAll.xsd http://www.opengis.net/gml/3.2
http://schemas.opengis.net/gml/3.2.1/gml.xsd">
<fes:DWithin>
<fes:ValueReference>geometry</fes:ValueReference>
<gml:Point gml:id="P1" srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>43.716589 -79.340686</gml:pos>
</gml:Point>
<fes:Distance uom="m">10</fes:Distance>
</fes:DWithin>
</fes:Filter>
[6]
21
4.2.5.1.10 Beyond (beyond a specified distance)
Abbildung 10:Operator Beyond
Der Beyond Operator gibt den Wahrheitswert TRUE zurück, wenn sich die Target Geometrie außerhalb der angegebenen Distanz zur Search Geometrie befindet.
4.2.5.1.11 BBOX
Abbildung 11: Operator BBOX
Der BBOX Operator (Bounding Box Operartor) gibt den Wahrheitswert TRUE zurück, wenn sich die Target Geometrie innerhalb der Search Geometrie befindet.
22
Die Besonderheit bei diesem Operator ist, dass die Search Geometrie immer ein rechteckiges Polygon ist.
<Filter>
<BBOX>
<PropertyName>Geometry</PropertyName>
<gml:Envelope srsName=
"http://www.opengis.net/gml/srs/epsg.xml#63266405">
<gml:lowerCorner>13.0983 31.5899</gml:lowerCorner>
<gml:upperCorner>35.5472 42.8143</gml:upperCorner>
</gml:Envelope>
</BBOX>
</Filter>
4.2.6 Object Identifiers (ID)
Eine ID soll eine eindeutige Kennung für eine Instanz einer Ressource im Rahmen des Web-Services darstellen. Ein Identifier Element kann als Prädikat in einem Filter Ausdruck verwendet werden, um ein Objekt eindeutig zu identifizieren.
4.3 Anwendung der FE nach aktuellem Stand der Technik
Der Filter Encoding Standard ist universell einsetzbar, das zeigt die Zahl der verschiedenen Applikationen und Systeme die ihn verwenden. Der FE wird vielfach in komplexen Geoinformationssystemen, Web Services und Clientanwendungen angewendet.
Im Folgenden ist eine Auswahl an bestehende Applikation beschrieben, in denen der OGC Filter Encoding Standard bereits erfolgreich in unterschiedlichem Umfang umgesetzt wurde.
4.3.1 WFS Filter Encoding im MapServer 6.2
MapServer ist eine in C implementierte Open Source Rendering Engine für Geodaten. Der MapServer wird bei komplexen Anwendungen im GIS-Bereich eingesetzt. Das Filter Encoding wird im GetFeature Request des Web Feature Services verwendet.
23
Die folgenden Filter sind für den MapServer Version 6.3 umgesetzt:
Feature Set Feature
Spatial Capabilities
Equals
Disjoint
Touches
Within
Overlaps
Crosses
Intersects
Contains
DWithin
BBOX
Scalar Capabilities
Logical Operators
And
Or
Not
Comparison Operators
PropertyIsEqualTo (=)
PropertyIsNotEqualTo (<>)
PropertyIsLessThan (<)
PropertyIsGreaterThan (>)
PropertyIsLessThanOrEqualTo (<=)
PropertyIsGreaterThanOrEqualTo (>=)
PropertyIsLike
PropertyIsBetween (range)
Tabelle 5: Filtertypen Mapserver 6.3
24 4.3.2 ArcGIS
ArcGIS ist eine Plattform für die Entwicklung von Anwendung zu Verwendung von geographischen Analysen.
Die folgende Tabelle gibt einen Überblick über die verschiedenen ArcGIS Produkte die den FE Standard unterstützen:
Filter Encoding 1.0 ArcIMS 9.2, 9.3, 10
ArcGIS for Desktop 9.2, 9.3, 10 ArcGIS Data Interoperability 9.2,
9.3, 10
GIS Portal Toolkit 3.1, 9.3 ArcGIS for Server Geoportal Extension, Versions 9.3.1, 10
Filter Encoding 1.1 ArcGIS for Server 9.3, 10
ArcGIS for Desktop 9.3, 10 ArcGIS Data Interoperability 9.3, 10
GIS Portal Toolkit 3.1, 9.3 ArcGIS for Server Geoportal Extension, Versions 9.3.1, 10 Tabelle 6: Umsetzung des FE in den Produkten von ArcGIS
Zur Verwendung des Filter Encoding Standards in ArcGIS 9.3 wurde eine Reihe von Filtern mit verschiedenen Funktionalitäten implementiert. WFS Services, die mit ArcGIS Server erstellt wurden, verwenden die OGC OpenGIS Filter Encoding Implementation Specification (FE) Version 1.1.
Diese räumlichen Filter wurden in ArcGIS umgesetzt:
Geometry Spatial Logical Comparison Sort
Envelope BBOX And EqualTo SortBy
Point Equals Or NotEqualTo
25
MultiPoint Disjoint Not LessThan MultiCurve Intersects GreaterThan
MultiSurface Crosses LessThanOrEqualTo
Touches GreaterThanOrEqualTo
Within Like
Contains Between
Overlaps NullCheck
Tabelle 7: Filterfunktionen in ArcGIS 9.3 und 10
4.3.3 OpenPOIMap
„Mitte März 2012 wurde die Webmapping-Applikation "OpenPOIMap" (Beta) freigeschaltet! OpenPOIMap befasst sich mit der Visualisierung von Point-of- Interests (POIs) aus OpenStreetMap-Daten sowie mit deren Integration in andere Systeme. Points-of-Interests (POI) sind "Punkte von Interesse", also wichtige Punkte in einer kartierten Welt.“ [7]
„Technisch gesehen ist OpenPOIMap eine Webapplikation und ein Webservice zur Nutzung von Points-of-Interests (POI) aus OpenStreetMap-Daten in GIS. Die Daten stammen von der 'Enhanced OpenStreetMap Database One' (EOSMDBOne). Die Software basiert auf dem FeatureServer und PostGIS.
Der Web Feature Service (WFS) Version 1.0.0 von OGC unterstützt auch das Filter Encoding (FE) in der Version 2.0.0 (FE von OGC).“ [7]
Die OpenPOIMap bietet die Möglichkeit die Logischen und Vergleichsoperatoren auf eine Datenbank mit POI-Daten anzuwenden. Als räumlicher Operator wird hier der Kartenausschnitt vermutlich anhand eines BBOX Operators verwendet. Die zeitlichen Operatoren werden nicht unterstützt.
26 5 Analyse des Standards anhand personalisierter Karten
Im folgendem wird analysiert, welche Stärken und Schwächen der Filter Encoding Standard aufweist. Diese Arbeit beschränkt sich dabei auf Anwendungsfälle zur Erstellung von personalisierten Karten.
Anhand von 3 definierten Anwendungsbeispielen, die im Umfeld der personalisieren Karten auftreten können, werden die Filterfunktionen miteinander kombiniert, um den Anwendungsfall bestmöglich zu erfüllen.
Bei den Beispielen handelt es sich um Abfragen von POI Daten die zur Darstellung auf der personalisierten Karte benötigt werden. Die Abfragen werden als XML Request an einen Web Feature Service (WFS) gestellt.
Anschließend wird ein Konzept erstellt, welches die Umsetzung der Filterfunktionen in einem Client mit einer einfachen generischen Benutzer- Schnittstelle (Generic User Interface GUI) ermöglichen soll.
5.1 Personalisierte Karte
Eine personalisierte Karte beinhaltet neben den relevanten topographischen Rahmenbedingungen Objekte oder Sachverhalte aus der natürlichen Umwelt, aus dem Wirtschafts-und Sozial-bereich oder der menschlichen Gesellschaft die der Person besonders wichtig sind.
5.2 Web Feature Service
Der OGC Web Feature Service Standard (WFS) definiert Schnittstellen und Operationen für die Abfrage und das Editieren von räumlichen Vektordaten.
Die Funktion eines WFS Dienstes liegt in der Bereitstellung von Objekten mit geometrischen und simplen Daten. Der Zugriff auf einen WFS-Server erfolgt mittels Http-Protokoll, per Http-Request. Die Antworten des Servers werden per XML zurückgegeben. Ein einfacher WFS-Server stellt mindestens drei Operationen bereit. Die erste Operation lautet „GetCapabalities“. Als Antwort auf diese Abfrage werden alle möglichen Operationen sowie Typen von Objekten (FeatureTypes), die
27
der WFS-Server bereitstellt, in einem XML Dokument ausgegeben. Mit der Operation „DescribeFeatureType“ werden Details zu einem bestimmten Objekttyp angefordert. Das Resultat dieser Anfrage ist ein Schema-Dokument, in dem Elemente und Elementtypen des angeforderten Objektes aufgelistet werden. Mit der Operation „GetFeature“ werden Objekte(Features) vom Server angefordert und diese in einer FeatureCollection, ebenfalls als XML Dokument zurückgegeben.
Zusätzliche zu diesen Basisoperationen gibt es die Operation „LockFeature“, die ein Objekt für den weiteren Zugriff sperrt sowie „Transaction“, mit dem eine Modifikation eines Objektes auf dem Server möglich ist.
Abbildung 12: WebFeatureService (WFS)
Die Kommunikation zwischen Client und Service gestaltet sich nach einem üblichen Schema. Der Client fragt mit dem GetCapabilties Request nach den Fähigkeiten des WFS und die angebotenen Feature Types. Darauf aufbauend kann mit dem DescribeFeatureType Request die Struktur der einzelnen Feature Types eingesehen werden. Dadurch kann mit dem GetFeature Request eine spezielle Instanz eines Features angefordert werden. Alternativ kann bei einem WFS mit Schreibzugriff der Transaction oder der LockFeature Request durchgeführt werden.
28 5.3 Analyse der Filterfunktionen anhand der Anwendungsbeispiele
Um die Stärken und Schwächen des Filter Encoding Standards herauszufinden wurden Anwendungsfälle gesucht anhand derer der Standard auf seine Verwendbarkeit überprüft wird. Die Features für die personalisierten Karten werden von einem WFS abgefragt und in einer topografischen Karte dargestellt.
Die relevanten Features sollen mit einem einzelnen GetFeature Request abgefragt werden. Diese Einschränkung soll die Stärken und Schwächen des Filter Encodings aufdecken soll.
Im ersten Schritt der Analyse werden die zur Verfügung stehenden Operatoren betrachtet und eine Liste der in Frage kommen Filterfunktionen erstellt.
Im Zweiten Schritt werden die Räumlichen- und Vergleichsoperatoren mit Hilfe der Logikoperatoren miteinander verknüpft. Im letzten Schritt der Filteranalyse wird die XML Syntax des kombinierten Filters erstellt.
29
5.3.1 Anwendungsbeispiel 1: Radfahrer POI im Umkreis um Route
30
Abbildung 13: Anwendungsbeispiel 1 © OpenStreetMap-Mitwirkende [8]
Ein begeisterter Fahrradfahrer möchte eine Karte mit seiner geplanten Tour durch Points of Interrest (POIs) veredeln. Dazu möchte er alle POIs im Abstand von 2 km zu seiner geplanten Route, ausgenommen Tankstellen die benötigt er als Fahrradfahrer nicht, anzeigen lassen.
Die POIs müssen allerdings auch mit dem Rad erreichbar sein. Deshalb sollten geprüft werden, ob die POIs über Wege mit dem Rad erreichbar sind. Demnach werden Verbindungen über Autobahnen, Schnellstraßen und Schienen ausgeschlossen.
5.3.1.1 Filterfunktionen zur Umsetzung
Bei diesem Beispiel handelt es sich um einen komplexen Zusammenhang zwischen der Radtour und den zu selektierenden Objekten.
Sie sollen sich innerhalb eines gewissen Abstands zu einem Line String befinden und von einer bestimmten Kategorie sein. Außerdem kommt noch eine weitere Bedingung dazu. Die Objekte sollen an weiteren Line Strings liegen, die mit dem Line String der Tour topologisch verbunden sind.
Auf die Liste der in Filterfunktionen für dieses Anwendungsbeispiel wird als erstes ein Buffer gesetzt. Im Filter Encoding Standard wird dieser durch den Dwithin Operator realisiert. Als Abstand wir hier 2000m benötigt, um dem Beispiel entsprechen zu können.
Außerdem ergibt sich aus der Bedingung, dass keine Tankstellen dargestellt werden sollen, ein Vergleichsoperator der die Tankstellen ausschließt als notwendigen Filter.
Die dritte Bedingung, dass die POIs über Radwege zu erreichen sind können mit dem FE nicht abgebildet werden. Der Filter Encoding Standard bietet keine Möglichkeit topologische Zusammenhänge abzufragen.
5.3.1.2 Liste der Filterfunktionen
• Räumlicher Operator:
o Dwithin Filter: Route wird als Line String übergeben, o Distance 2000m
31
• Vergleichsoperator:
o POI != Tankstelle
• Topologische Zusammenhänge können nicht analysiert werden
• Lediglich der Straßentyp also die Radwege können gefiltert werden
5.3.1.3 XML Syntax des Filters
<Filter>
<And>
<DWithin>
<PropertyName>WKB_GEOM</PropertyName>
<Distance unit=”m”>2000</Distance>
</DWithin>
<PropertyIsNotEqualTo>
<PropertyName>POI_TYPE</ProtertyName>
<Literal>Tankstelle</Literal>
</PropertyIsNotEqualTo>
</And>
</Filter>
5.3.1.4 Fehlende Funktionalität
Wie in Abschnitt 5.3.1.1 schon angedeutet kann die dritte Bedingung, des Anwendungsbeispiels, welche die POIs auf per Radweg Erreichbare einschränkte, nicht vollständig im Filter Encoding Standard abgebildet werden.
Um diese Bedingung vollständig abzubilden würden folgende Funktionalitäten benötigt:
Topologische Abfrage oder Netzanalyse:
Eine Funktion oder Operator, welcher einen Pfad zwischen zwei Punkten finden kann. Dieser Pfad kann wiederum bestimmten Bedingungen unterworfen sein. In unserem Beispiel, dass es sich um den Typ Radweg handeln muss.
Möglichkeit über eine Menge von Objekten zu iterieren:
Ein Operator mit dem man über eine Menge von Objekten (FeatureCollection) iterieren kann. Damit auf jede Geometrie bestimmte Filter oder Funktionen angewendet werden können. Eine weitere Funktionalität dieses Operators sollte es sein, nur die Objekte zurückzugeben, die die den Filterkriterien entsprechen oder die Funktion TRUE zurückgibt.
32
Diese beiden Funktionalitäten werden benötigt, um aus der Menge von POI im Anwendungsbeispiel diejenigen zu selektieren, die über Radwege erreichbar sind.
5.3.2 Anwendungsbeispiel 2: Tankstellen vor der Grenze
Abbildung 14: Anwendungsbeispiel 2 © OpenStreetMap-Mitwirkende [8]
Ein Autofahrer möchte wissen, welches die letzten 2 Tankstellen vor der Grenze sind, damit er sich noch eine Vignette für das Nachbarland kaufen kann, bevor er über die Grenze fährt.
5.3.2.1 Filterfunktionen zur Umsetzung
Dieses Beispiel schien zuerst einfach. Es erwies sich bei der Analyse als auch beim Aufbau des Filters nicht als trivial.
Die Autobahn auf der der Autofahrer fährt, wird als Line String dem Filter DWithin mit einer Distanz von 500 m übergeben. Damit wird sichergestellt, dass die Tankstellen an der Autobahn liegen.
33
Der nicht triviale Teil des Anwendungsbeispiels ist die Bedingung die letzten 2 Tankstellen. Diese Bedingung kann nicht vollständig erfüllt werden. Das resultiert, daraus, dass man nicht bestimmen kann von welchem Geografischen Ort aus in der Datenbank gesucht werden soll. Die Anzahl Ergebnisse lässt sich sehr wohl auf 2 begrenzen, aber es kann nicht sichergestellt werden, dass diese 2 Ergebnisse die beiden sind, die der Grenze am nächsten sind.
Um dem Anwendungsfall bestmöglich abzubilden wir hier ein weiterer Dwithin Filter implementiert, der eine Distanz von 50 km um die Grenz definiert.
So kann man sicherstellen, dass die letzten Tankstellen vor der Grenze als Ergebnis zurückgegeben werden nicht aber Ihre Anzahl. Die schien aber dem Anwendungsfall am besten zu entsprechen.
5.3.2.2 Liste der Filterfunktionen
• Räumlicher Operator:
o Dwithin Filter: Autobahn Feature wir übergeben,
• Distance 500m für POI Suche
o Dwithin Filter: Grenze Feature wir übergeben,
• Distance 50000m für POI Suche
• Vergleichsoperator:
o POI = Tankstelle
34 5.3.2.3 XML Syntax des Filters
<fes:Filter
xmlns:fes="http://www.opengis.net/fes/2.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/fes/2.0 http://schemas.opengis.net/filter/2.0.0/filterAll.xsd http://www.opengis.net/gml/3.2
http://schemas.opengis.net/gml/3.2.1/gml.xsd">
<And>
<fes:DWithin>
<fes:ValueReference>WKB_GEOM</fes:ValueReference>
<gml:LineString gml:id="A8"
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>47.800 12.185</gml:pos>
<gml:pos>47.841 12.487</gml:pos>
<gml:pos>47.826 12.815</gml:pos>
<gml:pos>47.772 12.977</gml:pos>
</gml:LineString>
<fes:Distance uom="m">500</fes:Distance>
</fes:DWithin>
<fes:DWithin>
<fes:ValueReference>WKB_GEOM</fes:ValueReference>
<gml:LineString gml:id="Grenze"
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>47.849 13.005</gml:pos>
<gml:pos>47.769 12.940</gml:pos>
<gml:pos>47.725 12.900</gml:pos>
<gml:pos>47.723 13.014</gml:pos>
</gml:LineString>
<fes:Distance uom="m">50000</fes:Distance>
</fes:DWithin>
<PropertyIsEqualTo>
<PropertyName>POI_TYPE</ProtertyName>
<Literal>Tankstelle</Literal>
</PropertyIsEqualTo>
</And>
</fes:Filter>
5.3.2.4 Fehlende Funktionalität
Um dieses Anwendungsbeispiel vollständig abbilden zu können, müsste der Filter Encoding Standard um eine weitere Funktionalität ergänzt werden:
Sortieroperator zur Sortierung nach dem Abstand von Objekten:
Ein Operator oder eine Funktion die die Ergebnisse eines Dwithin Filters nach dem Abstand zum Suchobjekt filtern kann.
Die notwenige Funktionalität würde es ermöglichen die Ergebnisse nach dem
35
Abstand zur Grenze zu sortieren. Mit dieser Funktionalität und eine Begrenzung auf 2 Ergebnisse könnte das Anwendungsbeispiel vollständig abgebildet werden.
5.3.3 Anwendungsbeispiel 3: Toiletten bei Sehenswürdigkeiten
Abbildung 15: Anwendungsbeispiel 3 © OpenStreetMap-Mitwirkende [8]
Eine Familie mit Kindern macht einen Ausflug in eine fremde Stadt. Da die Kinder immer viel Durst haben und deshalb oft auf die Toilette müssen wird eine Karte benötigt, die alle öffentlichen Toiletten im Stadtgebiet auflistet, die in der Nähe von Sehenswürdigkeiten sind.
36 5.3.3.1 Filterfunktionen zur Umsetzung
In diesem Beispiel treten andere Hindernisse auf als in den beiden vorherigen Beispielen. Hier werden Objekte gesucht die sich in der Nähe von anderen Objekten befinden. Diese Art von Abfrage geht nur, wenn die Sehenswürdigkeiten bekannt sind und dem Filter als Position übergeben werden können. Auch dann müsste man für jede Sehenswürdigkeit eine Abfrage generieren. Also muss nach einer Alternative gesucht werden.
Wenn man das Zentrum der Stadt kennt, kann man durch den Dwithin Operator alle Objekte in einem bestimmten Radius filtern. In diesem Fall die Toiletten. Um dem Anwendungsbeispiel noch mehr zu entsprechen könnte man zusätzlich auch noch die Sehenswürdigkeiten filtern, damit der Nutzer der Karte die Möglichkeit hat die Toiletten in der Nähe von Sehenswürdigkeiten anhand der Karte ausfindig zu machen.
5.3.3.2 Liste der Filterfunktionen
• Räumlicher Operator:
o DWithin Filter: Im Stadtzentrum o Distanz 4000m
• Vergleichsoperator:
o POI = Sehenswürdigkeiten o POI = Toiletten
37 5.3.3.3 XML Syntax des Filters
<Filter>
<And>
<DWithin>
<PropertyName>WKB_GEOM</PropertyName>
<gml:Point gml:id=”Center” srsName=”EPSG::4326”>
<gml:pos>52.5170 13.3890</gml:pos>
</gml:Point>
<Distance unit=”m”>2000</Distance>
</DWithin>
<PropertyIsEqualTo>
<PropertyName>POI_TYPE</ProtertyName>
<Literal>Tankstelle</Literal>
</PropertyIsEqualTo>
<PropertyIsEqualTo>
<PropertyName>POI_TYPE</PropertyName>
<Literal>Sehenswürdigkeiten</Literal>
</PropertyIsEqualTo>
</And>
</Filter>
5.3.3.4 Fehlende Funktionalität
Wie im Abschnitt 5.3.1.4 beschrieben, würde auch in diesem Fall eine weiter Funktionalität benötigt, um das Anwendungsbeispiel vollständig abbilden zu können.
Möglichkeit über eine Menge von Objekten zu iterieren:
Ein Operator mit dem man über eine Menge von Objekten (FeatureCollection) zu iterieren und auf jede dieser Geometrien bestimmte Filter oder Funktionen anwenden kann. Eine weitere Funktionalität dieses Operator sollte es sein, nur die Objekte zurückzugeben, die die den Filterkriterien entsprechen oder die Funktion TRUE zurückgibt.
38 6 Konzeptionelle Umsetzung der Filter in einem Web Client
Entgegen der ursprünglichen Idee einer praktischen Umsetzung wurde zugunsten einer konzeptionellen Umsetzung entschieden. Denn die konzeptionelle Umsetzung in Form von Grafiken und Mockups kann die Ergebnisse dieser Arbeit genauso gut veranschaulichen als es eine praktisch umgesetzte Lösung könnte.
Aufgrund des fehlenden Mehrwertes einer praktischen Umsetzung wurde zugunsten des konzeptionellen Entwurfs entschieden.
6.1 Architektur des Web Clients
Als Kartengrundlage für den Web Client könnte OpenStreetMap (OSM) verwendet werden. Die Datenbank von OSM steht seit 2012 unter der „Open Database Licence (ODbL) 1.0" zur Verfügung. „Die ODbL unterscheidet hierbei zwischen der Nutzung der Daten als Datenbank und der Herstellung eines Werkes ("Produced Work") aus den Daten, z.B. einer auf Papier gedruckten Karte. Abgeleitete Datenbanken dürfen hierbei nur unter der ODbL weiter verteilt werden, bei "Produced Works" wird nur vorgeschrieben, dass ein entsprechender Quellenhinweis angebracht wird und gegebenenfalls eine zur Herstellung verwendete abgeleitete Datenbank in einer geeigneten Form zur Verfügung gestellt wird.“ [8]
Als technologische Grundlage für den Entwurf des Web Clients dient ein Web Feature Server der lesend auf die Kartendatenbank zugreift und ein Minimum an Räumlichen- und Vergleichsoperatoren unterstützt.
Die Architektur und Kommunikation des Web Clients gestaltet sich wie in Abbildung 16 dargestellt. Der Web Feature Service hat Zugriff auf die Datenbank mit den OSM Daten. Der Web Client schickt GetCapabilities und GetFeature Abfragen an den Web Feature Service und bekommt die Antworten zurück.
39
Abbildung 16: Architektur der Client Server Kommunikation
Die GetCapabilities Anfrage benötigt der Web Client, um Auswahllisten für den QueryBuilder der Oberfläche zu füllen.
Durch die GetCapabilities Anfrage werden die zur Verfügung stehenden Features ermittelt und Filter Operatoren ermittelt.
Die Informationen über die Einzelnen Features werden mit einem DescribeFeature Request abgefragt um die Auswahl der Attribute zu füllen.
6.2 Design des User Interface
Die Oberfläche des Web Clients ist bewusst einfach gehalten. Wie in der Abbildung 17 zu sehen ist, befindet sich im oberen Bereich der linken Seite ein Textfeld zur Eingabe von Adressdaten, um die Karte im Kartenfenster rechts zu zentrieren.
Darunter befindet sich der QueryBuilder, mit dessen Hilfe sich die Filterfunktionen für die GetFeature Anfrage einfach aufbauen und kombinieren lassen.
40
Abbildung 17: Web Client User Interface Übersicht
Der QueryBuilder besteht aus 2 Registerkaten. Die erste Registerkarte (Abbildung 18, linker Teil) dient zur Auswahl des FeatureTypes der gefiltert werden soll.
Durch einen GetCapabilities Request werden die zur Verfügung stehenden FeatureTypes abgefragt und in die CheckBoxGroup eingelesen. Hier hat der Benutzer dann die Möglichkeit genau einen Feature Type, auszuwählen. Möchte der Benutzer mehre verschiedene Feature Types in der Karte filtern, müssen die Abfragen nach einander ausgeführt werden.
41
Abbildung 18: Web Client Feature Auswahl
In der 2. Registerkarte kann der Filter anhand von Auswahlfeldern und Textfeldern zusammengestellt werden.
Im oberen Teil der Registerkarte stehen die räumlichen Operatoren zur Verfügung.
Im unteren Teil die nicht räumlichen, also die Vergleich- und Zeitoperatoren.
Ein Entwurf des QueryBuilder (Abbildung 19) sah ein analoges Design für die räumlichen und nicht räumlichen Operatoren vor. Bei genauerer Betrachtung stellte sich heraus, dass die Räumlichen Operatoren damit nicht abgedeckt werden können. Die räumlichen Operatoren benötigen zusätzliche Schaltflächen für die Auswahl der Geometrie Objekte aus der Karte oder für den Import aus Datei im WKT Format. (siehe Abbildung 20)
Für die nicht räumlichen Operatoren werden im Auswahlfeld Property die Attribute des gewählten Feature Types zur Auswahl gestellt. Das Auswahlfeld Condition beinhaltet die Filteroperatoren, die Filteroperatorzeile wird durch ein Textfeld Value das den Filterwert aufnimmt der über die Tastatur einzugeben ist auf.
42
Die einzelnen Operatoren können anhand der Logikoperatoren, die sich am Ende jeder Filteroperatorzeile befinden, verknüpft werden. Außerdem können die Verknüpfungen durch Klammern ergänzt werden, die vor und nach jeder Filteroperatorzeile eingefügt werden können. (siehe Abbildung 20)
Abbildung 19: Web Client QueryBuilder Entwurf
Das finale Design (Abbildung 20) des QueryBuilder sieht eine Änderung der Filteroperatorzeile vor, je nachdem, welcher räumliche Operator gewählt wird.
In der Abbildung 20 sind beispielhaft 2 spezielle räumliche ausgewählt.
43
Abbildung 20: Web Client QueryBuilder
Wählt der Benutzer keinen räumlichen Filter aus, sondern betätigt, direkt nach der Auswahl des Feature Types, die GetFeature Schaltfläche auf dem ersten Registerblatt, so wird ein räumlicher Default Filter verwendet. Bei diesem Default Filter handelt es sich um einen BBOX Filter dessen Ausmaße der aktuellen Ansicht der Karte entspricht. Ist der Ausschnitt des Kartenfensters zu groß bekommt der Benutzer die Meldung er solle einen Filter setzen oder einen kleineren Kartenausschnitt wählen.
Die räumlichen Operatoren DWithin und Beyond haben eine Sonderstellung, denn außer einer Geometrie ist die Eingabe eines Distanzparameters erforderlich.
Wir einer der beiden Operatoren im Auswahlfeld Condition gewählt, wird die Filteroperatorenzeile um eine Textfeld, für die Eingabe der Distanz, ergänzt.
6.3 Grenzen des QueryBuilders
Bei den Zeitlichen Operatoren ist der QueryBuilder bei Zeiträumen auf obere und untere Grenzen beschränkt. Für jede dieser Grenzen des Zeitraums muss jeweils eine Filteroperatorzeile angelegt und mit AND verknüpft werden. Das heißt die
44
zeitlichen Operatoren die sich auf Zeiträume beziehen werden nicht unterstützt.
Die Begründung für diese Einschränkung ist „Keep It Simple“. Der Benutzer hat nur die Möglichkeit ein Datum im Textfeld einzugeben. Diese Form der zeitlichen Angabe ist ihm geläufig und er muss sich keine Gedanken über die Formatierung von Zeiträumen machen.
7 Schlussfolgerung / Ausblick
Zusammenfassend kann der OGC Filter Encoding Standard als ein Werkzeug beschreiben werden das zur Filterung von Daten universell einsetzbar ist. Er hat seine Grenzen, wenn es um die Filterung von topologischen Zusammenhängen geht.
Dennoch kann er auch für komplexe Abfragen die auf Vergleichen oder räumlichen Beziehungen beruhen angewendet werden.
Weitere sinnvolle Erweiterungen für den Filter Encoding Standard wären das iterative bearbeiten von einer Menge von Objekten und eine Sortierfunktion für die Entfernung von der Ausgangsgeometrie.
45 8 Abbildungsverzeichnis
Abbildung 1: Operator Equal 14
Abbildung 2: Operator Disjoint 14
Abbildung 3: Operator Touches 15
Abbildung 4: Operator Within 16
Abbildung 5: Operator Overlaps 17
Abbildung 6: Operator Crosses 18
Abbildung 7: Operator Intersects 18
Abbildung 8: Operator Contains 19
Abbildung 9:Operator DWithin 20
Abbildung 10:Operator Beyond 21
Abbildung 11: Operator BBOX 21
Abbildung 12: WebFeatureService (WFS) 27
Abbildung 13: Anwendungsbeispiel 1 © OpenStreetMap-Mitwirkende [8] 30 Abbildung 14: Anwendungsbeispiel 2 © OpenStreetMap-Mitwirkende [8] 32 Abbildung 15: Anwendungsbeispiel 3 © OpenStreetMap-Mitwirkende [8] 35 Abbildung 16: Architektur der Client Server Kommunikation 39
Abbildung 17: Web Client User Interface Übersicht 40
Abbildung 18: Web Client Feature Auswahl 41
Abbildung 19: Web Client QueryBuilder Entwurf 42
Abbildung 20: Web Client QueryBuilder 43
46 9 Tabellenverzeichnis
Tabelle 1: Wahrheitswerte von AND 10
Tabelle 2: Wahrheitswerte von OR 10
Tabelle 3: Vergleichsoperatoren 11
Tabelle 4: Zeitliche Operatoren 12
Tabelle 5: Filtertypen Mapserver 6.3 23
Tabelle 6: Umsetzung des FE in den Produkten von ArcGIS 24
Tabelle 7: Filterfunktionen in ArcGIS 9.3 und 10 25
47 10 Abkürzungsverzeichnis
WFS Web Feature Service
OSM Open Street Map
OGC Open Geospatial Consortium
FE Filter Encoding Standard
GML Geography Markup Language
48 11 Literaturverzeichnis
[1] The Open Geospatial Consortium, "OGC Open Geospatial Consortium," 2013.
[Online]. Available: http://www.opengeospatial.org. [Accessed März 2013].
[2] Open Geospatial Consortium Inc., OpenGIS Web Feature Service 2.0 Interface Standard, 2010.
[3] OSGeoLive, „OSGeoLive,“ 2013. [Online]. Available:
http://live.osgeo.org/de/standards/fe_overview.html. [Zugriff am März 2013].
[4] Open GIS Consortium Inc., Filter Encoding Implementation Specification 1.0.0, 2001.
[5] Open Geospatial Consortium Inc., OpenGIS® Filter Encoding Implementation Specification 1.1.0, 2005.
[6] The Open Geospatial Consortium, OpenGIS Filter Encoding 2.0 Encoding Standard, 2.0 Hrsg., 2010.
[7] The International Organization for Standardization (ISO), ISO 19107 Geographic information — Spatial, 2003.
[8] Hochschule für Technik Rapperswil, „OpenPOIMap – GISpunkt HSR,“ 05 2013.
[Online]. Available: http://giswiki.hsr.ch/OpenPOIMap. [Zugriff am 05 2013].
[9] © OpenStreetMap-Mitwirkende, „OpenStreetMap,“ [Online]. Available:
http://www.openstreetmap.org/copyright. [Zugriff am 30 Mai 2013].
[10] The Open Geospatial Consortium, OGC Reference Model, 2011.
[11] The International Organization for Standardization (ISO), ISO 19108 Geographic information — Temporal schema, 2002.
