Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
+49 (0) 351/8 33 82-0

Neuerungen in SQL Server 2008: Räumliche Datentypen

Genau wie der Datentyp HierarchyId, so sind auch die neuen räumlichen Datentypen geometry und geography CLR-Datentypen, die in jeder Datenbank verfügbar sind – unabhängig davon, ob CLR-Funktionen aktiviert sind.

Der geometry-Datentyp erlaubt die Darstellung von Daten im kartesischen Koordinatensystem und die Durchführung von Berechnungen mit diesen Daten.
Das möchte ich an einem Beispiel verdeutlichen:
image3

In diesem Koordinatensystem befinden sich 2 geometrische Figuren. Ein Strahl mit den Endpunkten (0; 0), (100; 200) und ein Quadrat mit den Eckpunkten (-40; -40), (100; -40), (100; 100), und (-40, 100).

Die Deklaration einer Tabelle zur Speicherung der Daten ist recht trivial. Hierzu erzeugt man einfach eine Tabellenspalte vom Typ Geometry in die man die Daten schreibt.

Ich möchte hier allerdings auf die Möglichkeiten des Datentyps eingehen. Daher werden in den folgenden Beispielen nur Variablen dieses Datentyps erzeugt. Mit Hilfe der statischen Methode STGeomFromText kann aus einem normalsprachlichen Text (dem sogenannten „Well Known Text“ = WKT) eine geometrische Instanz erzeugt werden. Im Beispiel ist das:

DECLARE @line geometry;
SET @line =
geometry ::STGeomFromText(‚LINESTRING (0 0, 100 200)‘,0)
DECLARE @rectangle geometry;
SET @rectangle = geometry ::STGeomFromText(‚POLYGON ((-40 -40, 100 -40, 100 100, -40 100, -40 -40))‘,0)

Wie man sieht, wird hier die Art der geometrischen Figur angegeben  und Punkte, die die Figur näher beschreiben. Das Quadrat ist verallgemeinert ein Polygon, daher ist der WKT hier POLYGON. Zu beachten ist bei Polygonen, dass Start- und Endpunkt übereinstimmen müssen.

Soweit ganz gut. Das Erzeugen und Speichern von Daten an sich ist recht langweilig. Was können die Methoden, die geometry zur Verfügung stellt?

STAsText: STAsText gibt den WKT für ein geometry-Objekt zurück.

STArea: Diese Funktion berechnet die Oberfläche von geometrischen Objekten. Im Fall der Linie ist die Oberfläche 0, aber das ist ehrlich gesagt auch nicht verwunderlich. Im Fall des Quadrats hat die Methode korrekt 140 * 140 = 19600 zurückgegeben.

STIntersection: Mit STIntersection wird die Überschneidung zweier Objekte berechnet. Das Ergebnis der Berechnung im Beispiel ist eine Linie mit den Endpunkten (0; 0) und (50; 100) – und genau das kann man auch sehr schön im Diagramm ablesen.

STLength: Ein letztes Beispiel an dieser Stelle soll STLength sein. Wie der Name schon vermuten lässt, kann damit die Länge bzw. der Umfang der Objekte berechnet werden.

Die Anwendungsfälle dafür können sehr vielfältig sein. Beispielsweise könnte hier die Entfernung zwischen Gebäuden oder Objekten berechnet werden.

Die Berechnung von Entfernungen mit STLength oder Flächen mit STArea auf geraden Flächen ist nur dann sinnvoll, wenn es sich um kurze Distanzen handelt. Möchte man Entfernungen in der realen Welt berechnen, ist der geometry-Datentyp aufgrund der Krümmung der Erde nicht mehr geeignet. Der geography-Datentyp schafft hier Abhilfe:

Wie schon vom Geometry-Datentyp bekannt, kann ein Objekt mittels der statischen Methode STGeomFromText erzeugt werden. Allerdings spielt hier die dort recht unwichtige SRID hier eine wesentliche Rolle. Sie definiert, anhand welchen Standards Berechnungen durchgeführt werden. In der MSDN findet man zum Thema folgendes:

geometry Instances Default to Zero SRID

The default SRID for geometry instances in SQL Server is 0. With geometry spatial data, the specific SRID of the spatial instance is not required to perform calculations; thus, instances can reside in undefined planar space. To indicate undefined planar space in the calculations of geometry data type methods, the SQL Server Database Engine uses SRID 0.

geography Instances Must Use Supported SRID

SQL Server supports SRIDs based on the EPSG standards. A SQL Server-supported SRID for geography instances must be used when performing calculations or using methods with geography spatial data. The SRID must match one of the SRIDs displayed in the sys.spatial_reference_systems catalog view. As mentioned previously, when you perform calculations on your spatial data using the geography data type, your results will depend on which ellipsoid was used in the creation of your data, as each ellipsoid is assigned a specific spatial reference identifier (SRID).

SQL Server uses the default SRID of 4326, which maps to the WGS 84 spatial reference system, when using methods on geography instances. If you use data from a spatial reference system other than WGS 84 (or SRID 4326), you will need to determine the specific SRID for your geography spatial data.

Im Gegensatz zu Geometry muss für die Initialisierung der Geography-Objekte also zwingend eine SRID angegeben werden. Der Standard ist aktuell 4362. Eine Übersicht der gültigen SRIDs erhält man, wenn man die Systemsicht sys.spatial_reference_systems aufruft:
image11

Es gibt noch eine weitere Einschränkung: Geography-Instanzen dürfen die Hemisphäre nicht überschreiten. Diese Einschränkung spielt natürlich erst dann eine Rolle, wenn man nicht mehr nur geographische Punkte speichert, sondern Berechnungen durchführen möchte und z.B. Entfernungen berechnet. Eine in meinen Augen gute Erklärung für diese Einschränkung liefert ein Blogeintrag von Steve Kass zum Thema. Darin wird auch gut beschrieben, weshalb die Punkte von Polygonen immer entgegen des Uhrzeigersinns angegeben werden müssen.

1 Kommentar

Avatar Bernd Viehmann

Guter Artikel. Vielen Dank.

Ich frage mich nur noch wie man die geometry-Daten aus der SQL-Server Datenbank in Koordinaten für Google-Maps konvertiert.

Viele Grüße

Bernd Viehmann

Kommentar hinterlassen


Pin It on Pinterest