Strukturelle und technische Voraussetzungen für einen SOS Michael Bauer Workshop 13.10.2011 Hamburg Hallo, Wir haben ja in vergangenen meetings festgestellt, dass eine nähere Betrachtung des Themas Sensor Web Enablement im Kontext von MRSL sinnvoll wäre. Schließlich handelt es sich bei den zu berichtenden Daten um Messwerte und die Sensor Web Enablement Standards wurden entwickelt um, von Sensoren gemessen Daten bereitzustellen. Deshalb will ich jetzt kurz zeigen was meiner Meinung nach getan werden muss, um diese Technik in den Bereichen einzusetzen, die MRSL betreffen. Und dann bleibt zum Schluß die Fragen, welche bei welchen Daten dies dann auch wirklich sinnvoll ist.

Sensor Web Enablement (SWE) Sensor Observations Service (SOS) Webservice zur Abfrage von Sensordaten Observations & Measurements (O&M) Standard zur Kodierung von Beobachtungen und Messungen Sensor Model Language (SensorML) Beschreibungssprache für Sensoren, Sensordaten und Messverfahren Transducer Model Language (TML) Sensor Planning Service (SPS) Sensor Alert Service (SAS) Web Notification Services (WNS) Sensor Web Enablement oder auch kurz SWE ist eine Gruppe von Standards des OGC. Für uns in erster Linie interessant ist der Sensor Observations Service (SOS).

Sensor Observation Service OGC Service, vergleichbar mit Web Feature Service (WFS) Operationen optimiert für Messdaten Nicht nur für Sensordaten Operationen: getCapabilities getObservation describeSensor getFeatureOfInterest Der für uns mit Abstand der interessantes der Dienste im Bereich Sensor web Enablement ist der SOS. Am besten kann man ihn mit dem WFS vergleichen. Man stellt eine Anfrage und bekommt Daten zurück. getObservation: Stellt Messdaten bereit Die Ergebnisse lassen sich filtern nach: Sensoren Time Parametern Ort Etc.

Architektur Was bedeutet das für die Architektur? Nun, bislang haben wir vor allem einfach und starre Architekturen – im simpelsten Fall so etwas hier. Natürlich sieht keiner unserer Knoten derart aus, aber für die Datenbereitstellung ist dies der Basisfall. Im allereinfachsten Fall ersetzen wir einfach den WFS durch einen SOS und gut ist. In der Praxis wird der SOS aber neben wohl dem WFS stehen. Später können dann auch etwas elegantere und flexiblere Modelle entstehen, aber momentan ist das noch etwas Zukunftsmusik.

Einer der Haken ist die Datenbankstruktur Einer der Haken ist die Datenbankstruktur. Ein SOS erwartet eine gewisse Struktur, die eben O&M entsprechen muss. Allerdings ist das Schema nicht zwangsläufig bei jedem Produkt gleich. Im Gegenteil, eigentlich… ;) Allerdings sind ja die Daten eh schon in einer Datenbank und je nachdem ob alle nötigen Infos bereits in der Datenbank vorhanden sind, kann man einen entsprechenden View für den SOS generieren. Ich beschreibe zuersteinmal die Beobachtung, also um welches objekt es sich handelt und dann den Wert des Parameters. Dies bedeutet, dass ich einem Sensor auch mehrere Parameter und gemessene Werte zuweisen kann. Darüber hinaus gibt es auch plugins und tools um aus Datenbankschemata gängiger Datenbanken so etwas zu generieren, um tiefe Eingriffe in gewachsene Datenstrukturen zu vermeiden.

Sensor Observation Service Time Layer Sensors Sensor in Time Timeseries In einem visuellen Beispiel bedeutet dies: Zeichnung erklären – 3 dimensionale Speicherung (2d Raum + Zeit) Layer herausziehen Zeitserien Durchstich „3D Bounding Box“ – Audehnung + Zeitraum

Technische Anforderungen Geringer IT Aufwand 1 Standardserver Datenbank bzw. Datenbankview SOS-Dienst

Observations & Measurements Observations & Measurements (O&M) Standard zur Kodierung von Beobachtungen und Messungen ISO 19156 “An Observation is an action whose result is an estimate of the value of some property of the feature-of-interest, at a specific point in time, obtained using a specified procedure.” (Cox 2008) „Der Standard „Observations and Measurements“ (O&M) stellt ein Modell sowie Daten-format zur Kodierung und Beschreibung von Beobachtungen und Messungen bereit.“ (GDI-DE Architekturkonzept 2.0) Observations & Measurements (O&M) ist ein Standard zur Kodierung von Beobachtungen und Messungen. Auch vom ISO übernommen unter unter Nr. 19156 zu finden. O&M wurde als Anwendungsschema von GML entwickelt und fügt sich somit nahtlos in die OGC Standardkette ein. Hier zwei Definitionen – einmal eine wissenschaftliche und dann eine ganz angewandte und naheliegende, die aus dem GDI Architekturdokument entnommen ist. Grundlegendes Konzept von O&M ist die Beobachtung bzw. Messung, durch welche ein Phänomen mit einem Wert verknüpft wird. Wobei Observation hierbei für die Messung steht und Phänomen für den gemessenen Parameter.

O&M und INSPIRE O&M relevant für verschieden INSPIRE Themen Verwendung in: D2.9 Guidelines for the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRE Annex II and III data specification development O&M wurde übrigens auch von der INSPIRE Community als relevant erkannt und wird für verschiedene Themen in Annex II und III angewendet werden. Die Diskussionen im Detail sind da noch am Laufen, aber unter anderem werden entsprechende FeatureTypes dafür hinzukommen.

Architektur Hier nochmal eine Folie die ich von Prof. Resch von der Uni Osnabrück geklaut habe, an die wir bei der BAW uns bei der Sensor Fusion, also der Zusammenführung von mehreren SOS anlehnen und in Zukunft enger kooperieren werden.

Angewandte Beispiele Pegel Online Aber jetzt hab ich sie genug gelangweilt mit der Theorie – was können wir denn damit genau anfangen: Das hier wohl bekannteste Beispiel ist Pegel Online. Hier mit der Zeitreihenvisialisierung für den Pegel St. Pauli. Aber man muss ja nicht zwangläufig die Zeitreihen ansehen. Durch die Bereitstellung von Pegelonline in Form eines SOS, kann ich die Daten auch in andere Anwendungen einbinden.

Angewandte Beispiele Heidelberg 3D Hier ein Beispiel von Heidelberg 3D, wo ebenfalls die Sensordaten aus PegelOnline verwendet wurden um die entsprechenden Pegel im 3D Modell einzublenden und bei Klick ein Label mit den entsprechenden Daten anzuzeigen. In diesem Fall werden der Wert, also der Wasserstand, die ID des Sensors und die Zeit angegeben.

Angewandte Beispiele Cosyna Wir haben ja eben schon viel über Cosyna gehört und aufgrund der vielen Eingangsdaten auch aus Sensoren die multiple Parameter messen, ist das natürlich ein gutes und richtiges Einsatzgebiet für SOS.

Beispiel – BAW Vision Ich hab dieses Beispiel mal BAW –Vision genannt, da dies zeigt wie wir uns den Einsatz von SWE in BAW zukünftig vorstellen. Also was haben wir vor und wieso nehmen wir dazu einen SOS? Zeichnung erklären.

Dateneignung Geeignet für „Rohdaten“ Echte Messwerte oder aufbereitete Daten Daten einer gewissen zeitlichen Aggregationsstufe Ungeeignet für Stark aggregierte Daten Geringe Datenmengen

Pro & Contra Pro Contra Flexible Architektur Arbeitsaufwand Nahtlose Integration in OGC Infrastrukturen Komplexere Architektur Standardisierte Datenstruktur Vereinfachte Datenharmonisierung Was also spricht für und was gegen den Einsatz von SWE in der MDI bzw. für die einzelnen Aufgaben der MDI? Was muss ich bedenken? Arbeitsaufwand – neue Technologien einzuführen bedeutet immer einen gewissen Arbeitsaufwand. Ich denke eine der Aufgaben innerhalb des Forschungsprojekts MDI muss sein, hier einfache Lösungen zu finden.