Open-Source Geodatenbanken

Open-Source Geodatenbanken
Benjamin Winter
Betreuer: Prof. Dr. Bernhard Möller
Dieses Seminar stellt verschiedene Open-Source Geodatenbanksysteme vor. Zu Beginn wird kurz die Geschichte der bekanntesten
drei Vertreter PostGIS, Spatialite und MySQL erläutert. Danach
werden die drei Systeme in ihrem Funktionsumfang verglichen und abschlieÿend noch einige Fähigkeiten von Geodatenbanken am Beispiel von
Spatialite aufgezeigt.
Abstract.
1
Einleitung
Immer mehr technische Geräte wie z.B. Handys, Smartphones und Digitalkameras sind mit GPS-Empfängern ausgestattet. Besonders im Bereich der Smartphones und Handys, die meist schon Internetfähigkeiten besitzen, können die
gewonnen Geodaten auf einfache Weise einem Onlinedienst zur Verfügung gestellt
werden, der diese dann entsprechend aufbereitet und dem Benutzer wieder verfügbar macht. So kann man z.B. bei Facebook seinen Standort mitteilen und
Freunde, die sich gerade in der Nähe benden und auch ihren Standort mitgeteilt haben, ausndig machen. Das ist jedoch nur ein Beispiel der vielfältigen
Anwendungsmöglichkeiten von Geodatenbanksystemen. Dazu sind meist keine
teuren Produkte von kommerziellen Herstellern nötig, es gibt auch einige OpenSource Geodatenbanken. Im Folgenden werden PosGIS, Spatialite sowie MySQL
als die gröÿten und bekanntesten Vertreter davon vorgestellt und miteinander
verglichen. Im Anschluss daran werden auch noch einige praktische Beispiele mit
Spatialite aufgezeigt. Diese sind einfach und unkompliziert umzusetzen, da man
für die Verwendung von Spatialite auf dem Computer nichts installieren oder
einrichten muss.
2
2.1
Geschichte
PostGIS
Die allgemein bekannte Geschichte der Open-Source Geodatenbanken beginnt
mit PostGIS[1][2]. PostGIS wurde von Refractions Research als eine Erweiterung
der PostgreSQL-Datenbank entwickelt. Im Mai 2001 hat Refractions Research
festgestellt, dass die in PostgreSQL schon rudimentär vorhandenen Geometriedatentypen nicht ausreichen, um Geoinformationsdaten ezient zu speichern und
zu verarbeiten. Die bisherige Vorgehensweise war, Geodaten, die die Fähigkeiten
von PostgreSQL überstiegen, in Dateien auszulagern oder als BLOB zu speichern. Beides war nicht sehr leistungsfähig. Folglich hat man damit begonnen, einen
2
Open-Source Geodatenbanken
eigenen Datentyp für Geodaten zu entwickeln. Schon die ersten Implementierungen dieses Datentyps waren zehnmal schneller als das Speichern in BLOBs. Die
seitdem zahlreich entwickelten Funktionen zum Umgang mit den neuen Daten
wurden in der GEOS-Bibliothek zusammengefasst. Die GEOS-Bibliothek ist eine
C++-Portierung der JTS Topology Suite und kann auch von anderen Datenbanksystemen, z.B. Spatialite, benutzt werden. Seit Version 0.8, die schlieÿlich
im Jahr 2003 erschienen ist, hat PostGIS den Standard ISO 19125 "Simple Feature Access" vollständig in die GEOS-Bibliothek implementiert. Mit Version 1.0
(April 2005) wurde ein nochmals verbessertes Datenformat zur internen Speicherung der Geodaten standardmäÿig eingeführt (die Entwicklung begann jedoch schon ab Version 0.8). Seit Version 1.2 (2006/2007) wird in PostgreSQL
der SQL/MM-Standard implementiert. Dieser Standard hat den Vorteil, dass
er mehr Geometrische Objekte als ISO 19125 beschreibt. Diese Erweiterungen
der Datenbank-Funktionen hat man jedoch nicht mehr in die GEOS-Bibliothek
aufgenommen, da diese Bibliothek nur den Simple Feature Access-Standard implementiert. Die aktuelle Version ist 1.5.2 (September 2010).
2.2
MySQL
Ein weiteres Open-Source Datenbanksystem ist MySQL. Es unterstützt seit Version 4.1 (2003) räumliche Erweiterungen zu diesem Zeitpunkt jedoch nur für
Tabellen, die die MyISAM-Storage Engine nutzen[5]. Generell wird, wie auch bei
PostGIS und Spatialite, der Simple Feature Access-Standard umgesetzt. Davon
wurden allerdings einige Teile nicht implementiert. Seit Version 5.0.16 (Nov 2005)
unterstützen auch die Storage-Engines InnoDB, NDB, BDB und ARCHIVE die
Geodaten-Spalten[6]. Genauere Funktionen für topologische Prädikate (beispielsweise Intersects, Overlaps und Touches) existieren seit Version 5.6.1 (April
2011). Diese neuen Funktionen beginnen mit einem "ST_"-Präx und haben
den Vorteil, dass sie nicht mehr mit der Hüllgeometrie (MBR, Minimal Bounding Rectangles), sondern mit den exakten geometrischen Formen arbeiten[7][8].
2.3
Spatialite
Eine Open-Source Datenbank mit einem etwas anderen Ansatz, aber auch mit
Unterstützung für räumliche Daten, ist Spatialite. Dies ist eine Erweiterung der
SQLite Programmbibliothek, welche eine schlanke, serverlose SQL-DatenbankEngine ist. Wegen dieser Eigenschaften ist nicht der komplette Funktionsumfang von Standard-SQL gegeben. Für genauere Informationen sei auf das Kapitel
"Funktionsumfang" verwiesen. Die erste Version von Spatialite ist im März 2008
erschienen[3]. Seit Version 2.0 vom Juni 2008 integriert Spatialite die GEOSBibliothek und befolgt somit vollständig den Simple Feature Access-Standard.
Zusätzlich wird die PROJ.4 Bibliothek, die Kartographie-Projektionen möglich
macht, seit Version 2.2 (September 2008) unterstützt. Die aktuelle Versionsnummer lautet 2.3.1 (Juli 2009). Die wichtigsten Neuerungen dieser Version
sind das Hinzufügen der SQL-Math-, sowie die Erweiterung um Funktionen
zum Umgang mit EXIF-GPS Daten. Seit Dezember 2009 wird an Version 2.4.0
Open-Source Geodatenbanken
3
gearbeitet, wobei letzter Stand der Entwicklung Version 2.4.0.RC-4 (November
2010) ist[4]. Diese ist jedoch noch experimentell und nicht zum alltäglichen Einsatz gedacht. Die wichtigsten, schon implementierten Neuerungen bis jetzt sind:
Konvertierungsfunktionen für KML und GML, Geschwindigkeitsverbesserungen
beim Routingalgorithmus sowie Unterstützung für DBF-Dateien.
3
Funktionsumfang im Überblick
Die Open-Source Datenbank mit dem wohl gröÿten Funktionsumfang stellt zweifelsohne PostGIS dar. PostGIS implementiert sowohl den Simple Feature AccessStandard komplett, als auch Teile des SQL/MM-Standards, sowie eigene Funktionen. Einige Beispiele für diese Funktionen wären das Konvertieren in SVG
bzw. KML und die Bildung von Polygonen aus Streckenzügen[9](Kapitel 3.2).
Eine weitere Datenbank mit einem groÿem Funktionsumfang im Hinblick auf
Geodaten ist SpatiaLite, eine Erweiterung der Standalone-Datenbank SQLite,
welche keine Client-Server-Architektur besitzt. Die Datenbank wird in einer
einzelnen Datei gespeichert. Deswegen funktionieren die SQL-Statements GRANT
und REVOKE nicht, da nur die Zugrisrechte der Datenbank-Datei gelten. Es
existieren noch einige weitere, nur eingeschränkt funktionsfähige SQL-Funktionen
[10]. Eine hiervon ist ALTER TABLE, die nur RENAME und ADD COLUMN unterstützt. DELETE, INSERT oder UPDATE funktionieren beispielsweise nicht auf Views und der FOR EACH STATEMENT-Trigger ist unter den
Funktionen überhaupt nicht vorhanden (FOR EACH ROW jedoch schon).
Dadurch, dass für die räumlichen Funktionen die gleiche Bibliothek wie bei
PostGIS, nämlich GEOS, zum Realisieren des Simple Feature Access-Standards
verwendet wird, steht SpatiaLite dem PostGIS-Datenbanksystem hinsichtlich
dieses Standards in nichts nach. Neben der GEOS-Bibliothek wird auch die
PROJ.4-Bibliothek verwendet. Dadurch kann man mit der Funktion "Transform" ein geometrisches Objekt von einem Koordinatensystem in ein anderes
transformieren (identiziert durch eine SRID)[11]. Ein sehr interessantes Feature von SpatiaLite / SQLite ist die Unterstützung für sogenannte "Virtual
Tables": Man kann eine Modul entwickeln, das auf beliebige Datenquellen zugreift und diese für SQLite als Tabelle, und somit für beliebige SQL-Statements
zur Verfügung stellt. In SpatiaLite sind einige solcher Module bereits enthalten.
Beispielsweise VirtualShape und VirtualText, wobei ersteres Zugri auf Shapeles (ein "Shapele" besteht aus mehreren Dateien und beschreibt Punkte, Linien, Flächen oder Multi-Punkte). Auch eine Routing-Funktion, die Dijkstra's
Algorithmus zur Berechnung der kürzesten Wege nutzt, kann durch das Modul
VirtualNetwork genutzt werden.
Im Vergleich zu den beiden anderen vorgestellten Datenbanksystemen ist
MySQL das mit dem kleinsten Funktionsumfang bezogen auf Geodaten. Wie
schon im Geschichts-Kapitel erwähnt, setzt MySQL generell auch den Simple
Feature Access-Standard um, jedoch nicht komplett. Die Verschneidungsoperationen Union() und Intersection() zum Erstellen von neuen Daten aus schon
vorhandenen wurden weggelassen. Des Weiteren werden keine GIS Metadaten
4
Open-Source Geodatenbanken
abgespeichert. Ebenso wird die SRID, welche die Eigenschaften eines Koordinatensystems beschreibt, zwar abgespeichert, aber nicht bei räumlichen Berechnungen berücksichtigt. Bei den räumlichen Berechnungen wird das zugrunde
liegende Koordinatensystem nur als planar betrachtet[12].
3.1
Überblick
Im Folgenden wird der Funktionsumfang der einzelnen Standards und Datenbanksysteme im tabellarischen Überblick zusammengefasst: Die Tabelle stammt
urspünglich aus [9] S. 3 und wurde an manchen Stellen erweitert und aktualisiert.
Funktionen
ISO
19125
Zugri auf Basiseigenschaften
(Dimension,
GeometryType, Zugri auf
die Geometriebestandteile)
Test von
Geometrieeigenschaften
(IsSimple, IsClosed,
IsRing)
Messfunktionen (Length,
Area, Distance)
Geometrische Funktionen auf
einer Geometrie(Distance,
Envelope, Centroid,
Buer, ConvexHull)
Verschneidungsoperationen
Topologische Prädikate gemäÿ
Dimensionally-Extended
9-Intersection Matrix
[Clementini & DiFelice 1996]
Konvertierung in
Well-Known-Text (WKT)
Well-Known Binary (WKB)
Konvertierung in Geography
Markup Language (GML)
X
SQL/ Post- Spatia-lite Mysql
MM
GIS
Spatial
X
X
X
X
X
X
X
X
(X)
X
X
X
X
X
X
X
X
X
(X)
X
X
X
X
X
X
X
X
(X)
X
X
X
X
X
X
X
Open-Source Geodatenbanken
Konvertierung in Scalable
Vector Graphics (SVG) und
Keyhole Markup Language
(KML)
Validierung von Geometrien
Koordinatentransformationen
Approximation von
Kurvensegmenten durch
Streckenzüge
Gesonderte geometrische
Funktionen und
Verschneidungen auf
achsenparallelen Rechtecken
Generalisierung und
Polygonisierung von Linien
Geometrische
Aggregatfunktionen
4
X
X
X
X
SVG; seit
2.4.0 RC 4
auch KML
X
X
X[13]
X[14]
5
X
X
X
Anwendungsbeispiele mit SpatiaLite
Jetzt sollen ein paar Anwendungsbeispiele von Geodatenbanken aufgezeigt werden. Dazu wird die Datenbank-Engine SpatiaLite benutzt. Um diese zu verwenden, reicht es aus, ein Programm herunterzuladen und auszuführen. Es ist
keine Installation oder Einrichtung am Computer notwendig. Die entsprechenden Dateien kann man von der Homepage [15] herunterladen. Prinzipiell ist es
egal, ob man spatialite-gui oder die Kommandozeilenversion (spatialite-tools)
benutzt. Da jedoch die GUI die Geometrischen Daten auch auf einfache Weise
darstellen kann, beziehen sich die folgenden Beispiele auf die GUI-Version.
Zum schnellen Einstieg wird auch eine Beispieldatenbank von [16] verwendet. Die folgenden Beispiele beziehen sich auf die "World.7z": In dieser, noch
gepackten, Datenbank sind alle Staaten der Welt aufgeführt. Zu jedem Staat in
der Datenbank sind Informationen wie beispielsweise die kartographischen Daten
als "Geometry", sowie die Flagge und das Wappen als Bild vorhanden. Neben
der Staatentabelle existiert eine weitere Tabelle mit dem Namen "Admin", aus
der beispielsweise ersichtlich wird, in welche Bereiche ein Staat unterteilt ist. Im
Falle von Deutschland sind dies die Bundesländer. Die "Cities"-Tabelle sollte
auch noch erwähnt werden. Dort sind neben den Koordinaten der jeweiligen
Stadt auch Informationen darüber enthalten, zu welchem Land sie gehört oder
ob sie eine Hauptstadt ist.
Um die Datenbank zu verwenden, startet man spatialite-gui, wählt im Menü
"Files -> Connecting an existing SQLite DB" aus und selektiert dann die aus der
"world.7z" entpackte Datei "world.sqlite". Das Hauptfenster des Programms ist
in drei Bereiche unterteilt: auf der linken Seite sind die Tabellen der Datenbank
6
Open-Source Geodatenbanken
zu sehen, auf der rechten Seite oben ein Eingabefeld für SQL-Befehle und unten
das Ergebnis der Abfrage. Um die Daten einer Tabelle anzusehen, kann man diese
mit der rechten Maustaste anklicken und den Menüpunkt "Edit Table Rows"
auswählen. Dadurch wird auch automatisch das SQL-Statement, das verwendet
wurde, um die Tabelle auszugeben, in das SQL-Eingabefeld eingetragen. Dort
kann es nach Belieben abgeändert werden (z.B. um uninteressante Spalten zu
entfernen). Durch einen Klick auf den Button rechts neben dem Eingabefeld
aktualisiert sich die Ausgabetabelle dann automatisch.
4.1
Geodaten ansehen
Da man nun mit der Funktionsweise des Programms spatialite-gui grob vertraut
sein müsste, könnte man sich als nächsten Schritt einmal die Geodaten aus einer
der Tabellen ansehen: Zu Beginn lässt man sich beispielsweise Deutschland aus
der Tabelle "Countries" der Beispieldatenbank ausgeben. Die interessanten Spalten sind dabei der Name des Landes und dessen Geodaten im Original, sowie
eine, in ein anderes Koordinatensystem transformierte, Ausgabe davon.
SELECT CNTRY_NAME as Name, Geometry as OriginalGeodaten,
TRANSFORM(Geometry, 32632) as TransformierteGeodaten
FROM Countries
WHERE CNTRY_NAME like 'germany'
ORDER BY CNTRY_NAME;
Das Ergebnis erscheint wie gewohnt unterhalb des Eingabefeldes. Nach einem
Rechtsklick auf eine Zelle in der Spalte OriginalGeodaten bzw. TransformierteGeodaten kann man "Blob Explore" auswählen und bekommt eine hexadezimale
Ansicht der Daten präsentiert, die jedoch für die hier aufgeführten Beispiele
nicht von Bedeutung ist. Wechselt man jedoch zur Registerkarte "Geometry Explorer", sieht man ein Bild der zuvor ausgewählten Daten. Fig. 1 zeigt auf der
linken Seite das Bild, das ausgegeben wird, wenn man die Spalte OriginalGeodaten ausgewählt hat und auf der rechten Seite das Bild, das entsteht, wenn man
die Spalte TransformierteGeodaten angeklickt hat.
Man kann erkennen, dass Deutschland in der OriginalGeodaten-Spalte etwas zusammengestaucht aussieht, in der TransformierteGeodaten-Spalte jedoch
normal erscheint. Das liegt an der SRID, die zum Abspeichern der Geodaten verwendet wurde. Eine genauere Erklärung dazu war bereits Thema eines anderen
Vortrages. Aus diesem Grund wird hier nicht weiter darauf eingegangen. Sieht
man sich nun das Fenster mit der Grakanzeige der Geodaten etwas genauer
an, ndet man auf der linken Seite auch einige Informationen zu den Daten an
sich. Hier kann man unter anderem erkennen, dass Daten mit der SRID 4326
vorliegen. In der "spatial_ref_sys"-Tabelle sind alle, vom Open Geospatial Consortium im Simple Feature Access - Standard denierten, SRID's abgespeichert.
Sucht man dort nach der SRID 4326, ndet man das zugehörige Referenzsystems
"WGS 84". Diese Erkenntnis wird gleich noch benötigt.
Open-Source Geodatenbanken
Fig. 1.
4.2
7
OriginalGeodaten (links) und TransformierteGeodaten (rechts)
Neueinträge
Wenn man sich die Tabelle "Cities" einmal genauer ansieht, wird man feststellen, dass dort die Stadt "Augsburg" nicht enthalten ist. Diese Informationslücke kann man durch einen Neueintrag beheben. Um Augsburg korrekt einzutragen, benötigt man zunächst einmal die Koordinaten in einer für das weitere
Vorgehen passenden Notation. An eine Auswahl von Notationen gelangt man
am einfachsten, indem man im Wikipedia-Eintrag [17] auf die Koordinaten auf
der rechten Seite direkt unter dem Titel klickt. Aber welche dieser Koordinaten
eigenen sich nun für die hier verwendete Beispieldatenbank? Dass es sich um
WGS-84-Koordinaten handelt, wurde schon herausgefunden. Es stellt sich jedoch die Frage, wie das in die Datenbank eingetragen wird. Dazu sieht man sich
einmal an, wie die anderen (deutschen) Städte eingespeichert wurden:
SELECT WUP_AGGL, AsText(Geometry) FROM Cities
WHERE CNTRY_Name LIKE 'Germany';
Die Funktion AsText(Geometry) gibt dabei die Geodaten in Form von WellKnown-Text, wie im Simple-Feature-Access-Standard deniert, aus. Jetzt kann
man erkennen, dass München ein "POINT" mit den Koordinaten 11.5833 und
48.1333 ist. Wenn man nun die Koordinaten von München, analog der Vorgehensweise bei Augsburg, sucht, wird man feststellen, dass die auf der GeoHackSeite[18] gefunden Koordinaten bis auf die Darstellung in umgekehrter Reihenfolge ziemlich genau mit denen der Datenbank übereinstimmen.
Da München jedoch recht groÿ ist, soll diese Ungenauigkeit nicht weiter
stören.
Da nun die für die Datenbank benötigte Notation der von Augsburg gefunden
Koordinaten bekannt ist, kann man sich den Well-Known-Text von Augsburg
zusammenstellen:
POINT(10.898333 48.371667)
8
Open-Source Geodatenbanken
Um zu erfahren, auf welche Weise man die neu gewonnenen Geodaten in die
Datenbank eintragen kann, könnte man die Hilfe aufrufen. Der Button hierzu
bendet sich in der Symbolleiste. Nach einem Klick auf das linke der beiden
blau hinterlegten Fragezeichen önet sich ein Hilfefenster. Dort sticht sogleich
die Überschrift "functions for constructing a geometric object given its Wellknown Text Representation" ins Auge. Nach einem Klick auf den Link ndet
man eine Funktion, die sich "PointFromText(...)" nennt. Die Well-Known-Text
von Augsburg ist inzwischen bekannt und man kann einen neuen Eintrag in der
Datenbank anlegen:
INSERT INTO Cities(WUP_AGGL, Geometry) VALUES
('Augsburg', PointFromText('POINT(10.898333 48.371667)', 4326));
Wichtig ist, dass die einzelnen Koordinaten nicht durch ein Komma getrennt
werden, denn wenn dies der Fall ist, stürzt SpatiaLite aufgrund eines Speicherzugrisfehlers ab.
4.3
Räumliche Lagebeziehungen
Mit SpatiaLite kann man sich auch alle in der Beispieldatenbank vorhandenen
Städte ausgeben lassen, die sich in Deutschland benden. Dies ist entweder mit
Standard-SQL möglich, indem man aus der Tabelle Cities alle Zeilen ausgeben
lässt, deren CTNRY_NAME-Spalte gleich "Germany" ist oder man nutzt die
räumliche Funktion Contains() und lässt sich alle Zeilen aus der Cities-Tabelle
ausgeben, deren Geodaten innerhalb von Deutschland liegen. Da im vorherigen Schritt, beim Eintragen von Augsburg in die Datenbank, die Spalte CNTRY_NAME nicht ausgefüllt wurde, könnte man mit Standard-SQL die Stadt
Augsburg nicht mehr Deutschland zuordnen. Daher wird im folgenden Beispiel
die Variante mit der räumlichen Funktion benutzt:
SELECT WUP_AGGL AS Name
FROM Cities, Countries
WHERE Countries.CNTRY_Name LIKE 'Germany'
AND Contains(Countries.Geometry, Cities.Geometry)
ORDER BY WUP_AGGL;
Wie man sehen kann,1 steht Augsburg an zweiter Stelle der Ergebnistabelle.
4.4
Entfernungsmessung
Eine weitere nützliche Funktion von SpatiaLite, die auch im OpenGIS Standard beschrieben ist[19], ist DISTANCE(). Sie erwartet zwei Parameter vom
Typ Geometry. Im folgenden Beispiel soll die Entfernung der Augsburger Universität zum Königsplatz ausgegeben werden. Dafür benötigt man zuerst die
jeweiligen Koordinaten. Diese können ohne viel Aufwand über die Internetseite openrouteservice.org herausgefunden werden. Openrouteservice ist ein
frei verfügbarer Routenplaner, basierend auf den Daten von openstreetmap.
Open-Source Geodatenbanken
9
org. Um die Koordinaten für die Universität in Augsburg herauszunden, kann
folgendermaÿen vorgegangen werden: Man gibt im Abschnitt "Routenplaner"
als Startpunkt "Augsburg Universität" ein und klickt auf "Setze". Die Karte
wird nun im rechten Teil der Seite auf den entsprechenden Kartenausschnitt
eingestellt. In der Kartenansicht bendet sich auch ein grüner Pfeil, welcher die
soeben gesuchte Position anzeigt. Wenn der Pfeil mit der Maus verschoben wird,
ändert sich automatisch der Inhalt des Eingabefeldes der Startposition zu den
Koordinaten, auf die der Pfeil zeigt. Diese Koordinaten können ebenfalls zum
Eintragen in die Datenbank verwendet werden.
Nachfolgend werden Beispieldaten für die Universität und den Königsplatz
in die Tabelle Cities eingetragen:
INSERT INTO Cities(WUP_AGGL, Geometry)
VALUES('Augsburg UNI',
GeomFromText('POINT(10.898868 48.333856)', 4326));
INSERT INTO Cities(WUP_AGGL, Geometry)
VALUES('Augsburg Königsplatz',
GeomFromText('POINT(10.894311 48.365317)', 4326));
Zu Beachten ist dabei noch, dass spatialite-gui nur das erste SQL-Statement
durchführt, auch wenn im Eingabefeld mehrere eingetragen sind. Man muss also
beide gesondert einfügen und ausführen. Die Kommandozeilenversion führt wie
erwartet alle Statements aus.
Nun möchte man die Entfernung zwischen der Universität und dem Königsplatz
herausnden:
SELECT DISTANCE(
(SELECT Geometry FROM Cities
WHERE WUP_AGGL LIKE 'Augsburg UNI'),
(SELECT Geometry FROM Cities
WHERE WUP_AGGL LIKE 'Augsburg Königsplatz'))
AS 'Entfernung';
Es stellt sich jedoch die Frage, in welcher Einheit das Ergebnis 0.031789 vorliegt.
Wenn man sich die spatial_ref_sys Spalte noch einmal genauer ansieht, erkennt
man, dass dort eine Spalte proj4text existiert. Diese Spalte ist für die Projektion
zuständig. In der Ausgabe von
SELECT srid, ref_sys_name, proj4text
FROM spatial_ref_sys
WHERE srid = 4326
OR srid = 32632;
wird ersichtlich, dass bei SRID 32632 in der proj4text-Spalte der Text "+units=m"
enthalten ist. In der entsprechenden Spalte der SRID 4326 ist kein solcher Wert
enthalten. Man kann also davon ausgehen, dass Geodaten mit der SRID 32632
die Einheit Meter benutzen. Also noch einmal die Entfernungs-Abfrage, diesmal
mit transformierten Daten:
10
Open-Source Geodatenbanken
SELECT DISTANCE(
(SELECT Transform(Geometry,32632)
FROM Cities
WHERE WUP_AGGL LIKE 'Augsburg UNI'),
(SELECT Transform(Geometry,32632)
FROM Cities
WHERE WUP_AGGL LIKE 'Augsburg Königsplatz')) AS 'Entfernung(m)';
Das Ergebnis ist dieses Mal: 3514.086873. Die Entfernung von der Universität
zum Königsplatz beträgt also ca 3,5 Kilometer.
4.5
Umkreisbestimmung
Um, wie in der Einleitung beschrieben, Freunde in der Nähe ausndig machen
zu können, gibt es mehrere Möglichkeiten. Da die Beispieldatenbank nicht aus
Positionen von Freunden besteht, wird angenommen, dass die eigene Position
"Augsburg UNI" ist und die Freunde jeweils in anderen Städten sitzen. Gesucht
werden Freunde, die sich in Orten im Umkreis von beispielsweise 130 Kilometern
benden. Da wieder mit der SRID 32632 gearbeitet werden muss, um Strecken
in Metern anzugeben, merkt man sich die Textdarstellung der eigenen Position
im gewünschten Koordinatensystem:
SELECT ASTEXT(Transform(Geometry,32632)) FROM Cities
WHERE WUP_AGGL LIKE 'Augsburg UNI';
Das Ergebnis ist: "POINT(640727.734896 5355150.367024)" Das weiter Vorgehen besteht darin, alle Orte zu nden, die höchstens 130 Kilometer von "Augsburg UNI" entfernt sind: Die oensichtlichste, jedoch nicht ezienteste Methode,
wäre, alle Städte auszugeben, deren Entfernung zur eigenen Position maximal
130 km beträgt:
SELECT WUP_AGGL FROM Cities
WHERE DISTANCE(
PointFromText('POINT(640727.734896 5355150.367024)', 32632),
Transform(Geometry,32632)) <= 130000;
Als Ergebnis erhält man neben Augsburg, Augsburg UNI und Augsburg Königsplatz auch noch München und Nürnberg. Eine ezientere Methode besteht
darin, einen Rahmen mit dem Radius 130 Kilometer um die eigene Position
zu erstellen und zu prüfen, welche Städte darin enthalten sind. SpatiaLite unterstützt "minimal bounding rectangles" und bietet mit der Funktion BuildCircleMBR(x, y, Radius, SRID) auch eine einfache Möglichkeit solche zu erstellen.
Hierbei ist zu beachten, dass es sich beim daraus resultierenden geometrischen
Objekt nicht um einen Kreis, sondern um das kleinste Quadrat, das den Kreis
enthält, handelt. Ein einfaches Contains(BuildCirleMBR(..), ..) reicht also nicht
aus. Da auch Städte mit einer Entfernung > 130 km im Rechteck enthalten
sind, müssen diese noch gesondert ausgeltert werden. Dazu misst man wie im
vorherigen Beispiel die exakte Entfernung:
Open-Source Geodatenbanken
11
SELECT WUP_AGGL FROM Cities
WHERE MBRContains(
BuildCircleMBR(640727.734896, 5355150.367024, 130000, 32632),
Transform(Geometry,32632))
AND Distance(
PointfromText('POINT(640727.734896 5355150.367024)', 32632),
Transform(Geometry,32632)) <= 130000;
Da jetzt nur die Entfernung der Städte berechnet werden muss, die innerhalb
des minimalen Rechtecks liegen, müsste diese Alternative schneller sein. Da beim
Ausführen der verschiedenen Abfragen subjektiv kein Geschwindigkeitsunterschied festgestellt werden kann, bräuchte man eine exakte Möglichkeit die Ausführungszeit zu messen. Eine solche ist mit spatialite-gui aber nicht gegeben.
Man kann jedoch die Kommandozeilenversion des Programms verwenden (unter
Windows: spatialite.exe aus dem Archiv spatialite-tools-win-x86-2.3.1.zip). Hierzu schlieÿt man das Fenster von "spatialite-gui" und startet "spatialite" mit
der Datenbank-Datei "world.sqlite" als Parameter. In der Eingabeauorderung
von spatialite kann man mit dem Befehl
.timer on
einschalten, dass gemessen wird wie lange die Ausführung eines SQL-Statements
dauert. Diese Zeit wird nach dem Ergebnis jedes Statements ausgegeben. Das
Statement, das die Entfernung zu jeder Stadt in der Datenbank misst, dauert
auf dem zum Testen verwendeten Netbook mit einer Taktrate von 800 MHz
im Durchschnitt ca 0.4 Sekunden. Das Statement, das nur die Entfernung der
Städte innerhalb des Rechtecks misst, dauert hingegen durchschnittlich nur ca
0.36 Sekunden. Es ergibt sich also ein Geschwindigkeitsvorteil von ca 11 %.
References
1. PostGIS : News
http://postgis.refractions.net/news/
Besucht: 05.05.2011
2. Refractions Research : PostGIS History
http://www.refractions.net/products/postgis/history/
Besucht: 05.05.2011
3. SpatiaLite and VirtualShape version history
http://www.gaia-gis.it/spatialite/changelog.html
Besucht: 05.05.2011
4. SpatiaLite 2.4.0 RC-4
http://www.gaia-gis.it/spatialite-2.4.0-4/changelog.html
Besucht: 05.05.2011
5. MySQL :: MySQL 3.23, 4.0, 4.1 Reference Manual :: 16 Spatial Extensions
http://dev.mysql.com/doc/refman/4.1/en/spatial-extensions.html
Besucht: 05.05.2011
12
Open-Source Geodatenbanken
6. MySQL :: MySQL 5.0 Reference Manual :: D.1.80 Changes in MySQL 5.0.16 (10
November 2005)
http://dev.mysql.com/doc/refman/5.0/en/news-5-0-16.html
Besucht: 05.05.2011
7. MySQL :: MySQL 5.6 Reference Manual :: D.1.3 Changes in MySQL 5.6.1 (Not
released Milestone 5)
http://dev.mysql.com/doc/refman/5.6/en/news-5-6-1.html
Besucht: 05.05.2011
8. MySQL :: MySQL 5.6 Reference Manual :: 11.17.5.4 Functions for Testing Spatial
Relations Between Geometric Objects
http://dev.mysql.com/doc/refman/5.6/en/functions-for-testing-spatial-relations-between-geometric-ob
html#functions-that-test-spatial-relationships-between-geometries
Besucht: 05.05.2011
9. Thomas Brinkho. Open-Source-Geodatenbanksysteme. Datenbank-Spektrum,
Heft 22, pp. 37.44, dpunkt-Verlag, August 2007
10. SQL Features That SQLite Does Not Implement
http://www.sqlite.org/omitted.html
Besucht: 05.05.2011
11. SpatiaLite SQL functions reference list
http://www.gaia-gis.it/spatialite/spatialite-sql-2.3.1.html
Besucht: 05.05.2011
12. MySQL :: GIS and Spatial Extensions with MySQL
http://dev.mysql.com/tech-resources/articles/4.1/gis-with-mysql.html
Besucht: 05.05.2011
13. SpatiaLite C APIs reference list
http://www.gaia-gis.it/spatialite/spatialite-C-API-2.3.1.html#p12
Besucht: 05.05.2011
14. SpatiaLite v.2 tutorial
http://www.gaia-gis.it/spatialite-2.0/SpatiaLite2-tutorial.html#t5
Besucht: 05.05.2011
15. SpatiaLite precompiled binaries download page
http://www.gaia-gis.it/spatialite/binaries.html
Besucht: 05.05.2011
16. SpatiaLite Resources
http://www.gaia-gis.it/spatialite/resources.html
Besucht: 05.05.2011
17. Augsburg Wikipedia
http://de.wikipedia.org/wiki/Augsburg
Besucht: 05.05.2011
18. GeoHack - München
http://toolserver.org/~geohack/geohack.php?pagename=M%C3%
BCnchen&language=de&params=48.136944444444_N_11.575277777778_E_region:
DE-BY_type:city%281330440%29
Besucht: 05.05.2011
19. SpatiaLite SQL functions reference list
http://www.gaia-gis.it/spatialite/spatialite-sql-2.3.1.html#p13
Besucht: 05.05.2011