Übersicht:
Favoritenliste:
Favoritenseiten
Ihre Favoritenliste enthält derzeit keine Seiten. Sie fügen dieser Liste Seiten hinzu, indem Sie im Menü Extras der angezeigten Seite Favorit selektieren. |
Grundlage für diese Seite ist das Dokument "erweiterter Steckbrief zum Themenbereich "Geophysik" der INSPIRE Datenspezifikation Geologie", Herausgeber: Leibniz-Institut für Angewandte Geophysik (LIAG), Regierungspräsidium Freiburg | Landesamt für Geologie, Rohstoffe und Bergbau
BEZIEHT SICH AUF TECHNICHAL GUIDELINE VERSION 3.0
Der Steckbrief soll geodatenhaltenden Stellen eine schnelle Entscheidungsgrundlage bezüglich der INSPIRE-Betroffenheit ermöglichen. Im Steckbrief wird das jeweilige INSPIRE-Thema grob erläutert, zu anderen INSPIRE-Themen abgegrenzt, die Objektarten beschrieben und eine Fragen- und Antwortensammlung zusammengestellt.
Der Steckbrief soll zunächst nicht dazu dienen, die Prozesse der Umsetzung zu beschreiben. Dafür sollte die Datenspezifikation, bzw. die fachlichen Leitfäden zur technischen Umsetzung, herangezogen werden.
Vorbemerkungen
Für das Verständnis der DSGP werden Grundkenntnisse in der Universal Modeling Language (UML) vorausgesetzt. Dazu gibt es eine Fülle von Literatur. Eine Einführung in UML befindet sich z. B. in TUW-OOM (2012) oder in ANDRAE et al. (2009)
Im Folgenden werden die Begriffe Klasse und Objektklasse synonym verwendet, ebenso Objekt und Klasseninstanz. Synonym sind ebenfalls Geoobjektklasse und Feature Type sowie Geoobjekt und Feature.
Die Umsetzung der DSGP von UML in XML wird von dem in INSPIRE als Standard-UML Modellierer festgelegten Enterprise Architect© (EA) (SPARX-EA 2014) übernommen. Die UML-Anwendungsschemata liegen daher auf der INSPIRE-Website primär als EA-Dateien vor. Deren Umsetzung ist im Prinzip nicht Gegenstand der DSGP. Obwohl alle DS auch als XML-Schemata verfügbar sind bzw. sein werden, ist für deren Verwendung ein Grundverständnis der Abbildung von UML-Klassen-diagrammen in XML-Schemata hilfreich. Außerdem werden im DSGP-Erweiterungsschema (siehe unten) diverse Beispiele in XML wiedergegeben. Empfohlen wird hierzu JECKLE (2001) Die DSGP (wie auch die DS aller anderen INSPIRE-Themen und -Unterthemen) liegt nicht nur als PDF-Textdokument INSPIRE-GEOLOGY (2013) vor, sondern auch in maschinenlesbarer Form unter INSPIRE-CUML (2013). Unter Themes stehen dort die Schemata und Klassendefinitionen der INSPIRE-Themen und -Unterthemen, unter Foundation Schemas die Definitionen der standardisierten Basis-Schemata (insbesondere der Geodatenstandards aus der ISO-TC211-Familie) und unter Generic Conceptual Model (GCM) zusätzliche themenübergreifend genutzte Basisklassen (Foundation Classes). Die Definitionen stehen sowohl im HTML- als auch in EA/XMI-Format zur Verfügung. Die Einsichtnahme in die BasisSchemata und -klassen in das GCM ist häufig notwendig, weil deren Attribute in Klassen der beiden Geophysik-Modelle vererbt und in den UML-Diagrammen der DSGP nicht immer sichtbar sind.
In den UML-Diagrammen, den textlichen Erläuterungen und den Feature-Katalogen der DSGP sind vielen Klassennamen 2- oder 3-stellige Kürzel vorangestellt. Diese Klassen sind Basisklassen aus den Schemata der von INSPIRE intensiv genutzten ISO-TC211-Familie (ANDRAE et al. 2009). Die Kürzel beziehen sich auf Pakete (Packages), d. h. Gruppen zusammengehöriger Klassendefinitionen aus den TC211-Schemata. Tab. 1 zeigt eine Übersicht der in der DSGP referenzierten Pakete. In den UML-Diagrammen der DSGP sind den Klassennamen häufig die ausgeschriebenen Paketnamen vorangestellt.
Die nativen Klassen der INSPIRE-DS sind häufig Unterklassen der Basisklassen oder durch Assoziationen, Aggregationen und Kompositionen mit Basisklassen verbunden. Bei der Ermittlung der mit Daten zu versorgenden Klassenattribute müssen daher auch die Basisklassen und deren Feature-Kataloge berücksichtigt werden, siehe INSPIRE-CUML (2013)
In den UML-Diagrammen der INSPIRE-DS werden Ober- / Unterklassenbeziehungen (Vererbungen) nicht immer durch Pfeile mit einer geschlossen umrandeten weißen Spitze dargestellt. Stattdessen wird manchmal auch der Name der Oberklasse oben rechts in das Kästchen der Unterklasse geschrieben
Die UML-Diagramme der INSPIRE-DS werden über Stereotypen (Stereotypes) semantisch erweitert, indem Klassen, Attribute, Assoziationen, Rollen und Pakete typisiert werden. Stereotyp-Angaben stehen in << … >> eingefasst ganz oben im betreffenden Diagrammkästchen. Die im den INSPIRE-UML-Profil zugelassenen Stereotypen sind im Generic Conceptual Model GCM (INSPIRE-GCM 2013) unter 9.6.3 aufgelistet. In der DSGP verwendet werden abernur <<featureType>>, <<codeList>>, <<type>>, <<dataType>> und <<metaclass>>als Stereotypen für Klassen und <<voidable>> als Stereotyp für Attribute.
Keine Angaben
Keine Angaben
Wie in diversen anderen INSPIRE-Themen wird auch in der Geophysik zwischen einem verbindlich vorgeschriebenen Kernmodell (Core Model, DSGPC) und einem optionalen Erweiterungsmodell (Extended Model, DSGPE) unterschieden.
Anm.: Der Begriff Modell sollte an dieser Stelle nicht mit einem geophysikalischen Modell im Sinne von Abschnitt "Modelle und zugehörige Klassen" verwechselt werden!
Das DSGPC beinhaltet Informationen zur Verfügbarkeit und Lokation von geophysikalischen Datenobjekten, beschränkt sich also auf Metadaten. Diese beziehen sich auf:
Das in den INSPIRE-Durchführungsbestimmungen (INSPIRE-1253 2013) verbindlich vorgeschriebene Kernmodell der Geophysik beschränkt sich somit auf Metadaten (ISO 19115 und andere) für Messungen und Kampagnen ausgewählter Geophysik-Methoden. Diese objektbezogenen Metadaten müssen von den Dataset-bezogenen Metadaten (die ja lt. INSPIRERoadmap bereits jetzt verbindlich bereitzustellen sind) unterschieden werden!
Komplexe Anwendungsfälle erfordern die Bereitstellung von über Metadaten hinausgehenden Detailinformationen, insbesondere von Mess- und Auswertungsergebnissen. In diesem Fall kommt das Erweiterungsmodell zur Anwendung.
Inhalte des Geophysik-Erweiterungsmodells sind:
Das Konzept der Named Pairs (frei wählbare Paare aus Parameternamen und Inhalten) in O&M ermöglicht eine flexible Anwendbarkeit des Erweiterungsmodells auf beliebige Geophysik-Methoden. Dazu bedarf es aber methodenspezifischer Attributfestlegungen in Form von Attributkatalogen, wie sie in den erweiterbaren Codelisten
ansatzweise schon existieren (INSPIRE-GEOLOGY 2013).
Das DSGPE ist – wie auch die Erweiterungsmodelle anderer INSPIRE-Themen – nicht Bestandteile der INSPIRE-Durchführungsbestimmungen (INSPIRE-1253-2013) und daher noch inoffiziell und unverbindlich. Die Bedeutung des Erweiterungsmodells wird in den späteren Phasen von INSPIRE erwartungsgemäß zunehmen, zumal weite Teile der Geophysik bisher nicht durch einheitliche Datenstandards abgedeckt werden. Das Gewinnen von Erfahrungen aus Piloteinsätzen des Erweiterungsmodells und die gemeinsame inhaltliche Weiterentwicklung des O&M-Gerüsts für die diversen Methoden der Geophysik sind aber bereits jetzt wichtige Aufgaben für die geophysikalische Fachwelt.
Hier noch eine wichtige Klarstellung: Die DSGE sehen speziell für Bohrlochmessungen (Logs) auch eine Speicherung im geologischen Anwendungsschema vor, siehe Klasse MappedInterval in INSPIRE-Geology (2013), Seite 27. Dies bezieht sich aber nur auf stratigraphische oder lithologische Interpretationen von Bohrlochmessungen. Die zugrundeliegenden Mess-Logs (z. B. Gamma Ray) gehören nichtsdestoweniger in das geophysikalische Anwendungsschema.
Das Kernmodell besteht aus zwei fundamentalen Klassen: GeophMeasurement (geophysikalische Messung) und Campaign (Kampagne), siehe Abb. 1.
Die abstrakte Klasse GeophObject (Abb. 1) beschreibt die allgemeinen Kenndaten einzelner Geoobjekte. Im Kernmodell ist sie die übergeordnete Klasse von GeophMeasurement und damit auch von GeophStation, GeophProfile und GeophSwath. Im Erweiterungsmodell wird sie für weitere Zwecke eingesetzt. Attribute von GeophObject sind:
distributionInfo: Information zum Datenerhalt (z. B. Beschreibung der Bestellprozedur, URL zum Dateistandort usw.), Datentyp = MD_Distributor aus dem ISO-19115- Metadatenstandard.
Die Angabe der URL einer Messdatei bietet die Möglichkeit, außer den messungsspezifischen Metadaten auch „harte“ Messdaten zu übermitteln, ohne das dazu das DSGPE eingesetzt werden muss
Nähere Angaben zu den aus der ISO-19115 stammenden Attributetypen befinden sich in INSPIRE-MDIR (2013), INSPIRE-CUML (2013) und ISO-TC211 (2011)
GeophObject wird aus der abstrakten Klasse SF_SpatialSamplingFeature der ISO 19156 Observation and Measurement (O&M) abgeleitet (INSPIRE-O&M 2011). Die reichhaltigen Möglichkeiten von SF_SamplingFeatures zur Abbildung der „realen“ Welt stehen daher prinzipiell auch in GeophObject und dessen Unterklassen zur Verfügung, auch wenn sie im Kernmodell nicht ausgenutzt werden. Unter anderem wird das Attribute shape von SF_SpatialSamplingFeature geerbt und an die Unterklassen von GeophObject weitervererbt. Shape ist nicht zu verwechseln mit projectedGeometry, obwohl beide vom Datentyp GM_Object sind. In shape wird die Geometrie der Messung beschrieben, falls diese von projectedGeometry abweicht. Das ist insbesondere dann der Fall, wenn die Messgeometrie mehr als 2-dimensional ist (z. B. bei der 3D-Seismik).
Die abstrakte Klasse GeophMeasurement leitet sich aus GeophObject ab und beschreibt die Metadaten geophysikalischer Messungen. Zusätzlich zu den Attributen von GeophObject enthält sie:
Die Klassen GeophStation, GeophProfile, und GeophSwath (Abb.1 und Abb. 2) werden aus GeophMeasurement abgeleitet und beschreiben Messungen mit jeweils punkt-, profiloder flächenbezogener Ausdehnung.
GeophStation beschreibt eine auf einen Einzelpunkt bezogene Messung. Attribute sind stationType (Art der geophysikalischen Station, siehe erweiterbare Codeliste stationTypeValue, enthält die Einträge gravityStation, magneticStation, VES sounding u. a.) und stationRank (ggf. Rang einer fest installierten geophysikalischen Station innerhalb eines hierarchisch aufgebauten Messnetzwerks, siehe Werteliste stationRankValue).
Wichtig: Für die Gravimetrie und Magnetik wird GeophStation auf Basispunkte und Feststationen beschränkt, um die Erzeugung einer großen Anzahl von Metadatensätzen zu vermeiden.
Für eigentlich nicht stationsbezogene Einzelpunktmessungen, z. B. VES = 1DGeoelektrik, ist stationRank sinnlos und wird mit inapplicable belegt (in XML-Notation: <ge_gp:stationRank xsi:nil="true" nilReason="inapplicable"/>). Das von SF_SpatialSamplingFeature geerbte Attribut shape wird per Constraint auf den Untertyp GM_Point (entspricht GML:Point) eingeschränkt
Die Klasse Campaign wird verwendet, um Mengen gemeinsam erhobener geophysikalischer Messungen (im Erweiterungsmodell auch von Prozessierungen und von Interpretationen) als Kampagnen zu dokumentieren.
Die abstrakte Klasse GeophObjectSet beschreibt gemeinsame Kenndaten von Mengen zusammengehöriger Geoobjekte. Im Kernmodell ist sie die übergeordnete Klasse von Campaign, im erweiterten Modell wird sie auch für andere Zwecke eingesetzt.
GeophObjectSet umfasst die folgenden Attribute (siehe Abschnitt: Messungen und zugehörige Klassen)
Campaign umfasst zusätzlich zu denen von GeophObjectSet geerbten (Abb. 3) die folgenden Attribute:
Das Erweiterungsmodell sieht vor, dass mittels GML-Coverages (Kap. 5.7) aggregierte Mess- und Auswertungsergebnisse (z. B. 2D/3D-Grids) an Kampagnen „angehängt“ und auf dieser Ebene bereitgestellt werden. Das ist insbesondere im Fall von Massendatenproduzierenden Geophysikmethoden (Gravimetrie, Magnetik u. a.) sinnvoll, weil eine Datenbereitstellung auf der Ebene von Einzelmessungen viel zu aufwendig und inperformant wäre.
Die im Kernmodell mindestens zu berücksichtigenden geophysikalischen Methoden ergeben sich aus den Inhalten der Codelisten stationTypeValue, profileTypeValue, stationRankValue und swathTypeValue. Zusammengefasst sind dies:
Zwecks Vermeidung einer „Überflutung“ des Web mit INSPIRE-Metadaten erfolgt im DSGPC methodenabhängig eine Beschränkung auf bestimmte Objekttypen, z. B. in der Gravimetrie auf stationsbezogene Messungen (siehe Spalte stationRank) oder in der Aerogeophysik auf Kampagnen (Fluggebiete).
Im Folgenden wird das XML-Dokument einer Bohrlochmessung (Log) gemäß Kernmodell wiedergegeben. An den beiden gelb markierten Positionen wird als optionale Zusatzleistung die URL eines (fiktiven) Dienstes zur Datenbereitstellung angegeben. Hinweis: Bohrlochmessungen werden im Geophysik-Schema als vertikale Profile aufgefasst.
Der größte Unterschied zwischen dem Kernmodell (DSGPC) und dem Erweiterungsmodell (DSGPE) der Geophysik sind die zusätzlichen Elemente für einen harmonisierten Austausch von über Metadaten hinausgehenden Beobachtungsergebnissen (Observation Results) zu Messungen und Interpretationen bzw. Modellen. Dies wird gewährleistet durch die Kombination von Klassen aus O&M (INSPIRE-O&M 2011) und GCM (INSPIRE-GCM 2013) sowie einiger weniger daraus abgeleiteter spezifisch geophysikalischer Klassen. Das Geophysik-Erweiterungsmodell ist also als Erweiterung des Kernmodells aufzufassen. Das DSGPE bietet in seiner aktuellen Form den Datenbereitstellern viele Lösungsalternativen und Freiheiten für die Abbildung ihrer Daten auf das Schema.
Wie bereits erwähnt ist das Erweiterungsmodell der Geophysik in der jetzigen Phase von INSPIRE noch inoffiziell und unverbindlich. Die Beschreibung des Erweiterungsmodells befindet sich daher nur im Annex D2 von INSPIRE-GEOLOGY (2013).
In der Praxis werden geophysikalische Untersuchungen oft in Kampagnen und Projekten organisiert. Ein großes Explorationsprojekt kann mehrere unterschiedliche Kampagnen umfassen. Jede Kampagne kann von einer anderen Institution ausgeführt werden und unterschiedliche Karten, Reports und Datensätze liefern. Die Kontrolle des Gesamtprojektes obliegt einer verantwortlichen Institution. Für die Modellierung dieser Hierarchie können die Klassen Campaign aus dem DSGPC und die zusätzliche Klasse Project aus dem DSGPE verwendet werden (Abb. 4).
Die Klasse Project wird, ebenso wie Campaign, aus der abstrakten Klasse GeophysicalObjectSet abgeleitet, erbt also die Attribute inspireId … largerWork, mittelbar auch shape. Als einziges natives Attribut besitzt sie principalInvestigator (Hauptverantwortlicher des Projektes).
Der Eintrag Interpretation in der Codeliste CampaignTypeValue kommt erst im Erweiterungsmodell zum Einsatz, da hier Prozessierungen und Modelle an Kampagnen angehängt werden können.
Zur Minimierung des technischen Overheads ist es ist in vielen Fällen sinnvoll, Kollektionen von Messdaten und Modellelementen (z. B. in Form von Grids) an Kampagnen und Projekte anstatt Einzeldaten an Messungen und Modelle anzuhängen. Das betrifft u. a. die Methoden Gravimetrie und Magnetik. Da Project und Campaign beide aus der O&M-Klasse SF_SpatialSamplingFeature abgeleitet sind, ist das durch den Einsatz von O&M-Coverages problemlos möglich. Eine Auflistung der für die Geophysik relevanten Coverage-Typen befindet sich in Tab. 3
Im DSGPE wird die Klasse OtherGeophMeasurement aus GeophMeasurement abgeleitet und erhält ergänzend das Attribut measurementType (Art der geophysikalischen Messung, siehe Abb. 5), zu dem die Codeliste OtherMeasurementType gehört. Die Metadaten einer Messung im DSGPE sind also identisch mit denen im DSGPC. Die erweiterbare Codeliste OtherMeasurementType dient zur Ausdehnung des Kernmodells auf zusätzliche geophysikalische Methoden, enthält bisher aber nur den Eintrag 3DMultielectrodeDC. Die Anbindung von Detailinformationen (Messergebnisse und spezifische Stammdaten) an GeophMeasurement bzw. OtherGeophMeasurement erfolgt über O&M, siehe Kap. 5.4 – 5.6.
Innerhalb des DSGPE entspricht die abstrakte Klasse GeophModel (Abb. 6) einem Modell, also per Definition einem Geoobjekt, das die Verteilung (geo)physikalischer Eigenschaften innerhalb des beobachteten räumlichen Bereichs repräsentiert. Ein Modell ist das Endprodukt einer Verarbeitungskette Messdaten → Prozess → Prozess … → Modell (Prozesse siehe Kap. 5.5) und als solches nicht für Geophysiker, sondern auch für Spezialisten anderer Bereiche nutzbar
Entsprechend der Verwendung der O&M-Terminologie kann die UML-Assoziation sampledFeature von GeophModel immer mit einer oder mehreren Instanzen von GeophMeasurement verbunden sein.
GeophModel umfasst neben den von der Superklasse GeophObject geerbten Attributen (z. B. shape) nur das [1..*]-Attribut relatedMeasurement, das die INSPIRE-IDs der für das Modell verwendeten geophysikalischen Messung(en) enthält.
Ebenso wie Messungen werden geophysikalische Modelle auf der Basis der Beprobungsgeometrie kategorisiert. Daher besitzt die Klasse GeophModel die folgenden vier Unterklassen: CurveModel, SurfaceGridModel, SolidGridModel und OtherGeophModel. Dazu gehören die Codelisten CurveModelTypeValue bzw. SurfaceGridModelTypeValue bzw. SolidGridModelTypeValue (Abb. 6). Per Constraint wird das Attribute shape auf die GML-Typen GM_Curve bzw. GM_Surface bzw. GM_Solid beschränkt.
Die Klasse OtherGeophysModel kommt zum Einsatz, falls die Modellgeometrie keiner dieser Alternativen entspricht (Bsp.: invertierte geoelektrische Sektion, bestehend aus PolygonShapes).
Über das geerbte Attribut largerWork können Modelle an Kampagnen, Projekte und Prozessierungen angehängt werden.
Die Anbindung von Detailinformationen an GeophModel inkl. der Unterklassen erfolgt über O&M, siehe Kap. 5.4 – 5.6.
Wegen der manchmal schwierigen Abgrenzung zwischen Mess- und Modelldaten (GeophMeasurement vs. GeophModel) gibt es auf Seite 290 von INSPIRE-GEOLOGY (2013) entsprechende Hinweise. Z. B. werden in der Seismik ein Profil als Messung (GeophProfile), eine Tiefensektion als Modell (SurfaceGridModel) und eine Zeitsektion als „Zwitter“, aber letztlich doch als Modell (CurveModel) eingestuft.
Die folgenden Definitionen (http://de.wikipedia.org/wiki/Sensor_Observation_Service) sind für das Verständnis von Kap. 5.5 notwendig.
Attribute einer Beobachtung sind:
Eine ausführlichere Beschreibung von O&M befindet sich in Kap. 4 von INSPIRE-O&M (2011).
Abb. 7 stellt die Einbettung vom O&M im GCM (INSPIRE GCM 2013) dar. Diese ist noch nicht spezifisch für die Geophysik und kann so auch von anderen INSPIRE-Themen genutzt werden.
Zum Verständnis von Abb. 7 ist der Unterschied zwischen einem Assoziationsnamen (mittig auf einer Assoziationslinie platziert) und einem Rollennamen (am Pfeilende einer Assoziation platziert) in UML wichtig: Der Assoziationsname identifiziert die Assoziation, während sich über den Rollennamen – ausgehend von der Ursprungsklasse – die über die Assoziation (in Pfeilrichtung) verlinkten Objekte der Zielklasse ansprechen lassen.
Bsp.: Aus einer Instanz von OM_Observation heraus lässt sich über den Rollennamen observedProperty auf die Eigenschaft zugreifen, die mit dieser Beobachtung untersucht wird. ObservedProperty wird somit wie ein Attribut von OM_Observation behandelt. Das „+“ vor dem Rollennamen macht observedProperty zu einem auch außerhalb der Klasse OM_Observation sichtbaren „Attribut“. Auch die am Pfeilende einer Assoziation angegebene Kardinalität (im obigen Beispiel 1) ist mit der eines Klassenattributs vergleichbar.
Im O&M Schema des GCM (Abb. 7) entsprechen sich die O&M-Terme und die GCMBasisklassen wie folgt:
Die Assoziationen zwischen diesen GCM-Klassen sind ebenfalls in Abb. 7 enthalten. Besonders wichtig sind:
Die aus der O&M-Klasse OM_Process abgeleitete Klasse Process (Abb. 7) umfasst die Attribute name, identifier, documentation und responsibleParty, die zusammen den Benutzer über das Verfahren und die nachweisführende Behörde informieren. Das Attribut Name von Process beschreibt den Typ des Prozesses; zugeordnet ist die Codeliste GeophProcessNameValue (S. 312 – 314 der DSGP) mit den Namen der wichtigsten Prozesstypen, z. B. VES oder 2DSeismicProcessing. Das multiple Attribut processParameter enthält die Namen und Inhalte der prozesstypischen Parameter. Dazu gehört die hierarchische und erweiterbare Codeliste GeophProcessParameterNameValue auf den Seiten 314 – 331 der DSGP; beispielhafte Codelisteneinträge sind VES_ARR_TYPE, AB_MAX, AB_DIST und MN_DIST für die 1D-Gleichstromgeoelektrik oder SEISM_METHOD, SEISM_WAVE_TYPE und SAMP_RATE für die Seismik.
Ein Objekt der Klasse Process beinhaltet nur die Namen und Beschreibungen der Prozessparameter, während OM_Observation die eigentlichen Inhalte der Prozessparameter enthält. Die wichtigsten Attribute wurden bereits unter Kap. 5.4 beschrieben. Zu OM_Observation gehört die erweiterbare Codeliste GeophProcessParameterNameValue.
Das Ergebnis einer Beobachtung (Rollenname result) ist in Abb. 7 vom Datentyp Any, d. h. im INSPIRE-GCM wird wegen der großen Themenbandbreite auf einer XML-Strukturierung vom O&M-Ergebnissen verzichtet; das bleibt also dem Datenanbieter überlassen. Diese Gestaltung von om:result erlaubt es, an dieser Stelle beliebigen XML-Code einzufügen. Anstelle einer solchen Beliebigkeit empfiehlt das DSGPE allerdings, Beobachtungsergebnisse mit SWE und/oder SensorML zu codieren (Kap. 5.6 und 5.7). Eine weitere Möglichkeit ist das Platzieren von GeophResult in om:result, um darin URLs auf externe Ergebnisdateien abzulegen (Kap. 5.8).
Sensor Web Enablement (SWE) ist ein zu TC211 gehöriger, in der ISO 19130 definierter Standard zur Unterstützung von Sensor-Netzwerken. Für den Gebrauch in INSPIRE ist der Begriff des Sensors zu verallgemeinern und durch Prozess zu ersetzen. Für INSPIRE sind insbesondere die folgenden SWE-Komponenten von Bedeutung:
Die SML wird speziell als Mittel zur Beschreibung von Sensoren bzw. Prozessen, ihrer Fähigkeiten und ihrer Eingabe-, Ausgabe- und Verarbeitungsparameter eingesetzt. SML ist dagegen kein Mittel zur Codierung von Beobachtungsergebnissen; dafür ist SWEC vorgesehen. SWEC ist auch für die Darstellung komplex strukturierter Beobachtungsergebnisse geeignet. SWEC ähnelt konzeptionell dem in der Wissenschaft verbreiteten QuasiDatenaustauschstandard Network Common Data Form (NetCDF), ist aber im Gegensatz zu diesem XML-basiert.
SML-Dateien sind wie auch NetCDF-Dateien selbstbeschreibend. Das folgende Beispiel zeigt die SWEC-Darstellung einer zeitabhängigen Wettermessung als Array aus Zeit, Temperatur und Luftdruck:
Ein weiteres Beispiel zeigt die SML-Darstellung eines Prozesses (Messung der Wasserhärte in Gewässern):
Beim Einbetten von SML- und SWEC-Code in das Element om:result einer Beobachtung können prozessbeschreibende Parameter sowohl im O&M-Anteil (OM_Process bzw. Process) als auch im SML-Anteil untergebracht werden. Vom DSGPE wird die vorrangige Verwendung von O&M empfohlen.
Sowohl SML als auch SWEC sind in INSPIRE-O&M (2011) kurz beschrieben; für ein tieferes Verständnis ist die Einsichtnahme in OGC-SWEC (2011) und OGC-SML (2014) notwendig.
Coverages sind ein Sprachkonstrukt innerhalb der Geographic Markup Language (GML), Version 3.2 (ISO 19136) zur Beschreibung der Ausprägungen (Werte, Values) der Eigenschaften raum- und optional zeitbezogener Phänomene, siehe OGC-COV (2010) und INSPIRE-GCM (2013). Typische Beispiele sind Geländehöhen, Niederschlagsmengen usw. Auch zusammengesetzte Eigenschaften (z. B. Temperatur und Salinität eines Fluids) sind zugelassen. Ein Coverage besteht aus einer Menge von solchen Attributwerten, von denen jeder mit einem Element der zum Coverage gehörigen räumlich/zeitlichen Domäne (Spatial/Temporal Domain) verknüpft ist. Typische Domänen sind Punktmengen (z. B. Standorte von Sensoren), Kurvenmengen (z. B. Konturlinien), Grids (z. B. Geländemodelle) usw. Ein kontinuierliches Coverage besteht – im Gegensatz zu einem diskreten Coverage – zusätzlich aus einer Methode zur Interpolation der Werte an Raum/Zeit-Koordinaten, die „zwischen“ den Elementen der Domäne liegen, der sog. Coverage-Funktion (Coverage Function).
Da es sich gezeigt hat, dass reine GML-Coverages für div. Anwendungsbereiche nicht ausreichen, wird in OGC-COV (2010) – entspricht der ISO 19123 – ein erweitertes abstraktes Modell für Coverages definiert. Neu hinzugekommen ist insbesondere das Element rangeType, das Informationen über den Wertebereich eines Coverage enthält. Wie aus Abb. 8 ersichtlich, wird zur Implementierung von rangeType auf die SWEC-Klasse DataRecord zurückgegriffen.
Die Klasse Coverage in Abb. 8 enthält als Attribute die coverageFunction (Datentyp CoverageFunction) und metadata (Datentyp Any). In metadata kann daher beliebiger XML-Code zur Angabe von Metadaten eingefügt werden; das wird aber im DSGPE nicht empfohlen, da dafür bereits geeignete Klassen definiert wurden.
Weitere Klassen im Anwendungsschema sind:
Die abstrakte Klasse Coverage in Abb. 8 wird in mehrere Unterklassen, entsprechend den verschiedenen Coverage-Grundtypen, vererbt (Abb. 9).
Beispiele von Coverage-Typen sind: (http://en.wikipedia.org/wiki/Coverage_data)
Tab. 3 zeigt eine Auflistung der für die Geophysik relevanten Coverage-Typen und ihrer Einsatzbereiche.
Das folgende Beispiel zeigt ein Multipoint-Coverage für gravimetrische Stationsdaten:
Coverages sind das von INSPIRE-GCM empfohlene Mittel zur Darstellung von Beobachtungsergebnissen und Modellinhalten. Auch beim „Anhängen“ aggregierter Messergebnisse (2D/3D-Grids, Tins u. a.) an Kampagnen und Projekte sind Coverages i. d. R. die am besten geeignete Technik.
Ein weiteres wichtiges Argument für die Verwendung von Coverages ist die Verfügbarkeit eines dedizierten Webdienst-Typus, nämlich des Web Coverage Service = WCS zum Transport von Coverages über das Internet, siehe z. B. KORDUAN et al. (2008) und http://de.wikipedia.org/wiki/Web_Coverage_Service).
Bereits die Core-Variante eines WCS erlaubt dabei das Extrahieren von Teilbereichen (z. B. Subgrids) per Trimming oder das Generieren von Schnitten per Slicing. Für die aktuelle Version WCS 2.0 existieren außerdem mehrere standardisierte WCS-Erweiterungen, z. B. unterstützen ein:
Im Gegensatz zu WCS 1.0 kann WCS 2.0 mit allen oben genannten Coverage-Typen umgehen und ist nicht mehr an reguläre Gitter gebunden.
WCSe sind OGC/ISO-normiert (ISO 19123) und daher ein wichtiges Hilfsmittel zum Zusammenführen verschiedener Coverages und zum Aufbau von Portallösungen. Weitere Informationen zu WCS befinden sich z. B. in OGC-WCS (2010), KORDUAN et al. (2008) und in http://de.wikipedia.org/wiki/Web_Coverage_Service.
In INSPIRE sind bisher nur Web Feature Services (WFS) – siehe z. B. INSPIRE-TGDS (2012) und KORDUAN et al. (2008) – als Download-Dienste vorgesehen, WCSe dagegen nicht. Im Rahmen einer späteren INSPIRE-Fortschreibung ist aber damit zu rechnen. Aktuell kann die INSPIRE-konforme Bereitstellung von Coverages daher nur als Predefined Datasets, ggf. unter Verwendung von Atom Feeds (INSPIRE-TGDS 2012) erfolgen.
Ein datengenerierender Prozess (Process) entspricht z. B. der Erfassung von 2D-SeismikDaten. Geeignete processParameter wären in diesem Fall die Beprobungsrate (entspricht Eintrag SAMP_RATE der Codeliste), der Sensorabstand (entspricht SEN_SPACING), der Erfassungsbereich (entspricht CVRG) usw. Die Codeliste GeophProcessNameValue enthält Einträge, die zur Namensgebung von Prozessen (Attribut name von Process) vorgeschlagen werden, z. B. boreholeLogging oder 2DseismicProcessing; siehe INSPIREGEOLOGY (2013) ab Seite 312.
Beim Codieren von Beobachtungsergebnissen hat man die Wahl zwischen den folgenden Techniken:
Zu 1: Nach der INSPIRE-Empfehlung sollten Beobachtungsergebnisse wenn möglich mit den entsprechenden GCM-Coverage-Typen (Tab. 3) codiert werden. Das Coverage wird in diesem Fall direkt in om:result eingeschlossen. Das ist möglich, weil om:result vom Typ Any ist (Abb. 7) und mit beliebigen XML-Inhalten gefüllt werden darf.
Zu 2: Alternativ können Beobachtungsergebnisse mit SWEC und ggf. zusätzlich mit SML codiert werden. Das ist insbesondere dann erforderlich, wenn die Beobachtungsergebnisse nicht ausschließlich Raum/Zeit-Koordinaten haben. Auch in diesem Fall werden die Beobachtungsergebnisse direkt in om:result aufgenommen.
Zu 3: Sehr häufig werden geophysikalische Daten in weit verbreiteten und z. T. sehr komplexen Industriestandardformaten angeboten. Deren Ersatz durch eine XML-Codierung ist aus Akzeptanz- oder speichertechnischen Gründen nicht immer wünschenswert. In solchen Fällen kommt die Klasse GeophResult (Abb. 10) zur Anwendung, um die Daten in eine Beobachtung einzubeziehen. Diese Klasse hat ein multiples Attribut GeophResource, das in einer Instanz von GeophResult beliebig häufig vorkommen darf. GeophResult und GeophResource sind wg. des Fehlens eines Identifikator-Attributs vom Stereotyp <<datatype>>.
GeophResource besitzt zwei Attribute:
O&M-Daten müssen physikalische und geophysikalische Eigenschaftsnamen entweder als Referenz zu den beobachteten Eigenschaften oder als XML, eingebunden in die Beobachtungsergebnisse, enthalten. Für eine solche Referenzierung dient die Codeliste GeophPropertyNameValue, siehe S. 331 – 341 von INSPIRE-GEOLOGY (2013). Im Anhang D2 von INSPIRE-GEOLOGY (2013) befinden sich diverse Beispiele für die Codierung geophysikalischer Daten in O&M.
Als zusätzliches, geschlossenes Beispiel wird im Folgenden das XML-Dokument für die Bereitstellung einer seismischen Messung mit der INSPIRE-ID http://mfgi.hu/inspire/SLN2D_NK-60 wiedergegeben (Quelle: László SŐRÉS, MAFI). Dieses
Dokument entspricht i. W. dem DSGPC. Über eingebettete XML-Tags
<sam:relatedObservation xlink:href="…“> (gelb markiert) wird auf 2 weitere XMLUnterdokumente mit den URLs
verwiesen, in denen zusätzliche Daten per Erweiterungsmodell bereitgestellt werden.
Messdaten und prozessierte Daten werden in je eine Instanz von OM_Observation „verpackt“ und auf separate, miteinander verlinkte XML-Dokumente (1 Hauptdokument und 2 Unterdokumente) verteilt. Diese Zerlegung in Teildokumente bietet u. a. den Vorteil einer besseren Übersichtlichkeit, ist aber nicht zwingend erforderlich.
In (c) sind insbesondere die Links auf mehrere, per URLs bereitgestellte Messdateien von Bedeutung (gelb hinterlegt).
Anmerkung: In der Seismik wäre eine 100%ige O&M-Darstellung der Daten zu seismischen Messungen und Prozessierungen wegen deren Größe und Komplexität unrealistisch. Im Element om:result können aber per linkage-Klausel und URL-Angabe externe Messdateien in gängigen Standardformaten (z. B. in der Seismik SEG-Y) referenziert werden, siehe Seite 297 von INSPIRE-GEOLOGY (2013).
(a) Das folgende Beispiel zeigt die Codierung eines 1D-Schichtmodells aus spezifischen Widerständen mittels eines MultiCurve-Coverage. Zu beachten ist die Trennnung zwischen den Schichtintervallen (gml:multiCurve) und den per Inversion zugeordneten spezifischen Widerständen (gml:rageSet und gml:rangeType).
(b) Diese Beispiel zeigt eine ebenfalls als Multicurve-Coverage codierte Bohrlochmessung. Der umgebende O&M-Anteil wurde der Kürze wegen weggelassen.
(c) Diese Beispiel codiert ebenfalls eine Bohrlochmessung, jedoch unter Verwendung eines Multipoint-Coverage.
Bsp. 7 bezieht die Log-Ergebnisse auf Teufenintervalle (die sich auch überschneiden dürfen), Bsp. 8 dagegen auf einzelne Teufen, also sinngemäß wie bei Verwendung des LAS-Standards (HESLOP et al. 2000). Multipoint-Coverages erzeugen daher einen kompakteren XML-Code und sind für Bohrlochmessungen i. d. R. die bessere Wahl.
Ein aussagekräftiges Beispiel befindet sich auf Seite 303 – 304 von INSPIRE-GEOLOGY (2013). In diesem Beispiel werden die Messparameter ARR_TYP = Elektrodenanordnung und AZM = Azimut des Messprofils einer VES-Messung (Vertical Electrical Sounding, 1Dgeoelektrische Sondierung) mit SML (Element sml:parameters) beschrieben. Die Beschreibung der Ergebnisparameter AB = Abstand der Stromelektroden, MN = Abstand der Spannungselektroden und APP_RES = für (AB, MN) ermittelter scheinbarer spezifischer Widerstand erfolgt ebenfalls mit SML (sml:components), allerdings mit eingebetteten SWEAnteilen (swe:dataArray). Die Abbildung der zu den Ergebnisparametern gehörigen Werte ist dagegen Sache von SWE (swe:values).
Die komplette Detailbeschreibung der Sondierung (exkl. Metadaten), bestehend aus SML - und SWEC-Elementen, befindet sich in einem einzigen -Block. Das komplette, DSGPE-konforme XML-GML-Dokument (hier nicht wiedergegeben) würde diesen Block in (Kap. 5.5) einbetten
Für die Implementierung des DSGPE gibt es die folgenden Lösungsalternativen:
Im einfachsten Fall (s. Bsp. 5) wird die Mess- bzw. Modelldatei in einem herkömmlichen Format per xlink href=“…“ in das DSGPE-Dokument des geophysikalischen Objekts eingebunden. Diese Methode ist z. B. in der Seismik zu empfehlen, wo es mit SEG-Y einen fest etablierten Dateistandard gibt. Ein „Aufbrechen“ der SEG-YStruktur in XML/GML mit dem Ziel einer WFS- Übertragung seismischer Messdaten wäre wegen des großen Datenvolumens ohnehin unrealistisch. Die Beschreibung von Messparametern (Messgerät, Umweltbedingungen usw.) erfolgt unter Einsatz des O&M-Standards (Observation & Measurement), der über sein „Named Pairs“-Konzept die freie Definiton von Parametern erlaubt. Daraus resultiert aber die Notwendigkeit, die Messparameter der verschiedenen geophysikalischen Methoden zu normieren. Im DSGPE konnte diese Aufgabe bisher nur ansatzweise gelöst werden (Codelisten GeophProcessNameValue und GeophProcessParameterNameValue in INSPIREGEOLOGY (2013)). Alternative 1 lässt sich mit relativ geringem Aufwand umsetzen. Sinnvolle Beispiele sind die Seismik (Einbinden von SEG-Y-Dateien) oder die Bohrlochgeophysik (Einbinden von LAS-n-Dateien).
Wie bereits unter Kap. 4.1 und 4.2 erwähnt, ist es auch im DSGPC möglich, außer Metadaten auch „harte“ Messdaten bereitzustellen. Dazu kann unter MD_DistributionInfo die URL einer auf einem Webserver liegenden Messdatei angegeben werden.
Auch bei den Alternativen 3 und 4 wird - zusätzlich zu den Metadaten des DSGPC - O&M zur Beschreibung der Messparameter (Geräteparameter, Umweltbedingungen usw.) verwendet.
Die Wahl zwischen den Alternativen 3 und 4 ist (sowohl in der Geophysik als auch in anderen INSPIRE-Themen) nicht immer einfach. Hinweise dazu befinden sich in INSPIRE-O&M (2011). Insgesamt sind Coverages aber die von den themenübergreifenden INSPIRERahmenbedingungen favorisierte Technik, insbesondere wegen der Verfügbarkeit spezieller Webdienste für einen funktional hochentwickelten Datenzugriff.
Die Datenspezifikationen der Geophysik umfassen ein verpflichtend einzuhaltendes Kernmodell (DSGPC) und ein optionales Erweiterungsmodell (DSGPE). Beide Modelle wurden konsequent auf Basis vorhandener Geodatenstandards konzipiert.
Das per Gesetz verbindliche DSGPC beschränkt sich auf Metadaten zu Messungen (z. B. VES) bzw. Messkampagnen (z. B. Gravimetrie) aus 14 Methoden der Geophysik. Innerhalb des Gesamtthemas Geologie stellt das DSGPC somit nur geringe Anforderungen an die Datentransformation und an die technische Infrastruktur zur Datenbereitstellung. Über eine in den Metadaten einer Messung (MD_DistributionInfo) eingebettete URL können ggf. auch komplette Messdateien übertragen werden.
Das sich im Annex von INSPIRE-GEOLOGY (2013) befindliche DSGPE ist in der aktuellen Phase von INSPIRE unverbindlich. Das DSGPE setzt auf dem DSGPC auf, sieht aber neben der Bereitstellung von Metadaten auch die von „harten“ Messdaten und die von Messparametern (z. B. Angaben zum Messgerät) vor. Außerdem werden auch geophysikalische Modelle, z. B. Inversionsergebnisse, vom DSGPE abgedeckt. Für die Implementierung des DSGPE gibt es die drei Lösungsalternativen
Entsprechende Pro- und Contra-Argumente finden sich unter Kap. 5.10. In allen drei Varianten können beliebige Attribute für Messungen und Modelle verschiedener geophysikalischer Methoden definiert werden. Dies ist bisher erst ansatzweise über die Codelisten GeophProcessNameValue und GeophProcessParameterNameValue in INSPIRE-GEOLOGY (2013) erfolgt und bedarf weiterer Aktivitäten in der geophysikalischen Fachwelt.
Insgesamt hat die TWG dem DSGPE bewusst zahlreiche Freiheitsgrade belassen, um der geophysikalische Fachwelt Gelegenheit zu eigenen Ausgestaltungsvorschlägen zu geben, die in eine spätere Fortschreibung der DSGP eingehen werden.
Die Autoren empfehlen allen datenhaltenden Stellen, die ihre geophysikalischen Daten zum jetzigen Zeitpunkt nicht nur DSGPC-, sondern auch DSGPE-konform anbieten wollen, den Einsatz von Variante (a), insbesondere im Fall der Verfügbarkeit internationaler Datenstandards (z. B. SEG-Y für die Seismik oder LAS für die Bohrlochgeophysik)
<Potentielle Daten und Einrichtungen auflisten>
< Daten und Einrichtungen auflisten, die potentiell nicht zu INSPIRE gehören>
BKG - Bundesamt für Kartographie und Geodäsie DS - Data Specification DSGE - Data Specification Geology DSGP - Data Specification Geology – Subschema Geophysics DSGPC - Data Specification Geology – Subschema Geophysics – Core Model DSGPE - Data Specification Geology – Subschema Geophysics – Extension Model EA - Enterprise Architect FOI - Feature of Interest GCM - Genereric Conceptual Model GDI - Geodateninfrastruktur GDI-DE - Geodateninfrastruktur Deutschland GFM - General Feature Model GML - Geographic Markup Language (ISO 19136) GMR - Geology and Mineral Resources ISO - International Standardisation Organisation JRC - Joint Research Committee von INSPIRE LAS - Log ASCII Standard MAFI - Magyar Állami Földtani Intézet (Ungarischer Geologischer Dienst) O&M - Observation and Measurement (ISO 19156) OGC - Open Geospatial Consortium SWE - Sensor Web Enablement (ISO 19156) SEG-Y - Society of Exploration Geophysicists, Austauschformat (Seismik) SensorML, SML - Sensor Model Language SOS - Sensor Observation Service UML - Unified Modeling Language URI - Uniform Resource Identifier URN - Uniform Resource Name URL - Uniform Resource Locator TWG - Technical Working Group VES - Vertical Electrical Sounding WCS - Web Coverage Service WFS - Web Feature Service XML - Extensible Markup Language XSI - XML Schema Instance
ANDRAE, C., FITZKE, J. & ZIPF, A. (Hrsg.) (2009): OpenGIS essentials, Die Geo-Standards von OGC und ISO im Überblick. – 232pp, Wichmann-Verlag, Heidelberg, ISBN 978-3-87907- 473-0. GDI-DE-REGISTRY (2012): GDI-Registry V1.0. – Abschlussbericht zum Modellprojekt, Geodateninfrastuktur Deutschland, http://www.geoportal.de/SharedDocs/Downloads/DE/GDIDE/Abschlussbericht_Registry_V1.pdf?__blob=publicationFile. HESLOP, K., KARST, J., PRENSKY, S. & SCHMITT, D. (2000): Log ASCII Standard, File Structures. – 43pp, http://www.cwls.org/las/dl/LAS%203%20File%20Structure.pdf. INSPIRE-1253 (2013): EU-Verordnung 1253/2013 der Kommission vom 21. Oktober 2013 zur Änderung der Verordnung (EU) Nr. 1089/2010 zur Durchführung der Richtlinie 2007/2/EG hinsichtlich der Interoperabilität von Geodatensätzen und –diensten. - http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:331:0001:0267:DE:PDF. INSPIRE-CUML (2013): INSPIRE Consolidated UML Model. – http://inspiretwg.jrc.ec.europa.eu/data-model/draft/r4530/. INSPIRE-GCM (2013): INSPIRE DS-D2.5, Generic Conceptual Model, v3.4rc3. – http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.5_v3.4rc3.pdf INSPIRE-GEOLOGY (2013): INSPIRE-DS-D2.8, Data Specifications on Geology – Technical Guidelines. – http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_G E_v3.0.pdf INSPIRE-GESD (2011): INSPIRE DS-D2.7, Guidelines for the encoding of spatial data, v3.3rc2. – http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.7_v3.3rc2.pdf INSPIRE-MDIR (2013): INSPIRE Metadata Implementing Rules – Technical Guidelines based on EN ISO 19115 and EN ISO 19119, V1.3. – http://inspire.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf INSPIRE-O&M (2011): INSPIRE-DS-D2.9, Guidelines for the Use of Observation & Measurements and Sensor Web Enablement-related Standards in INSPIRE Annex II and III data specification development, V1.0. – http://inspire.ec.europa.eu/documents/Data_Specifications/D2.9_O&M_Guidelines_v2.0rc3.p df. INSPIRE-TGDS (2012): Technical Guidance for the implementation of INSPIRE Download Services V3.0. - http://inspire.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_S ervices_3.0.pdf ISO-TC211 (2011): ISO TC211 Harmonized Model. – http://www.isotc211.org/hmmg/HTML/. JECKLE (2001): Von UML zum XML-Schema. – Vortrag auf Konferenz „XML in Action“, April 2001, München, http://www.jeckle.de/files/XMLInActionXSDGenerierung.pdf. KORDUAN & ZEHNER (2008): Geoinformation im Internet, Technologie zur Nutzung raumbezogener Informationen im WWW. – 314pp, Wichmann-Verlag, Heidelberg, ISBN 978-3- 87907-456-3.
OGC-COV (2010): OGC GML Application Schema – Coverages, Open Geospatial Consortium, http://portal.opengeospatial.org/files/?artifact_id=41438&passcode=yxxtfckm7anmjx1jyq0s. OGC-SML (2014): SensorML- Model and XML Encoding Standard, Version 2.0.0. – https://portal.opengeospatial.org/files/?artifact_id=55939. OGC-SWEC (2011): Common Data Model Encoding Standard, V2.0. – Open Geospatial Consortium, http://www.opengeospatial.org/standards/swecommon. OGC-WCS (2010): OGC® WCS 2.0 Interface Standard – Core. - Open Geospatial Consortium, https://www.google.de/?gws_rd=ssl#q=OGC+09-110r3%2C. SPARX-EA (2014): EA © Visual Modeling Software. – Sparx Systems Enterprise Architect ©, http://www.sparxsystems.de/uml/ea-function/. TUW-OOM (2012): Objektorientierte Modellierung – Strukurmodellierung. – TU Wien, Business Informatics Group, http://www.uml.ac.at/wpcontent/uploads/teaching/02_Klassendiagram_Folien.pdf. WIECHMANN, M. (2014): Erläuterungen zum Themenbereich Geophysik der INSPIRE Datenspezifikation Geologie (v3.0) – Version 1 vom 07.08.2014, 12pp, BGR Hannover, http://www.geoportal.de/SharedDocs/Downloads/DE/GDIDE/Steckbrief_Geophysik.pdf?__blob=publicationFile.