Seitenhistorie

1. Ziel des Steckbriefs

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.

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.

2. Definition des Themas

Keine Angaben

3. Abgrenzung zu anderen INSPIRE-Themen

Keine Angaben

4. Inhalt des Themas

4.1 Geologie

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:

• • Messungen für 14 ausgewählte geophysikalische Methoden (airborneGeophysics, sonar usw.) mit Punkt-, Profil- oder Flächenbezug (siehe Tab. 2)
  • Modelle (insbesondere Inversionsergebnisse), die aus Messungen der oben genannten Methoden generiert wurden
  • Messkampagnen (Anm.: Im DSGPE gibt es auch Interpretationskampagnen), in denen Messungen der oben genannten Methoden durchgeführt wurden

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:

• • Geophysikalische Modelle (Profile, Karten, 3D-Modelle, 1D/2D/3D-Prozessierungsund Interpretationsergebnisse in Form von Profilen, Karten, Grids, Tins usw.), die direkt für eine Analyse des geologischen Umfeldes vom Benutzer verwendet werden können
  • Prozesse, die Sensoren auslesen und Messdaten generieren, oder die aus Messdaten Modelle generieren (z. B. Inversionen)
  • Zusätzliche Klassen zur Einbindung des Schemas der ISO 19156 Observation and Measurement (O&M) für die Bereitstellung geophysikalischer Detailinformationen von Kampagnen, Messungen und Modellen, inkl. Erläuterungen und Beispielen (INSPIRE-GEOLOGY 2013, Annex D2)
  • Projekte als übergeordnete Objekte von Kampagnen
  • Codelisten (z. T erweiterbar und/oder hierarchisch aufgebaut) und Verbindungen zu Basisklassen, siehe INSPIRE-O&M (2011) und Annex D2 von INSPIRE-GEOLOGY (2013)

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

• • GeophProcessParameterNameValue,
  • GeophPropertyNameValue,
  • OtherGeophModelTypeValue
  • OtherMeasurementTypeValue

ansatzweise schon existieren (INSPIRE-GEOLOGY 2013).

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.

4.2 Zusammenfassung Geophysik-Kernmodell

Das Kernmodell besteht aus zwei fundamentalen Klassen: GeophMeasurement (geophysikalische Messung) und Campaign (Kampagne), siehe Abb. 1.

Messungen und zugehörige Klassen

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:

• • inspireId: Eindeutiger Objektidentifikator des Geoobjekts, Datentyp = Identifier, siehe Kap. 5.5.2.3 von INSPIRE-GEOLOGY (2013). Dort findet man auch die anderen weiter unten aufgeführten „importierten“ Datentypen. Der Aufbau der INSPIRE-ID wird in INSPIRE-GCM (2013), Kap. 14, beschrieben, außerdem in GDI-DE-REGISTRY (2012) und in INSPIRE-GESD (2011). Danach besteht eine INSPIRE-ID aus einem Namensraum und einem lokalen Identifier (OID). Namensräume sind i. d. R. institutionsbezogen und werden in Deutschland von GDI-DE (Geschäftsstelle beim BKG) verwaltet. OIDs müssen innerhalb des jeweiligen Namensraums eindeutig sein. Typischerweise kommen als OIDs die bisher bereits verwendeten Schlüssel von Datenbankobjekten zum Einsatz. Eine INSPIRE-ID ist ein Uniform Resource Identifier (URI), der nach Umsetzung des Namensraums in eine Internet-Domäne zu einem Uniform Resource Locator (URL) wird und zum Zugriff auf von Datenanbieter bereitgestellte Geoobjekte verwendet wird. Ein (konstruiertes) Beispiel für eine INSPIRE-ID ist http://oid.gdi-de.org/de.ni.liag/gr_messung_12345. Für interne Verlinkungen in den XML-Strukturen des gleichen Datenproviders werden z. T. nur die OIDs verwendet (vergleichbar mit relativen Pfaden)
  • citation: Bibliografische Angabe, Datentyp = DocumentCitation aus dem GCM (INSPIRE GCM 2013)
  • projectedGeometry: 2D-Projektion des Geoobjekts auf die Erdoberfläche in Form von Punkten, Kurven oder Begrenzungspolygonen, zur Verwendung durch einen INSPIRE-Darstellungsdienst bzw. zur Darstellung des Geoobjekts auf einer Karte. Datentyp = GM_Object (aus GML)
  • verticalExtent: Vertikale Ausdehnung des Geoobjekts (z. B. Untersuchungsbereich). Datentyp = EX_VerticalExtent aus dem ISO-19115-Metadatenstandard
  • largerWork: Identifikatoren (INSPIRE-IDs) übergeordneter geophysikalischen Objektmengen, z. B. von Messkampagnen, Datentyp = Identifier

  • distributionInfo: Information zum Datenerhalt (z. B. Beschreibung der Bestellprozedur, URL zum Dateistandort usw.), Datentyp = MD_Distributor aus dem ISO-19115- Metadatenstandard.

    Panel
    bgColor lightgrey
    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:

• • platformType: Plattform, von der aus die Messung durchgeführt wurde, z. B. Landfahrzeug, Helikopter oder Seeboden, siehe Codeliste platformTypeValue
  • relatedModel: INSPIRE-IDs der aus der Messung erstellten geophysikalischen Modelle. Datentyp = identifier
  • relatedNetwork: Bezeichnungen der nationalen oder internationalen Beobachtungsnetze, zu dem die Messvorrichtung gehört oder an das die Messdaten übermittelt werden, siehe Codeliste networkNameValue

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).

    Panel
    bgColor lightgrey
    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

  • GeophProfile beschreibt eine profil-, d. h. eine auf eine Raumkurve bezogene Messung. Einziges natives Attribut ist profileType (Art des geophysikalischen Profils). Aktuell gibt es in der zugehörigen Codeliste profileTypeValue die Einträge (1) Multielektroden-Gleichstromgeoelektrik, (2) 2D-Seismik und (3) Logging. (1) und (2) beschreiben die Profilgeometrie auf der Erdoberfläche, (3) dagegen den 3D-Verlauf einer Log-Messung im Bohrloch. Die Codeliste ist erweiterbar, als Empfehlungen sind bereits die Profiltypen: Flight Line, Cone Penetration, VSP und Georadar angegeben. Das von SF_SpatialSamplingFeature geerbte Attribut shape (siehe oben) wird per Constraint auf den Datentyp GM_Curve (entspricht GML:Curve) eingeschränkt
  • GeophSwath beschreibt eine flächenhafte Messung mit dem Attribut swathType (Streifentyp). Entgegen der Namensgebung beschränkt sich GeophSwath aber nicht typischerweise auf streifenförmige Messungen. Die Codeliste swathTypeValue enthält aktuell nur die 3 Einträge 3D-Seismics, Radarinterferometry und Sonar, ist aber erweiterbar. Das von SF_SpatialSamplingFeature geerbte Attribut shape (siehe oben) wird per Constraint auf den Datentyp GM_Surface (entspricht GML:Surface) eingeschränkt. Eine GML:Surface-Instanz besteht aus einer Menge Kante-an-Kantebenachbarter Polygone („Patches“) vom Typ GML:Polygon, von denen jedes eine komplexe Struktur mit inneren und äußeren Ringen haben kann. Mit GML:Surface kann z. B. ein 3D-Raumkörper über seine Grenzflächen beschrieben werden. In GeophSwath besteht eine GM_Surface-Instanz typischerweise aber nur aus jeweils einem Polygon

Kampagnen und zugehörige Klassen

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)

• • inspireId: Objektidentifikator der Geoobjektmenge
  • citation: Bibliografische Angabe, Datentyp = DocumentCitation
  • projectedGeometry: 2D-Projektion(en) der Geoobjektmenge auf die Erdoberfläche als Punkt(e), Kurve(n) oder Begrenzungspolygon(e) zur Verwendung durch einen INSPIRE-Darstellungsdienst bzw. zur Darstellung auf einer Karte. Datentyp = GM_Object
  • verticalExtent: Vertikale Ausdehnung der Geoobjektmenge (z. B. Untersuchungsbereich). Datentyp = EX_VerticalExtent
  • distributionInfo: Information zum Datenerhalt. Datentyp = MD_Distributor.
  • largerWork: Identifikatoren = INSPIRE-IDs übergeordneter (umfassenderer) Geoobjektmengen, z. B. von Projekten im Erweiterungsmodell. Datentyp = Identifier
  GeophObjectSet wird (wie auch GeophObject) aus der abstrakten Klasse SF_SpatialSamplingFeature von O&M abgeleitet (INSPIRE-O&M 2011). Die Möglichkeiten von SF_SamplingFeatures zur Abbildung der „realen“ O&M-Welt stehen daher prinzipiell auch in GeophObject und dessen Unterklassen zur Verfügung, auch wenn sie im Kernmodell nicht ausgenutzt werden.

Campaign umfasst zusätzlich zu denen von GeophObjectSet geerbten (Abb. 3) die folgenden Attribute:

• • campaignType: Art der Kampagne. Die zugehörige Codeliste ist campaignTypeValue. Im Kernmodell hat diese Liste verbindlich nur den Eintrag measurement; für das Erweiterungsmodell sind die weiteren Einträge processing und interpretation vorgesehen
  • surveyType: Art der geophysikalischen Untersuchung (geophys. Methode), siehe Codeliste surveyTypeValue mit aktuell 14 Einträgen (Tab. 2)
  • client: Institution, für die die Daten erfasst wurden. Datentyp = RelatedParty aus dem GCM (INSPIRE-GCM 2013)
  • contractor: Institution, von der die Daten erfasst wurden, Datentyp = RelatedPart
  • shape ist von SF_SpatialSamplingFeature geerbt und vom universellen Datentyp GM_Object, aber per Constraint eingeschränkt auf den Untertyp GM_Surface. shape ist nicht zu verwechseln mit projectedGeometry (siehe Abschnitt: Messungen und zugehörige Klassen)

Geophysikalische Methoden im Kernmodell

Die im Kernmodell mindestens zu berücksichtigenden geophysikalischen Methoden ergeben sich aus den Inhalten der Codelisten stationTypeValue, profileTypeValue, stationRankValue und swathTypeValue. Zusammengefasst sind dies:

Beispiel

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.

4.3 Zusammenfassung Geophysik-Erweiterungsmodell

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.

Projekte, Kampagnen und zugehörige Klassen

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.

Messungen und zugehörige Klassen

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.

Modelle und zugehörige Klassen

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.

Observation&Measurement - Grundbegriffe

Die folgenden Definitionen (http://de.wikipedia.org/wiki/Sensor_Observation_Service) sind für das Verständnis von Kap. 5.5 notwendig.

• • Eine Observation (Beobachtung) ist eine Aktion, die – angewandt auf ein Untersuchungsobjekt – für eine Eigenschaft ein Ergebnis liefert. In der Geophysik handelt es sich dabei typischerweise um Messungen am Erdkörper
  • Über das Untersuchungsobjekt (Feature-of-Interest, FOI) erfolgt in der Regel die Georeferenzierung der Beobachtung. Beispiele für Untersuchungsobjekte sind Gesteinsproben, Dauerbeobachtungsflächen, Bohrungen, Lagerstätten, Störungen usw.
  • Ein Phänomen (Phenomenon) ist ein beobachtetes Ereignis am Untersuchungsobjekt, z. B. ein Erdbeben
  • Eine Eigenschaft (Property) beschreibt einen Teilaspekt eines Phänomens, z. B. die Amplitude eines Erdbebens. In der Geophysik wird eine Eigenschaft i. A. durch eine am Untersuchungsobjekt beobachtete physikalische Größe beschrieben. Weitere Beispiele sind Lufttemperatur, Windgeschwindigkeit, Schadstoffkonzentration usw. Eigenschaften sind häufig zeitabhängig und ändern sich kontinuierlich. Die Beobachtung erfolgt i. d. R. aber nur an diskreten Zeitpunkten (SamplingTimes). Ein Phänomen kann mehrere Eigenschaften aufweisen. Anm.: Phänomene und Eigenschaften werden in der Fachliteratur häufig gleichgesetzt
  • Das Ergebnis (Wert, Result) ist das einer Eigenschaft zugeordnete Resultat einer Beobachtung, in der Geophysik i. A. die Ausprägung einer physikalischen Größe wie z. B. Druck, Widerstand, Dichte usw.
  • Das Ergebnis selbst wird durch eine(n) Prozedur (Procedure, Prozess, Process) erzeugt. Dieses kann durch das Auslesen eines Sensors (Messgeräts), eine Simulation, eine Inversion usw. erfolgen. Sensoren werden häufig als Spezialfälle von Prozessen aufgefasst
  • Eine Instanz von Observation Set ist eine logische Gruppierung von miteinander in Bezug stehenden Beobachtungen, welche gemeinsam, z. B. von einem Webdienst, angeboten werden.

Attribute einer Beobachtung sind:

• • SamplingTime – Zeitpunkt der Beobachtung, siehe oben
  • ResultTime – Zeitpunkt der Ermittlung des Ergebnisses
  • ResultQuality – Qualität des Messwertes
  • Parameter – Beschreibung von Beobachtungsparametern, die nicht direkt zum Untersuchungsobjekt oder zum Prozess gehören. Dabei kann es sich z. B. um Geräteeinstellungen, Wetterbedingungen usw. handeln. Das Attribut Parameter ist flexibel anwendbar, da es vom Typ parameter::NamedPair ist (frei wählbare Paare aus Parametername und -Inhalt) ist und außerdem multipel sein darf. Mit diesem Konstrukt lassen sich auch komplizierte Sachverhalte in O&M abbilden

Eine ausführlichere Beschreibung von O&M befindet sich in Kap. 4 von INSPIRE-O&M (2011).

Observation&Measurement im Generic Conceptual Model

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:

• • Beobachtung und OM_Observation
  • Prozess und Process
  • Observation Set und ObservationSet
  • FOI und GF_Feature
  • Property und GF_PropertyType

Die Assoziationen zwischen diesen GCM-Klassen sind ebenfalls in Abb. 7 enthalten. Besonders wichtig sind:

• • Phenomenon, verbindet OM_Observation mit GF_PropertyType; der Rollenname ist observedProperty
  • Domain, verbindet OM_Observation mit GFI_Feature; der Rollenname ist featureOfInterest
  • Range, verbindet OM_Observation mit Any; der Rollenname ist result
  • ProcessUsed, verbindet OM_Observation mit OM_Process; der Rollenname ist procedure

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 und Sensor Markup Language

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:

• • O&M (obwohl auch als eigenständiger ISO-Standard definiert)
  • Sensor Markup Language (SensorML, SML) (OGC-SML 2014) als MarkupSprache zur Beschreibung der datengenerierenden Prozesse
  • SWE Common (SWEC) (OGC-SWE 2011), enthält die Basisklassen von SWE (also auch von O&M) und kann u. a. zur Codierung von Beobachtungsergebnissen eingesetzt werden
  • Sensor Observation Service (SOS) als Webdienst zur Abfrage von EchtzeitSensordaten sowie von Sensordatenzeitreihen. Die angebotenen Sensordaten umfassen die Beschreibungen von Sensoren bzw. Prozessen (codiert in SML) und die eigentlichen Messwerte (codiert in O&M, SML und SWEC)

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

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:

• • domainSet – räumliche Ausdehnung des Coverage
  • rangeSet – Menge der (ggf. zusammengesetzten) Eigenschaftswerte des Coverage, ggf. inkl. Raum/Zeit-Koordinaten
  • rangeType – Typdefinitionen der rangeSet-Attribute

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)

• • Gridded coverages
    
    • GridCoverage – reguläres, äquidistantes Grid ohne Georeferenz (z. B. ein Rasterbild ohne Eckkoordinaten)
    • RectifiedGridCoverage – dito, aber mit Georeferenz (z. B. Satellitenfoto)
    • ReferenceableGridCoverage – nicht notwendigerweise äquidistantes Grid (z. B. Serie von Satellitenbildern, die in unterschiedlichen Zeitabständen aufgenommen wurden, oder kurven-lineares 1D-Grid entlang eines Flussverlaufs)
  • Multi-feature coverages
    • MultiPointCoverage – Wertemenge, die sich auf eine Menge diskreter Punkte in einem Raum/Zeit-Kontinuum beziehen (Punktwolke)
    • MultiCurveCoverage – Wertemenge, die sich auf eine Menge diskreter Kurven in einem Raum/Zeit-Kontinuum beziehen (z. B. Isolinien oder Flugbahnen)
    • MultiSurfaceCoverage – Wertemenge, die sich auf eine Menge diskreter Flächen in einem Raum/Zeit-Kontinuum beziehen (z. B. Isoflächen)
    • MultiSolidCoverage – Wertemenge, die sich auf eine Menge diskreter Körper (Solids) in einem Raum/Zeit-Kontinuum beziehen (z. B. CAD-Objekte)

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:

• • transaktionaler WCS (WCS-T) das Hochladen von Coverages auf einen Server bzw. das Ändern bereits vorhandene Coverages
  • Web Coverage Processing Service (WCPS) die flexible Ad-hoc-Verarbeitung und Filterung von Coverage-Mengen
  • WCS-CRS (CRS = Coordinate Reference System) das Ansprechen eines Coverage in einem anderen als dem gespeicherten Koordinatenreferenzsystem

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.

Observation&Measurement im Erweiterungsmodell

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:

• • 1. O&M + GML-Coverage
  • 2. O&M + SensorML + SWEC (O&M + SWEC ist ebenfalls möglich)
  • 3. O&M + Link auf externe Datei

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:

• • resource – Der Datenzugang wird als CI_OnlineResource bereitgestellt, bestehend aus einer URL für den Onlinezugang und einer optionalen Quellenbeschreibung
  • resourceType – Typ der Ressource, muss aus der Codeliste ResourceTypeValue stammen, siehe S. 342 – 343 von INSPIRE-GEOLOGY (2013). Einträge dieser Liste sind u. a. SEG-Y, LAS, UKOAA, …, Coverage, SensorML und SWE

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.

Beispiele zum Erweiterungsmodell

Beispiel für die Verwendung von Observation&Measurement

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

• • http://mfgi.hu/inspire/OBS_SLN2D_NK-60.1 (für die Messdaten) und
  • http://mfgi.hu/inspire/OBS_SLN2D_NK-60.2 (für die prozessierten Daten)

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).

Beispiel für die Verwendung von Coverages

(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.

Beispiel für die Verwendung von SensorML

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

Alternativbetrachtungen zum Erweiterungsmodell

Für die Implementierung des DSGPE gibt es die folgenden Lösungsalternativen:

1. 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).

   Panel
   bgColor lightgrey
   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.

2. Prinzipiell ist O&M auch dafür geeignet, einfach strukturierte Messungen mit O&MBordmitteln, d. h. mit selbstdefinierten „Named Pairs“-Parameter zu beschreiben. In der Regel handelt es sich aber dabei um Massendaten (Gravimetrie, Magnetik, Aerogeophysik), die lt. DSGPE nicht über Einzeldokumente, sondern kampagnenweise zusammengefasst über Coverages bereitzustellen sind.
3. Als dritte Alternative (siehe Bsp. 6) wird der Einsatz von Coverages vorgeschlagen. Coverages sind ein Sprachkonstrukt innerhalb der Geographic Markup Language (GML) zur Beschreibung der Ausprägungen der Eigenschaften raumbezogener Phänomene. Coverages sind anwendbar auf multiple geophysikalische Mess- und Modelldaten, die an komplexe räumliche Objekte (Grids, Punktmengen, Profile usw.) gekoppelt sind. Mit einem Coverage werden i. d. R. keine Einzelmessungen, sondern die Ergebnisse ganzer Messkampagnen übertragen. Wg. des grundsätzlich räumlich/zeitlichen Bezugs lässt sich ein Coverage z. B. nicht ohne Weiteres zur Beschreibung einer VES-Messung, deren Einzelmesswerte sich auf variierende Elektrodenabständen beziehen, einsetzen. Sinnvolle Beispiele: Kampagnen- bzw. Messgebietsweise zusammengefasste Massendaten der Gravimetrie, Magnetik oder der Aerogeophysik, 2D/3D/4D-Modelle aller Art.
4. Als vierte Alternative (siehe Bsp. 7) sieht das DSGPE den Einsatz des SWEStandards (SWE = Sensor Web Enablement) zur Vorhaltung von Messdaten und Modellen vor. Messdaten und Modelle werden dabei strukturiert vorgehalten, also nicht einfach als „Black-Box-Datei“ wie bei Alternative 1. Geräteparameter werden mit der SWE-Komponente Sensor Markup Language (SML) beschrieben, Messdaten und Modelle dagegen mit der universellen Datenbeschreibungssprache SWECommon (SWEC). Mit SWEC lassen sich z. B. zeitabhängige Arrays abbilden. Dieses Verfahren eignet sich besonders für geophysikalische Methoden mit komplexen Datenstrukturen, für die es keine etablierten Dateistandards gibt. Sinnvolle Beispiele: VES, TEM.

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.

Fazit

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

• • (a) O&M + externe Datei(en),
  • (b) O&M + Coverage und
  • (c) O&M + SML/SWEC.

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)

5. Potentielle Daten, die zum Thema gehören

<Potentielle Daten und Einrichtungen auflisten>

6. Daten, die nicht zum Thema gehören

< Daten und Einrichtungen auflisten, die potentiell nicht zu INSPIRE gehören>

Abkürzungsverzeichnis

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

Literatursverzeichnis

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.