BEZIEHT SICH AUF TECHNICHAL GUIDELINE VERSION 2.0

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.

2. Definition des Themas

Digitale Höhenmodelle für Land-, Eis-und Meeresflächen. Dazu ggehören Geländemodell, Tiefenmessung und Küstenlinie [INSPIRE Richtlinie 2007/2/EG]


3. Abgrenzung zu anderen INSPIRE-Themen

Ausschluss von folgenden Objekten innerhalb des Themas, DS umfasst nicht:

  • Küstenlinien → Behandlung im Thema Meeresregionen (Sea Regions) (TWG Beschluss)
  • keine relativen Erhöhungen der Elemente bezogen auf andere räumliche Objekte

4. Inhalt des Themas

4.1 Höhe

  • Dimensionale Eigenschaft eines Elements, bestehend aus einem absoluten Maß bezogen auf eine definierte Oberfläche als Ursprung (Geoid, Wasserstand, etc.) → Höhen, Tiefen
  • Terrestrische Höhen (Landeshöhen) dargestellt als:
    • Digitales Geländemodell (DTM, Digital Terrain Model) beschreibt die dreidimensionale Form der Erdoberfläche (Oberflächentopographie)
    • Digitales Oberflächenmodell (DSM, Digital Surface Model) konzentriert sich auf dreidimensionale Geometrie aller Objekte auf der Erde (Unterschied zu DGM: einschließlich Brücken, Gebäude, Vegetation usw.)
    • Bathymetrie-Daten, z.B. gerastertes Meeresbodenmodell
  • sowohl Rasterdaten (DGM z.B. als TIN) als auch Vektordaten (Höhenlinien, Höhenangaben & Bruchkanten für morphologische Beschreibung des Geländes)
  • räumliche Darstellung als Vektor (2D oder 3D), Raster oder TIN (Triangulated Irregular Network = unregelmäßiges Dreiecksnetz)

4.2 Zusammenfassung Datenmodell

Das Datenmodell basiert auf den vier folgenden Anwendungspaketen:

  • Basismodell Höhe (Elevation - Base):
    definiert gemeinsame Elemente, Eigenschaften & Klassen der Höhendaten
  • Vektormodell Höhenelemente (Elevation - Vector Elements):
    Attribute & Beziehungen räumlicher Objekte mit Höhenangaben
  • Modell Höhenraster (Elevation - Coverages):
    definiert die Grundlage für flächendeckende Bereitstellung von Höhenmodellen
  • TIN-Höhenmodell (Elevation - TIN): Bereitstellung von Geländemodellen als TIN-Struktur
    basiert auf Sammlung von Vektor-Geometrien wie Kontrollpunkte, Bruchkanten und beinhaltet erforderliche Parameter für Berechnung einer Delaunay- Triangulation im nachfolgenden Prozess
    → oft beschränkt auf fortgeschrittene technische Benutzer, nicht so weit verbreitet wie rasterbasierte Höhendaten

5. Potentielle Daten, die zum Thema gehören

Anwendungsfälle

  • Hoch- und Tiefbau: Gestaltung von Straßen, Standortplanung, Berechnungen für Bau von Dämmen, Reservoirs, Aushub- und Erdarbeiten mit LKW etc.
  • Geowissenschaften: Simulation und geomorphologische Klassifizierung, geologische Kartierungen, Interpretation von Hangprofilen für Erstellung von Reliefkarten)
  • Planungs- und Ressourcenmanagement: Bewirtschaftung natürlicher Ressourcen, Fernerkundung, Bodenkunde, Landwirtschaft, Meteorologie, Umwelt- und Stadtplanung, Forstwirtschaft)
  • Vermessung und Photogrammetrie: Erfassung von DTMs, Bearbeitung von Orthobildern, Qualitätsbewertung der Daten für topographische Kartierung
  • Militärische Anwendungen: wertvolle Erkenntnisse über Gelände, Höhe und Neigung der Erdoberfläche; Sichtbarkeitsanalyse für Gefechtsführungssysteme, Waffenleitsysteme, Flugsimulation, Radarsignalanalysen ...

6. Daten, die nicht zum Thema gehören

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

7. FAQs

offene Fragen bzw. Diskussionen, wo sich die Mitglieder der TWG besonders über Meinungsäußerungen freuen würden:

  • Bathymetrie von Flussläufen wurde bisher nicht berücksichtigt, sollte jedoch nachträglich in zukünftigen Version aufgenommen werden, weil es ein wichtiger Aspekt für relevante Anwendungsfälle wie z.B. für die Sicherheit im Bereich der Binnenschifffahrt ist
    Gibt es dazu gegenteilige Meinungen oder zusätzliche Bemerkungen für diese oder andere Ergänzungen?


4 Kommentare

  1. https://inspire.ec.europa.eu/forum/discussion/view/265361/availability-of-elevation-data-in-the-inspire-thematic-viewer

    I would be willing to start with you a discussion / brainstorming about the most important factors hindering the interoperability of European Elevation data.

    Please, feel free to add your personal views on the state of implementation of INSPIRE Elevation data and report any existing drawbacks to achieve this goal on time, ideally pointing at your own examples and direct experiences in your country.

  2. https://inspire.ec.europa.eu/forum/discussion/view/266096/interpretationimplementation-of-grids-for-raster-data-especially-elevation

    I now have implemented the prototype of a software that is transforming any raster data source to a data set that is stored in EPSG:3035 and is georeferenced in a way that it alignes with the affordance of the INSPIRE statistical GRIDs.

    Beitrag von Markus Mayr, BEV (Österreich), zur Bereitstellung von Rasterdaten für INSPIRE (hier Thema Höhe).

  3. https://github.com/INSPIRE-MIF/helpdesk/issues/75

    we've run into some logical issue in the provision of Elevation Grids, pertains to the exact location for which the value is provided, value-is-corner vs. value-is-center. I'm aware that this has long been a point of confusion when dealing with Coverage models, with the more data-affine folks tending towards value-is-corner (cleanly nailed down location) while the visualization end is convinced these values are pixels, thus insist on value-is-center. For Themes such as OrthoImagery, value-is-center makes total sense, as the values are actually pixels (so apply for the entire cell). For Elevation, value-is-center would only make sense if we lived in a MineCraft or Lego based world.

    However, this logical approach is at odds with the following:
    IR Requirement Annex II Section 6.2.1.2 Constraints of the spatial object type RectifiedGridCoverage

    Grid points of a RectifiedGridCoverage shall coincide with the centres of cells of the geographical grids defined in Section 2.2 of Annex II of the Commission Regulation on Interoperability of Spatial Data Sets and Services at the same resolution level.

    I'd be interested how other MS are providing their elevation data, following the technical SOTA (value-is-corner), or just bowing to the legal requirements (value-is-center)?