Übersicht:

Favoritenliste:

Favorite Pages

There are currently no pages on your favorites list. You can add pages to this list by selecting Favorite from the Tools menu on the page you're viewing.
Skip to end of metadata
Go to start of metadata

Welche Zusammenhänge gibt es zwischen WMS-Layern und Daten-Metadatensätzen?

Hintergrund: Ein Anwendungsfall für einen Nutzer ist, dass nach dem Suchen und Finden von Diensten und deren Visualisierung Informationen über die zugrunde liegenden Daten von Interesse sind (z.B. zur Bestellung, Informationen über Qualität, Aktualität, ...)

8 Comments

  1. 1. Nutzer findet WMS im Metadateninformationssystem (vorausgesetzt der WMS entspricht den AdV-Festlegungen zum WMS-DE Version 1.0; Version 2.0 vom 15.05.2008)
    2. Somit kann über eine GetFeatureInfo (Ausweichvariante) nach den festgelegten Attributen gefragt werden bzw. über den Aufruf GetRecordById die XML-Daten abgegeben werden

    3. Ich habe ein Ergebnis

    Anm. So funktioniert z.B. die Basiskarte Sachsen (z.B. WMS DOP-RGB)

  2. Im GetCapabilities-Dokument des WMS besteht also eine Verknüpfung zum Metadatensatz. Dadurch kann der User eines z.B. Geoinforamtionssystems direkt durch einen Klick auf z.B. die betreffende Ebene in der Kartenansicht zu den Metainformationen gelangen.

    Auszug aus dem GetCapabiltiies-Dokument aus Sachsen:


    <Layer queryable="0" opaque="0" cascaded="1">
        <Name>adv_dop</Name>
        <Title>DOP 020</Title>
        <Abstract>Digitale Orthophotos (Bodenauflösung 20 cm)</Abstract>
        <SRS>EPSG:31468</SRS>
        <MetadataURL type="TC211">
              <Format>text/xml</Format>
              <OnlineResource xlink:type="simple" xlink:href="http://www.landesvermessung.sachsen.de/geomis/soapServices/CSWStartup?Request=GetRecordById&version=2.0.2&OutputSchema=http://www.isotc211.org/2005/gmd&Service=CSW&ElementSetName=full&ID=d38dca40-fbd7-483a-8c9d-7025cc981028"/>
         </MetadataURL>
        <Style>
               <Name>DEFAULT</Name>
               <Title>DEFAULT</Title>
               <LegendURL width="300" height="165">
                    <Format>image/gif</Format>
                    <OnlineResource xlink:type="simple" xlink:href="http://www.landesvermessung.sachsen.de/ias/basiskarte4/service/legendimage?SRV_NO=2&SRV_WA=1&IMG_TYPE=gif&LAYERS=adv_dop"/>
              </LegendURL>
        </Style>
        <ScaleHint min="0.000374177136322228" max="3741.77136322228"/>
    </Layer>


    Das entscheidende Element in den GetCapabilities ist also <MetadataURL>. Wenn es sich um standardisierte Metadaten nach ISO 19115 handelt, muss zusätzlich der type="TC211" angegeben werden, wie es hier der Fall ist (OGC 01-068r3, S. 28).  Die Verbindung zwischen dem WMS und dem Metadatensatz muss von Hand vom Datenhalter in den WMS eingepflegt werden, sobald der dataset / series-Metadatensatz vorliegt.

    Da hier "nur" ein standardisiertes xml-Metadatum angeboten wird,  sollte der jeweilig verwendete Client für das Anschauen der WMS-Karten in der Lage sein, aus dem xml einen für Menschen lesbaren Metadatensatz darzustellen, um die bestmögliche Information des Anwenders zur Herkunft und Qualität der Daten zu gewährleisten.

    Andersherum kann aus einer Metadatenanwendung ggf. die URL der WMS-Schnittstelle per Klick in einen Kartenviewer transferiert werden, so dass der Nutzer sich zu einer recherchierten Geodatenressource auch gleich den Dienst anschauen kann, der die Geodaten abbildet.

  3. Vermutlich habe ich die Frage etwas unpräzise gestellt:

    Eigentlich wollte ich fragen, wie häufig ein Layer und ein Daten-Metadatensatz inhaltlich konsistent sind. Ein Layer kann z.B. aus mehreren Datensätzen zusammengefügt sein.

    1. "konsistent" verstehe ich zwar nicht so ganz... Aber Layer und Datensatz sollten einfach zusammen passen. Man muss aus meiner Sicht den Metadatensatz dann eben so modellieren, dass er den Layer beschreibt. Metadatensätze haben nur einen einzigen Zweck: sie müssen vorliegende Geodatenressourcen umfassend und vollständig beschreiben. Von daher kann es keine Inkonsistenz geben, sofern die Metadaten wirklich ihren Zweck gegenüber dem Datennutzer erfüllen. Gäbe es eine Inkonsistenz wären die Metadaten schlicht falsch angelegt und müssten berichtigt werden.

      Beispiel:

      Der Layer zeigt "Bäume". Es gibt jeweils einen dataset-Metadatensatz für Laub- und einen für Nadelbäume, weil z.B. die Attributtabellen unterschiedlich sind. Da der Layer aber "Bäume" abbildet, verweist der Layer auf einen series-Metadatensatz für "Bäume". Dieser series-Metadatensätz muss dann eigentlich einen Verweis auf die UUID (GetRecordById) der beiden zugehörigen dataset-Metadaten mit "Laubbäumen" und "Nadelbäumen" enthalten.
      Von daher müsste es so sein, dass es nicht nur eine Daten-Service-Kopplung (Wann ist eigentlich das Dokument des AK Metadaten dazu fertig?) geben, sondern es müsste aus meiner Sicht auch eine Verbindung zwischen dataset und series-Metadatensätzen geben, wenn man ernsthaft mit dem hierarchy level arbeiten will.

      Vielleicht sehe ich, die ich so gut wie keine Ahnung vom Aufbau der ISO habe, es aber auch einfach etwas zu praktisch, welchen Nutzen Metadaten haben müssen, damit man (endlich) mit fremden Geodatenressourcen vernünftig arbeiten kann. Geodatenressourcen ohne Beschreibung sind doch wertlos. Darauf kann niemand eine Analyse oder sonstiges aufbauen. Man kann aber auch nicht alle Daten für ein Projekt immer selbst erheben (um dann nach kurzer Zeit wieder vergessen zu haben, wie sie entstanden sind, weil man es (natürlich) nicht angemessen (also z.B. mittels ISO-konformer Metadaten eines passenden hierarchy levels) dokumentiert hat. Wir wollen doch gerade mit der GDI erreichen, dass die bestehenden Geodatenressourcen gemeinsam genutzt werden können. Von daher darf es da aus meiner Sicht keine Inkonsistenzen geben. Ich habe es als als Datenhalter doch selbst in der Hand, wie ich meine Metadaten modelliere. Da ist es auch vollkommen egal, ob eine Geodatenressource nun zufällig zu den paar INSPIRE-Themen gehört oder ob es eine ganz "alltägliche" Geodatenressource ist, die ja in der Praxis viel häufiger vorkommt und damit eine wesentliche GDI-Relevanz besitzt.

  4. Der Ansatz ist sicher ganz richtig und die zugrundeliegenden Standards erlauben den Aufbau in dieser Form. Dieser Input kann aus meiner Sicht als input für eine Anleitung/Unterstützung Verwendung finden und damit zukünftig für bessere Qualität bzgl. Konsistenz sorgen.

    Genaue Analysen, wie oft das aktuell schon der Fall ist, sind aber schwierig. Daher meine Nachfrage. Sie zielt auf Informationen zur aktuellen Lage.

  5. Ich habe zu dem Thema Ende letzten Jahres mal einen Vortrag gehalten. Der ist vielleicht hilfreich: http://www.where2b-conference.com/vortraege_2010

    Wenn wir eine Kopplung zwischen Services und Daten realisieren wollen geht das nicht über eine händische Pflege der Verknüpfungen zwischen zwei Metadatensätzen! Die Verknüpfung muss automatisch erfolgen, es sollte nur einen single point of access geben. Meiner Meinung nach solten wir dafür sorgen, dass die Datenhaltungskomponenten um einfache Metadatenmodelle erweitert werden. Diese können, auch von den auf den Daten konfigurierten Services, automatisch interpretiert und nach Außen abgegeben werden (z.B. über die MetadataUrl).  Alles was händisch gepflegt werden muss wird - falls es keinen besonderen Nutzwert hat - zum Datenfriedhof. Und davon haben wir schon mehr als genug ;-) .

    1. Der Service-Metadatensatz ist doch sowieso völlig unkritisch. Wenn ich meine Geodaten (also Shapes, Bilder usw.) mit series oder dataset-Metadaten, die ausschließlich von Hand erstellt werden können, weil der Inhalt niemals von einem irgendwie gearteten Tool generiert werden kann, da dahinter menschlicher Sachverstand stehen muss (!) existieren, dann muss ich einen Link zu diesen Metadaten per Hand (also in der Regel durch die Nutzung der Möglichkeiten zur entsprechenden Verlinkung meiner normalen Geodatensoftware) in das GetCapabilities-Dokument (Layer, MetadataURL) einpflegen.

      Wenn dann der Link einmalig (da ja die UUID im GetRecordById-Request) gesetzt ist, kann ich doch mit meiner CSW-Software das GetCapabiltiies-Dokument des Dienstes harvesten. Die CSW-Software kann dann beim Harvesten entweder noch die verlinkten dataset/series-Metadatensätze mit harvesten oder belässt es aber beim Harvesten dieses GetCapabiltites-Dokumentes. So entsteht dann der gekoppelte Service-Metadatensatz.

      Ich habe das mit einem Dienst dieses Harvesting eines WMS mit GeoNetwork mal ausprobiert, aber in Ermangelung von ISO-Kenntnissen nicht bis ins Detail überprüft. Es funktioniert aber soweit, da ein Service-Metadatensatz mit entsprechenden Links auf die zugehörigen dataset-/series-Metadaten entsteht. Service-Metadaten von Hand erstellen zu wollen, kann nicht wirklich klappen. Das muss aus meiner Sicht immer zumindest halbautomatisiert laufen (so viel wie möglich aus dem GetCapabilties-Dokument, kleine Einzelheiten zur Fachlichkeit ggf. per Hand nacherfassen). Die series- oder dataset-Metadaten müssen aus meiner Sicht aber immer zuerst und immer von einem fachlich versierten Menschen erstellt werden. Man kann also nie mit einem service-Metadatensatz bei der logischen Erfassung beginnen.

      tile-Metadaten kann man übrigens wieder automatisiert erstellen, aber ihr Nutzen für einen Menschen ist sehr begrenzt.

      - Ich hoffe man kann´s verstehen. Habe jetzt leider nicht ausreichend Zeit. -

      1. So hab ich das ja auch geschrieben - es ging nur darum, dass das harvesten über die Service URL erfolgen soll. Ein explizites Einstellen der Metadatensätze ist dann nicht notwendig, da die von INSPIRE geforderte MetadataURL ja schon auf den Record verweist.

        Das mit dem (halb-)automatischen Anlegen von Metadaten für die zum Beispiel in einer Geodatenbank gepflegten Metadaten halte ich dennoch für den einzig sinnvollen Weg. Die Naturschutzverwaltung in RP hat einen solchen Weg für Postgres/PostGIS realisiert. Natürlich können nicht alle Metadaten für INSPIRE dort aus den Datenm generiert werden - jedoch ein großer Teil. Der Rest kann durch die verantwortliche Stelle angereichert werden. Es entsteht ein konsistentes Daten/Metadatensystem auf Ebene der Datenhaltung. Jetzt müssen nur noch die Services dieses System automatisch lesen können und für jedes Content Element (featuretype/layer) die MetadataUrl in die Capabilities eintragen. Dann reicht es die Links auf die Capabilities  zu verwalten und der Rest kann automatisch erfolgen. Daten die nicht über Services bereitgestellt werden, können über einen anderen Weg in den Zentralkatalog überführt werden.

        Der komplett integrale Weg, nämlich die Metadaten und Daten in einem featuretype zu verwalten ist ebenfalls möglich. Man muss nur ein xslt vorhalten um aus dem Daten-GML ein ISO19139 XML zu erhalten. Geonetwork hat das AFAIK schon implementiert. Hier gibt es jedoch viele redundante Informationen im Datensatz.