Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Lesedauer 17 Min.

Ordnung für Orte und Regionen

Die Verwaltung von Geodaten und die Arbeit damit in spezialisierten Datenbanken.
Viele Bereiche unseres Lebens sind heutzutage ohne kartenbasierte Webanwendungen und Navigationssysteme nicht mehr denkbar. Beispielsweise versorgen uns Smart­phones und Smartwatches mit aktuellen Wetter-, Fahrplan- und Stauinformationen anhand unseres Standorts. Weitere Anwendungen sind die Berechnung von Routen zwischen Standorten und deren Darstellung in Karten. Auch moderne industrielle Anwendungen und Trends aus den Bereichen Smart Cities und Industrie 4.0 greifen vielfältig auf geografische Daten der entsprechenden Sensoren zurück. Man bezeichnet diese Daten mit Informationen über Standorte, Routen, Regionen und so weiter als Geodaten.Dort wo Daten erhoben werden, müssen diese auch gespeichert und verwaltet werden. Für eine effektive informationstechnische Bereitstellung und Verwaltung von Geodaten werden sogenannte Geoinformationssysteme (GIS) eingesetzt.Ein Geoinformationssystemsetzt sich aus mehreren Bestandteilen zusammen (Bild 1). Man zählt sowohl die Hard- als auch die Software hinzu [1]. Die Basis eines GIS sind die Geodaten. Um diese und um deren Speicherung und Verwaltung in speziellen Geodatenbanken geht es in diesem Artikel. Die anderen Komponenten ­eines GIS sind ebenfalls schnell erklärt:
Komponenteneines GIS(Bild 1) © Bild: ldbv.bayern.de [1]
  • Basissoftware: Diese setzt auf die Geodatenbank auf und stellt grundlegende GIS-Funktionen bereit. Sie ist die Zwischenschicht zwischen der Fachanwendung und der Geodatenbank.
  • Fachanwendungen: Diese bieten individuelle Funktionen für die jeweiligen Aufgaben. Es handelt sich um die Anwendungssoftware. Oft ist es unsere Aufgabe, diese Software – zum Beispiel in Form einer .NET-Anwendung – zu entwerfen und zu implementieren. Dabei nutzen wir üblicherweise die Dienste einer Geodatenbank.
Herkömmliche SQL- beziehungsweise NoSQL-Datenbanken sind aufgrund der besonderen Eigenschaften von Geodaten nur teilweise oder erst durch Zusätze geeignet, diese Informationen zu verwalten [2]. Darüber hinaus unterstützen Geodatenbanken auch besondere Methoden, Sortier- und Suchverfahren, die sich auf standortbezogene Fragestellungen beziehen. Beispielsweise erlaubt eine Geodatenbank die direkte Ermittlung von Objekten im Umkreis eines Standorts, in dem man eine Abfrage an eine solche Datenbank richtet. Eine solche Abfrage ist mit einer herkömmlichen SQL-Abfrage an ­eine relationale Datenbank vergleichbar, jedoch in ihrer Syntax auf die Belange eines standort- und raumbezogenen Informationssystems spezialisiert.Zusammenfassend können wir also folgende Eigenschaften zu einer Geodatenbank benennen:
  • Datentypen: Diese muss geometrische Datentypen anbieten, beispielsweise für Punkte, Polygone, Streckenzüge und so weiter.
  • Methoden: Sie unterstützt Methoden, beispielsweise zur Bestimmung eines Streckenzugs oder zur Berechnung eines Schnitts zwischen zwei Flächen.
  • Abfragen: Sie bietet Algorithmen und Datenstrukturen, um die Verarbeitung von räumlichen Basisanfragen zu ermöglichen. Dazu zählt zum Beispiel die Abfrage nach Objekten, die sich innerhalb ­einer bestimmten räumlichen Geometrie befinden.
Die geometrischen Datentypen und Funktionen werden nicht nur von der Geodatenbank, sondern auch von den Anwendungssystemen – etwa einer Fachanwendung – genutzt.

Standardisierung von Geodaten

Um die Daten möglichst einfach zwischen verschiedenen Geoinformationssystemen auszutauschen und zur Vereinfachung bei der Entwicklung von Anwendungen, welche die Geodaten nutzen, sind Standards sehr wichtig. Das Open Geospatial Consortium (OGC [3]) hat in Zusammenarbeit mit der ISO Spezifikationen zu Geometrieklassen entwickelt – das Feature-Geometry-Modell. Es handelt sich dabei um ein konzeptionelles Datenmodell für räumliche Eigenschaften von Geoobjekten. Definiert werden dabei Standardoperationen für Zugriffe, Abfragen, Verwaltung, Verarbeitung und den Austausch von Geoobjekten.Das OGC ist ein Zusammenschluss aller relevanten GIS-Anbieter, GIS-Nutzer und der zugehörigen Verbände, die sich durch Schaffung von Standards zum Ziel gesetzt haben, die Nutzung von GIS zu verbessern und Klarheit bei der Anwendung von Geodaten zu schaffen. Als Hauptaufgabe sieht das OGC die Definition einer Technologie, die es den Entwicklern und den Anwendern ermöglicht, geocodierte Daten und eine geobasierte Funktionalität zu nutzen.Ein Beispiel sind Geodatendienste, auch bekannt als OGC-Dienste. Dabei handelt es sich um Internetdienste, die es erlauben, über standardisierte Schnittstellen Daten auszutauschen und Karten und weitere Geodateninformationen zu übertragen. Der Aufruf erfolgt über eine Internetadresse (URL), über die der Geodatendienst eindeutig identifizierbar ist. Behörden stellen auf diese Weise öffentliche Basisdaten, zum Beispiel Bodenrichtwerte oder Flächennutzungspläne, zur Verfügung. Der URL der Geodatendienste kann in Geoinformationssysteme (GIS) oder Webanwendungen eingebunden werden, die diese Funktion unterstützen. Die Bereitstellung über Online-Services ermöglicht eine stetige Aktualität der Daten in den Fachanwendungen.OGC-Standards dienen also dazu, die Geodaten anwendungsübergreifend zu nutzen. Ein solches standardisiertes Dateiformat ist beispielsweise die Geography Markup Language (GML). Die komplette Spezifikation finden Sie unter [4]. Sie beschreibt Geoinformationen in einem vektorbasierten Format. Mittels Styled Layer Descriptor (SLD) [5] und Symbology Encoding (SE) [6] kann das Aussehen von Kartenebenen definiert werden. Typische Anwendung einer SLD-Definition ist es, einem Web Map Service (WMS) mitzuteilen, wie eine spezielle Kartenebene dargestellt werden soll. Mittels Filter Encoding (FE) wird die Auswahl aus allen Vektordaten ermöglicht. Auf diese Weise kann das gewünschte Format der Kartenbilder und Kartendaten aus den betreffenden Online-Diensten abgerufen werden.Auf der Webseite des Landes Niedersachsen [7] ist beispielsweise beschrieben, wie man die Daten abruft, unter welchen Bedingungen diese genutzt werden können und wie man einen solchen Dienst in ein GIS einbindet. Neben dem GML-Format spielen zwei weitere Formate eine Rolle: Well-Known Text (WKT) und Well-Known Binary (WKB).Geometrische Objekte, die mit WKT dargestellt werden können, sind: Punkte, Linien, Polygone, Triangulated Irregular Networks (TIN) und Polyeder. Multi-Geometrien sind verfügbar, um mehr als eine Geometrie derselben Dimension in einem einzelnen Objekt darzustellen, und Geometrien unterschiedlicher Dimensionen können in einer Geometriesammlung gespeichert werden.Koordinaten für Geometrien können 2D (x, y), 3D (x, y, z) oder 4D (x, y, z, m) sein, wobei der m-Wert ein Teil eines linearen Referenzsystems ist. Auch bei einem 2D-System ist dies möglich (x, y, m). Das WKB-Format ist eine binäre Entsprechung des WKT-Formats.WKT-Geometrien werden in allen OGC-Spezifikationen verwendet und sind in Anwendungen vorhanden, die diese Spezifikationen implementieren. Beispielsweise enthält das Datenbanksystem PostGIS-Funktionen, die Geometrien in und aus einer WKT-Darstellung konvertieren können. WKT-Beispiele sehen Sie in Bild 2.
Well-Known-Text-Beispiele(Bild 2) © Bild: Wikipedia [17]

Koordinatensysteme

Geodaten sind Punkte und Vektoren, Kurven und dergleichen, das heißt, sie werden innerhalb eines Koordinaten­systems abgebildet. Koordinatensysteme sind wiederum ­Bezugssysteme. Sie ermöglichen die Interpretation eines Wertes in Bezug auf einen Datenraum, in den dieser Wert ein­gebettet ist. Räumliche Bezugssysteme beziehen sich auf Lageinformationen und erlauben es, die Lage eines Objekts räumlich zu verorten. Die Spezifikation der Lage erfolgt über Koordinaten, das Koordinatensystem ist in diesem Fall das Koordinatenbezugssystem. Das heißt: Nur wenn zu den Koordinaten das jeweilige Bezugssystem bekannt ist, kann eine Interpretation der Lage erfolgen. Aus den Koordinaten können konkrete Längen- und Flächenangaben abgeleitet werden.Bei einem kartesischen Koordinatensystem befinden sich die Achsen in einem rechten Winkel zueinander und es wird dadurch ein n-dimensionaler metrischer Raum beschrieben (Bild 3). Der Abstand zwischen zwei Punkten entspricht dem euklidischen Abstand. Bekannt sind die typischen x-y-Koordinatensysteme aus der Mathematik und aus Zeichendarstellungen. Das Prinzip lässt sich jedoch auch auf den drei- oder n-dimensionalen Fall übertragen.
Koordinatenbezugssysteme(Bild 3) © Bild: T. Brinkhoff [18]
Als georeferenzierende Koordinaten werden solche Systeme bezeichnet, die einen Bezug zur Erdoberfläche haben. Lokale Koordinaten beschreiben dagegen die Lage der Position von Objekten unabhängig von der Erdoberfläche. Diese werden zum Beispiel in CAD-Dateien angewendet. Bei georeferenzierten Koordinaten unterscheidet man geodätische Koordinatenbezugssysteme und projizierte Koordinatensysteme:
  • Geodätische Koordinatenbezugssysteme: Die Erde kann nicht mathematisch exakt beschrieben werden. Eine Annäherung mit der Berücksichtigung der Abplattung der Erdoberfläche bildet ein (Rotations-)Ellipsoid. Man beschreibt in diesem Fall die Lage eines Punktes auf der Erdoberfläche durch ein dreidimensionales kartesisches Koordinatensystem mit dem Ursprung im Mittelpunkt des Rotationsellipsoids. Die Rotationsachse ist die z-Achse. Die Koordinaten entsprechen dann einem dreidimensionalen Vektor (x, y, z). Kartesische 3D-Koordinaten sind eher ungeeignet zur Beschreibung von Positionen auf der Erdoberfläche. Geografische Koordinaten eignen sich dazu besser. Die Werte werden dabei bezogen auf den Äquator und einen Nullmeridian festgelegt. Die Abweichung vom Äquator ist die geografische Breite und die Abweichung vom Nullmeridian ist die geografische Länge. Werte, die verwendet werden, um ein geografisches Koordinatenbezugssystem im Hinblick auf das globale Bezugssystem zu definieren, bezeichnet man als geodätisches Datum.
  • Projiziertes Koordinatensystem: Dieses basiert immer auf einem geografischen Koordinatensystem und wird auf einer flachen, zweidimensionalen Oberfläche definiert. Längen, Winkel und Flächen in den zwei Dimensionen sind bei einem projizierten Koordinatensystem konstant. Man spricht von Flächen-, Winkel- und Längentreue. Positionen werden durch x-y-Koordinaten in einem Gitternetz identifiziert. Der Ursprung befindet sich in der Mitte des Gitternetzes. Jede Position besitzt zwei Werte, die sie gegenüber diesem zentralen Punkt referenzieren, die horizontale Position und die vertikale Position. Diese zwei Werte werden als x-Koordinate und y-Koordinate bezeichnet. Projizierte Koordinatensysteme implizieren eine Verzerrung, die von der gewählten Projektion und der Lage und Größe des betroffenen Gebiets abhängig ist. Projizierte Koordinaten eignen sich für die Darstellung auf ­einem Kartenblatt oder Bildschirm.
Für die Darstellung von Höhenangaben eignen sich vertikale Koordinatenbezugssysteme. In der Praxis werden oft zusammengesetzte Koordinatenbezugssysteme verwendet, die aus mindestens zwei unabhängigen Systemen bestehen.

Datenbanksysteme im Überblick

In diesem Abschnitt geben wir einen Überblick über die gängigen Datenbanksysteme, welche explizit mit Geodaten umgehen können.
  • Oracle Spatial: Die Datenbank von Oracle erlaubt es, Geodaten objektrelational zu speichern, und bietet den größten Funktionsumfang für die Verwaltung von Geodaten.
  • Microsoft SQL Server: Unterstützt geometrische Datentypen auf Basis des OCG-Datenmodells.
  • SAP SQL Anywhere und SAP HANA: Neben dem OGC-Datenmodell werden Geometrien nach SQL/MM Spatial berücksichtigt. SAP HANA enthält einen erweiterten Funktionsumfang.
  • SpatiaLite: Es handelt sich um ein freies Geodatenbank­system, das besonders für mobile Anwendungen gut geeignet ist.
  • PostgreSQL/PostGIS: Mithilfe der Erweiterung PostGIS wird PostgreSQL zu einem voll funktionsfähigen Geodatenbanksystem.
  • MySQL und MariaDB: MySQL implementiert die geometrischen Datentypen gemäß dem OGC-Datenmodell. Demgegenüber bietet Maria­DB als Abspaltung von MySQL zusätzliche Funktionen.
  • MongoDB: Als NoSQL-Datenbank unterstützt MongoDB die Speicherung von Geodaten sowie Abfragen darauf. Neben den JSON-Dokumenten ist MongoDB in der Lage, auch Geo­JSON-Dokumente zu verwalten. Dabei werden die Geodaten nicht als reiner Text, sondern im JSON-Format gespeichert [8].

Spatial Data

Der englische Begriff Spatial Data steht für Geodaten beziehungsweise für diejenigen Daten, die einen Raumbezug haben. Es handelt sich dabei um maschinenlesbare Informationen über Gegenstände mit einem räumlichen Bezug zur Erdoberfläche. Die zwei wichtigsten Eigenschaften von räumlichen Daten sind:
  • Geometrische Eigenschaften: Diese beziehen sich auf die Position und Ausdehnung von Objekten. So kann man über Koordinaten beispielsweise die Lage eines Ortes angeben.
  • Topologische Eigenschaften: Diese beschreiben die räumlichen Beziehungen von Objekten zueinander. Beispielsweise das Aneinandergrenzen oder das Überlappen von Regionen und Ähnliches.
Bei der Repräsentation von geometrischen Eigenschaften unterscheidet man grundsätzlich zwischen einem Raster- und einem Vektormodell. Das Rastermodell teilt den Datenraum in gleichförmige quadratische oder rechteckige Rasterzellen. Rasterdaten sind eine matrixbasierte Darstellung anhand von Bildpunkten beziehungsweise Pixeln. Pixel besitzen eine feste Kantenlänge, und demzufolge wirken diese bei starker Vergrößerung eckig. Rasterdaten besitzen eine relativ gesehen einfache Datenstruktur und können in kurzer Zeit erfasst werden. Nachteilig ist jedoch, dass die Grenzen der dargestellten Objekte nicht ganz genau sichtbar sind und die Transformation zu Vektordaten ziemlich aufwendig ist. Vektormodelle bauen dagegen auf Punkten und Linien auf. Vektordaten werden anhand von Koordinatenpunkten und Linien repräsentiert.
  • Punkte: Ein Punkt besteht aus Angaben zum x-, y- und manchmal zum z-Wert. Anhand von mehreren Punkten werden Objekte ohne Ausdehnung beschrieben, beispielsweise ein einzelnes Grundstück.
  • Linien beziehungsweise Polylinien: Eine Linie entsteht durch die Verbindung von zwei Punkten. Linien stellen Verbindungen im Raum dar, beispielsweise eine Straße oder einen Fluss.
  • Polygone: Ein Polygon besteht aus einer Reihe von Punkten, wobei der letzte Punkt mit dem ersten Punkt identisch ist. Alternativ gibt es zusätzliche Informationen, an welcher Stelle das Objekt geschlossen wird. Polygone eignen sich für Objekte mit Ausdehnung, beispielsweise zur Modellierung eines Landkreises.
Vektordaten finden dort Verwendung, wo Flächengrößen, Wegelängen oder Grenzen ermittelt werden. Diese können mit Datenbanktabellen verknüpft werden und dienen somit zur Visualisierung der Datenbankinhalte.Weitere notwendige Merkmale von Geodaten sind thematische und temporale Eigenschaften. Mit thematischen Eigenschaften sind Sachattribute gemeint, beispielsweise der Name der Gemeinde oder die Einwohnerzahl eines Ortes. Temporale Eigenschaften beziehen sich auf einen Zeitpunkt oder einen Zeitraum, für den die betreffenden übrigen Eigenschaften gelten sollen.Daten, die in einem anderen Format vorliegen – etwa in Tabellen –, können in ein Raster- oder Vektordatenformat umgewandelt werden. In objektrelationalen Systemen lassen sich die oben genannten Primitiven, also Punkte, Linien oder Polygone, als Spatial Data Types definieren. Der Vorteil von Spatial Data Types­ liegt darin, dass diese nicht nur die geometrischen und topologischen Merkmale der Objekte enthalten, sondern auch Methoden zur Manipulation und Operationen für Abfragen an die Datenbank. Damit sind auch komplexe Abfragen möglich wie „Ermittle alle Straßen, die einen Fluss überqueren“.

Geometrieklassen in SQL/MM Spatial

Eine Reihe von Anwendungen kann aufgrund der Komple­xität der Datenstrukturen nicht mittels SQL-Standarddaten­typen, das heißt diverse Zahlendatentypen, Typen für Zeichenketten und so weiter, modelliert werden. Zur Lösung wurde die Erweiterung SQL/MM definiert. MM steht in dieser Abkürzung für Multimedia. Für Geodaten ist es die Erweiterung SQL/MM Spatial [9]. Wir geben dazu einen kompakten Überblick über die Geometrieklassen, die in diesem Standard definiert sind. SQL/MM Spatial erlaubt die Verwaltung räumlicher Daten in relationalen Datenbanksystemen. Bei einem Geometriemodell handelt es sich um ein abstraktes Modell. Es wird verwendet, um die Beziehung zwischen verschiedenen Klassen und die Vererbungsregeln für die Methoden festzulegen. Bild 4 stellt die Typhierarchie von SQL/MM Spatial dar. Bild 5 liefert ein paar anschauliche Beispiele. Dazu beachten Sie die folgenden Erläuterungen: ST_Geometry bildet den abstrakten Basistyp für eine 2D-Geometrie. Von diesem Typ werden alle weiteren Spatial-Data-Typen abgeleitet. Weitere abstrakte Typen sind auf dem Bild grau hinterlegt. Die wichtigsten Subtypen von ST_Geometry sind:
Typhierarchievon SSL/MM Spatial(Bild 4) © Bild: www.ogc.org [4]
Beispielevon Kurven(Bild 5) © Bild: www.ogc.org [4]
  • ST_Point: Wird verwendet zur Repräsentation eines Punktes im 2D-Raum.
  • ST_Curve: Ist eine Folge von Punkten, die interpoliert oder geschlossen sein können.
  • ST_LineString: Ist ein Subtyp von ST_Curve und wird für ­eine lineare Interpolation eingesetzt.
  • ST_CircularString: Ist ebenso ein Subtyp von ST_Curve, mit dessen Hilfe Kreisbögen interpoliert werden.
  • ST_Surface: Dient der Modellierung von Flächen.
  • ST_Polygon: Ist ein Subtyp von ST_Surface mit linearen ­Ringen.
An dieser Stelle sind vielleicht noch die folgenden Erläuterungen von Interesse. ST_Punkt-Werte sind nulldimensionale Geometrien und stellen nur einen einzigen Ort dar. Jeder Punkt besteht aus einer x- und einer y-Koordinate, um den Ort im jeweiligen Raum zu identifizieren. Punkte können beispielsweise verwendet werden, um kleinere reale Objekte wie einen Laternenpfahl zu modellieren. ST_MultiPoint-Werte stehen dagegen für eine Sammlung von Einzelpunkten. Kurven sind auch eindimensionale Geometrien. Der Standard SQL/MM Spatial unterscheidet zwischen ST_Line­String, ST_CircularString und ST_CompoundCurve. Flächen beziehungsweise ST_Surface sind zweidimensionale Geometrien und werden – wie Kurven – mit einer Folge von Punkten definiert. Die Grenze jeder Fläche ist eine Kurve oder ­eine Reihe von Kurven, wenn die Oberfläche Unterbrechungen aufweist. Die Typen ST_MultiSurface und ST_MultiPolygon werden verwendet, um Folgen von Kurvenpolygonen zu modellieren oder Polygone mit linearen Grenzen.Zu den oben genannten ST_Geometry-Typen werden eine Reihe von Methoden definiert. Diese ermöglichen die Durchführung geometrischer Operationen und die Abfrage von Objekteigenschaften und topologischer Beziehungen (Tabelle 1). Die Methoden zeigen, dass die Verwendung einer „Spezialdatenbank“ beziehungsweise die Nutzung einer Implementierung von SQL/MM Spatial nicht nur geeignete Datentypen für die Modellierung von geografischen Repräsentationen bietet, sondern auch mithilfe der Methoden typische Fragestellungen aus der Anwendungspraxis einer geobasierten Applikation leichter umgesetzt werden können. Ein Beispiel: Den Flächeninhalt einer durch ein geometrisches Objekt definierten Region bestimmen kann man näherungsweise auch „manuell“, wenn man die begrenzenden Punkte der Region hat. Dazu ist ein entsprechender Algorithmus zu implementieren, welcher die „Eckpunkte“ der Region in Form von Koordinaten entgegennimmt und als Ergebnis einen Näherungswert für den Flächeninhalt liefert. Der Aufruf der Methode ST_Area() macht dieses jedoch überflüssig, das heißt, die Arbeit wird von der Datenbank übernommen.

Tabelle 1: Im Standard SQL/MM Spatial definierte Methoden der Basisdatentypen

Methode Rückgabewert Erläuterung
ST_Dimension() smallint Liefert eine Angabe zur Dimension des geometrischen Wertes.
ST_Geometry_Type() varchar(128) Gibt eine String-Repräsentation des Datentyps zurück.
ST_IsEmpty() integer Prüft auf die leere Menge.
ST_IsSimple() integer Testet, ob es sich um eine einfache Geometrie handelt, das heißt ohne Schnitt.
ST_Boundary() ST_Geometry Liefert die Begrenzung eines Objekts.
ST_Envelope() ST_Polygon Liefert das minimale umschließende Rechteck.
ST_Length() double Dient zur Ermittlung der Länge einer Kurve.
ST_StartPoint() ST_Point Liefert den Startpunkt einer Kurve.
ST_EndPoint() ST_Point Liefert den Endpunkt einer Kurve.
ST_IsClosed() integer Überprüft, ob die Kurve geschlossen ist.
ST_IsRing() integer Überprüft, ob es sich um einen Ring handelt.
ST_Area() double Errechnet den Flächeninhalt der Region.
ST_Perimeter() double Bestimmt den Umfang des Objekts.
ST_Centroid () ST_Point Liefert den mathematischen Mittelpunkt.

Oracle Spatial

Wir haben bereits ausgeführt, dass es mehrere Optionen gibt, Geodaten in einer Datenbank zu verwalten. Zum einen ist da die Option, die „Spezialdatentypen“ in klassischen SQL-/NoSQL-Datenbanken zu verwenden (siehe die obige Liste). Eine auf Geodaten spezialisierte Datenbank ist Oracle Spa­tial. Diese ist eine Erweiterung des Oracle DBMS. Sie stellt eine konkrete Lösung für die Speicherung und Verwaltung raumbezogener Daten bereit. Geht es um größere Vorhaben mit einer Geodatenbank, dann kommt daher Oracle Spatial häufig zum Einsatz.Eine Besonderheit gegenüber der Funktionalität von SQL/MM Spatial besteht in der Unterstützung von Raster- und Topologiedaten. Oracle Spatial kennt nur einen Geo-Datentyp sdo_geometry. Anhand des Wertes dieses Typs können alle im Simple-Feature-Modell definierten Klassen repräsentiert werden, konkret [10]:
  • 2D-Raumdaten: Speichern von räumlichen 2D-Geodaten, beispielsweise Straßen, Verwaltungsgrenzen und dergleichen. Man kann zugehörige Abfragen formulieren, beispielsweise „Wie weit ist es?“ oder „Befindet sich das Objekt innerhalb der Region?“
  • 3D-Punktwolkendaten und Lichterkennung und -messung ­(LiDAR): Verwaltung von Daten aus Laserscanning oder durch Fotogrammetrie gewonnener Geo-Sensordaten zur Verwendung in 3D-geografischen Unternehmens-Informationssystemen (GIS) und Smart-City-Anwendungen. Die 3D-Unterstützung ist für Punktwolken- und CityGML-Workflows optimiert. Hinweis: Fotogrammetrie, auch Bildmessung genannt, ist eine berührungslose Mess- und Auswertungsmethode, um aus Fotografien eines Objekts durch Bildvermessung Informationen über die Lage und die Form des Objekts zu ermitteln.
  • Rasterdaten: Speichern und Verarbeiten von georeferenzierten Rasterdaten wie Satellitenbildern und gerasterten Daten für das Energiemanagement.
  • Netzwerkdaten: Modellierung von Straßentransport-, Telekommunikations-, Versorgungs-, Energie- und anderen Netzwerken. Es erfolgt eine Analyse dieser Daten, beispielsweise zur Suche nach kürzesten Wegen, den nächsten Nachbarn und so weiter.
  • Topologiedaten: Verwaltung vonTopologiedaten, die von Kartierungsanwendungen genutzt werden. Ein Layer-Konzept ist möglich.
  • Streaming-Punktdaten: Verfolgen ­einer großen Anzahl von sich bewegenden Objekten für Logistik- und IoT-Anwendungen und Durchführen von Analysen von sich bewegenden Personen und Objekten zum Zwecke der Kontaktverfolgung mithilfe eines API.
Sie erkennen: Diese Funktionen von Oracle Spatial sind auf spezielle Use-Cases ausgerichtet, beispielsweise aus den folgenden Bereichen: Polizeiarbeit, für sogenannte digitale Verbrechenskarten; Verwaltung von Landkarten; Anwendungen für Transport- und Logistikunternehmen und betriebswirtschaftliche Anwendungen, zum Beispiel für die Analyse von Kundenstandortdaten.

Zugriff auf Geodatenbanken

Sehen wir uns nun die Zusammenarbeit an, also konkret die Schnittstellen für die Nutzung einer Geodatenbank. Wir interessieren uns für die Programmierung aus dem .NET Framework heraus. Die Angelegenheit stellt sich nicht allzu schwierig dar, da wir auf bekannte Bibliotheken und gege­benenfalls einige Erweiterungen zurückgreifen können. Wir be­trachten die folgenden Aspekte:
  • Modellierung von Geodaten mit Klassen.
  • Zugriff über das Entity Framework Core.
  • Zugriff auf Oracle Spatial mit der Bibliothek dotConnect for Oracle.
Beginnen wir mit den speziellen Klassen für die Modellierung der Geodaten, also den geometrischen Entsprechungen. Hier haben wir mehrere Varianten. Für einfache geobasierte Modelle, das heißt nicht unbedingt für die Zusammenarbeit mit einer speziellen Geodatenbank, gibt es beispielsweise die Klasse GeoCoordinate im .NET Framework [11]. Diese bietet Basiseigenschaften, zum Beispiel Longitude, Latitude und Altitude für das Speichern von Geodatenpunkten.Darüber hinaus findet sich eine Methode GetDistance() zur Berechnung der Entfernung zwischen zwei Punkten. Dabei wird die sogenannte Haversine-Formel verwendet, um die Entfernung zu bestimmen. Hier gilt folgende Einschränkung: Die Haver­sine-Formel berücksichtigt die Krümmung der Erde, geht jedoch davon aus, dass eine kugelförmige Erde anstelle eines Ellipsoids vorliegt. Bei großen Entfernungen führt die Haversine-Formel zu einem Fehler von weniger als 0,1 Prozent. Die Höhe wird nicht verwendet, um den Abstand zu berechnen.Halten wir fest: Die Klasse GeoCoordinate können wir also verwenden, wenn wir Geodaten verarbeiten wollen und wir den gesamten Overhead der oben genannten Basisdaten­typen, das heißt die Spatial-Data-Typen, nicht benötigen. Beispielsweise können wir die Klasse einsetzen, wenn wir Standorte in einer Karte darstellen möchten. Für .NET Core gibt es diese Klasse nicht im Framework, es finden sich jedoch entsprechende Datentypen, wenn wir beispielsweise die Bibliothek eines Kartendienstes einbinden.Ebenso gibt es im Namespace System.Data.Spatial Klassen, die eine Modellierung der Spatial Data ermöglichen [12].Unbedingt erwähnen möchten wir die Bibliothek NetTopologySuite [13]. Das API mit seiner Fülle von Klassen und Methoden zum Modellieren und Manipulieren von zweidimen­siona­ler linearer Geometrie bietet zahlreiche geometrische Prädikate und Funktionen des Open-GIS-Konsortiums. Es ist ein Wrapper um die Basisbibliothek JTS Topology Suite [14].Kommen wir zum Zugriff auf Geodatenbanken. Die Transaktionen werden üblicherweise über das Entity Framework (EF) Core abgewickelt. Dieses bietet spezielle Datentypen und Funktionen für die Arbeit mit Geodaten, die in einer Datenbank verwaltet werden. EF Core nutzt für die Zuordnung der räumlichen Datentypen die eben vorgestellte Bibliothek NetTopologySuite [15]. Referenziert man diese Bibliothek im eigenen Projekt, dann hat man Zugriff auf die folgenden Geometrie-Namespaces: Point, LineString, Polygon, GeometryCollection, MultiPoint, MultiLineString und MultiPolygon. Die Datentypen CircularString, CompoundCurve und CurePolygon werden nicht unterstützt. EF Core unterstützt damit viele Funktionen einer Geodatenbank. Der Vorteil aus Entwicklersicht besteht darin, dass wir uns an keine alternative Vorgehensweise gewöhnen müssen. Wir können auf diese Weise beispielsweise mit den Geodaten-Funktionen der Datenbanken in Microsoft SQL Server oder SQLite arbeiten. Beides sind SQL-Datenbanken. Ebenso ist die Nutzung der Geodatenbank-Funktionen der Datenbank PostGIS als Extension der PostgreSQL über EF Core möglich. Hier handelt es sich um eine objektrelationale Datenbank. Dazu werden die .NET-Anweisungen in Anweisungen für die Datenbank durch die Bibliothek NetTopologySuite transformiert (Bild 6).
Mapping der .NET-Funktionenauf die Geodatenbank-Funktionen von PostGIS SQL(Bild 6) © Bild: www.npgsql.org [19]
Kommen wir noch final zu Oracle Spatial. Hier haben wir ebenfalls die Option, über EF Core zu gehen, wie bei den anderen Datenbanken auch. Möchten wir das erweiterte Funktionsspektrum dieser Geodatenbank (siehe oben) in einer
.NET-Anwendung nutzen, dann setzt man die Bibliothek dotConnect for Oracle ein, die unter [19] dokumentiert ist und in EF Core einzubinden ist.

Fazit

Geodatenbanken sind entweder Erweiterungen zu klassischen Datenbanken oder sie treten als „Spezial-DB“ auf. Wesentliche Merkmale sind ihre besonderen Datentypen, die sich an der Modellierung der Geografie für ­Orte, Räume, Regionen et cetera orientieren. Die vielfältigen Anwendungsmöglichkeiten werden durch spezialisierte Funk­tionen unterstützt, welche praktischerweise direkt in die Datenbank integriert sind. Aus Sicht der Softwareentwicklung ist der Zugriff auf eine Geodatenbank kein Hexenwerk. Wir können mit EF Core arbeiten und über spezielle Datentypen beziehungsweise Bibliotheken die Transaktionen auf die Datenbank ausführen. Viele interessante Anwendungsfälle ergeben sich, da umfassende Geodaten-Sammlungen über Webservices auch von öffentlicher Seite zur Verfügung gestellt werden.

Fussnoten

  1. GIS-Leitfaden, http://www.dotnetpro.de/SL2210GeoDB1
  2. Gunter Saake et al., Datenbanken. Konzepte und Sprachen, mitp, 2013, ISBN 978-3-95845-776-8,
  3. About OGC, http://www.dotnetpro.de/SL2210GeoDB9
  4. OGC, Geography Markup Language, http://www.dotnetpro.de/SL2210GeoDB2
  5. OGC, Styled Layer Descriptor & Symbol Encoding ­Specifications, http://www.dotnetpro.de/SL2210GeoDB3
  6. OGC, Symbology Encoding, http://www.dotnetpro.de/SL2210GeoDB4
  7. Geodatenportal Niedersachsen, Geodienste-Standards des OGC, http://www.dotnetpro.de/SL2210GeoDB5
  8. GeoJSON, http://www.dotnetpro.de/SL2210GeoDB7
  9. Knut Stolze, SQL/MM Spatial, http://www.dotnetpro.de/SL2210GeoDB8
  10. Geodatenbank von Oracle, http://www.dotnetpro.de/SL2210GeoDB10
  11. Microsoft Docs, GeoCoordinate-Klasse, http://www.dotnetpro.de/SL2210GeoDB11
  12. Microsoft Docs, Namespace System.Data.Spatial, http://www.dotnetpro.de/SL2210GeoDB16
  13. NetTopologySuite, http://www.dotnetpro.de/SL2210GeoDB12
  14. JTS Topology Suite, http://www.dotnetpro.de/SL2210GeoDB13
  15. Spatial Data, http://www.dotnetpro.de/SL2210GeoDB14
  16. Dokumentation zu dotConnect for Oracle, http://www.dotnetpro.de/SL2210GeoDB17
  17. „Well-known text“, http://www.dotnetpro.de/SL2210GeoDB6
  18. Thomas Brinkhoff, Geodatenbanken in Theorie und ­Praxis, Wichmann, 2022, ISBN 978-3-87907-694-9,
  19. Spatial Mapping with NetTopologySuite, http://www.dotnetpro.de/SL2210GeoDB15

Neueste Beiträge

DWX hakt nach: Wie stellt man Daten besonders lesbar dar?
Dass das Design von Websites maßgeblich für die Lesbarkeit der Inhalte verantwortlich ist, ist klar. Das gleiche gilt aber auch für die Aufbereitung von Daten für Berichte. Worauf besonders zu achten ist, erklären Dr. Ina Humpert und Dr. Julia Norget.
3 Minuten
27. Jun 2025
DWX hakt nach: Wie gestaltet man intuitive User Experiences?
DWX hakt nach: Wie gestaltet man intuitive User Experiences? Intuitive Bedienbarkeit klingt gut – doch wie gelingt sie in der Praxis? UX-Expertin Vicky Pirker verrät auf der Developer Week, worauf es wirklich ankommt. Hier gibt sie vorab einen Einblick in ihre Session.
4 Minuten
27. Jun 2025
„Sieh die KI als Juniorentwickler“
CTO Christian Weyer fühlt sich jung wie schon lange nicht mehr. Woran das liegt und warum er keine Angst um seinen Job hat, erzählt er im dotnetpro-Interview.
15 Minuten
27. Jun 2025
Miscellaneous

Das könnte Dich auch interessieren

UIs für Linux - Bedienoberflächen entwickeln mithilfe von C#, .NET und Avalonia
Es gibt viele UI-Frameworks für .NET, doch nur sehr wenige davon unterstützen Linux. Avalonia schafft als etabliertes Open-Source-Projekt Abhilfe.
16 Minuten
16. Jun 2025
Mythos Motivation - Teamentwicklung
Entwickler bringen Arbeitsfreude und Engagement meist schon von Haus aus mit. Diesen inneren Antrieb zu erhalten sollte für Führungskräfte im Fokus stehen.
13 Minuten
19. Jan 2017
Evolutionäres Prototyping von Business-Apps - Low Code/No Code und KI mit Power Apps
Microsoft baut Power Apps zunehmend mit Features aus, um die Low-Code-/No-Code-Welt mit der KI und der professionellen Programmierung zu verbinden.
19 Minuten
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige