Geography - Bildungsportal Sachsen

4.5. Speicherung von Geodaten
Anforderungen an die Speicherung
• Funktionalität der Speicherung und des Retrieval
• Effizienz der Abfrage
 Retrieval eines einzelnen Geoobjekts
 Punktanfragen
 Rechteckanfragen
 Regionsanfragen
 Abstandsanfragen
 Räumlicher Verbund
 Nächste‐Nachbarn‐Anfrage
 … Untersuchung möglicher Konzepte und Technologien:
 Speicherung in klassischen relationalen Strukturen
 Speicherung in BLOB
 Nutzung objektrelationaler Features
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
35
Relationale Speicherung
Charakteristik des relationalen Modells: nur atomare Datentypen
 Komplexe Datentypen müssen zerlegt werden
Beispiel: SELECT Punkt.laenge, Punkt.breite, Ring.RingID, Ring.art
FROM Bundesland, MultiPolygon, Polygon, Ring, Punkt
WHERE Bundesland.name = ´Sachsen´ AND
Bundeslang.mPolyID = Multipolyon.mPolyID AND
Multipolygon.mPolyID = Polygon.mPolyID AND
Polygon.polyID = Ring.polyID AND
Ring.ringID = Punkt.ringID
ORDER BY Multipolygon.mPolyID, Polygon.polyID,
Ring.ringID, Punkt.pos;
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
36
Speicherung als BLOB
• Speicherung der Geoobjekte als Binary Large Object (BLOB)
• Speicherung (und Retrieval) der Geometrien als Ganzes, aber
• keine Möglichkeit der Anfragebearbeitung und ‐optimierung
• keine Unterstützung für geometrische Operationen
• keine Überprüfung der Korrektheit von Geometrien
 für Vektorgeometrien nicht geeignet
 aber: für bestimmte Geoobjekte (Rasterbilder, Multimedia‐Objekte) trotzdem eine gute Lösung
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
37
Objektrelationale DBMS: Grundlagen
Erweiterung des relationalen Modells • Die grundlegenden Konzepte wie Ablage der Daten in Tabellen, deklarative Anfragesprache und alle DBMS‐Eigenschaften bleiben erhalten!
• Mengenwertige Attribute  Schachtelung / Entschachtelung in der Anfragesprache notwendig!
• Geschachelte Relationen  ein Attribut kann nicht nur mengenwertig sein, sondern sogar wieder selbst eine Relation
• Referenzen  ein Attribut kann eine Referenz auf andere Tupel (der gleichen oder einer anderen Relation enthalten)  nicht mehr auf Fremdschlüssel zur Realisierung von Beziehungen beschränkt
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
38
Objektrelationale DBMS: SQL‐Standard
Definiert in SQL:1999 –Erweiterungen nochmals in SQL:2003
Wichtige Konzepte
 User Defined Types (UDT)–(im Standard heißen diese Abstract Data Types, ADT)  User Defined Functions (UDF), um die definierten Datentypen „vernünftig“ benutzen zu können ( Methoden)
 Vererbungshierarchien für Tabellen und Typen  Objektidentitäten für komplexe Tupel in Relationen
Anwendung für unterschiedliche Bereiche
 vom Anwender selbstdefinierte, proprietäre Datentypen für spezielle Anwendung
 Komplex strukturierte Daten wie XML‐Daten, Geodaten, …
 Idealfall: Standardisierung der Bezeichnungen der UDTs und UDFs für eine bestimmte Anwendungsdomäne im SQL‐Standard Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
39
Objektrelationale Geodatenbanksysteme
 Definition eigener geometrischer Basistypen als Klassen (Umsetzung in objektrelationalen DBMS als UDTs)
 Erforderliche geometrische Methoden können den geometrischen Klassen hinzugefügt werden (Umsetzung in objektrelationalen DBMS als UDFs)
 In vielen Datenbankbetriebssystemen umgesetzt
– Oracle 10g/11g (Oracle Spatial) – IBM Informix (Spatial DataBlade) und DB2 (Spatial Extender)
– MS SQL Server 2005 u. 2008
– PostgreSQL/PostGIS
– MYSQL (Erweiterungen für geometrische Daten)
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
40
4.6. Geodaten im MS SQL Server 2008
Spatiale Datentypen des MS SQL Servers
Der SQL Server 2008 unterstützt zwei Typen von Geodaten:

Geometry ‐ flaches Erdmodell  für projizierte Koordinatensysteme (planar) und lineare Bezugssysteme

Geography ‐ rundes Erdmodell
 für geographische Koordinatensysteme (geodätisch)
• Beide Arten unterstützen alle OGC Typen
Geometry
Geography
 Unterstützung für Legacy Systeme
 Geeignet z.B. für Innenräume (Architektur, ...)
 Einfacher in der Berechnung
 Konzept schwieriger für geospatial
 Unterstützt existierende Anforderungen für weite Entfernungen (Schiffe, Militär, ...)
 Unterstützt neuere Geo‐
Anwendungen
 Komplexer in der Berechnung
 Einfacheres Konzept für geospatial
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
41
Arbeit mit spatialen Datentypen
 Geodaten mit dem Datentyp geometry oder geography werden binär gespeichert
 Instanzen des Typs können NULL sein
 Eingabe als
‐ Weil known Binary ‐ ST[Type] FromWKB
‐ Weil known Text ‐ ST[Type] FromText
‐ Geography Markup Language (GML) ‐ GeomFromGml
Außerdem SQLCLR Funktionen (MS SQL Common Language Runtime)
‐ Parse
‐ Point
 Jeder Typ unterstützt eine Anzahl von Methoden und Properties, die mit den OGC übereinstimmt
‐ Zusätzliche Erweiterungen für die Typen (MakeValid, Reduce, …)
‐ GEOMETRY implementiert alle OGC Properties und Methoden
‐ GEOGRAPHY implementiert die meisten OGC Eigenschaften und Properties
Beispiel:
Prof. Dr. G. Gräfe
CREATE TABLE Districts (
DistrictId int IDENTITY (1,1),
DistrictName nvarchar(20),
DistrictGeo geometry );
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
42
Datentyp Geometry – Point und LineString
Geometrietyp
Neben dem allgemeinsten Typ GEOMETRY können (u.a.) auch alle Typen des Simple‐Feature‐Modells angegeben werden: POINT, LINESTRING, POLYGON etc.
SRID falls kein räumliches Bezugssystem vorliegt, ist 0 anzugeben
Quelle: Microsoft – SQL Server
Beispiel:
INSERT INTO Districts (DistrictName, DistrictGeo)
VALUES ('Mensa', 'POINT (‐5 ‐5)');
INSERT INTO Districts (DistrictName, DistrictGeo)
VALUES (‚Weg',
geometry::STGeomFromText('LINESTRING (5 160, 10 115, 135 100)', 0));
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
43
Datentyp Geometry – einfaches Polygon
INSERT INTO Districts (DistrictName, DistrictGeo)
VALUES ('HTW',
WKT‐Format
geometry::STGeomFromText
('POLYGON ((10 25, 80 10, 150 145, 50 180, 15 115, 60 110, 10 25))', 0));
SELECT DistrictID, DistrictGeo,
Districts.DistrictGeo.STAsText() ‐‐ Klartext über STAsText() FROM Districts Where DistrictID=4
WKB‐Format
WKT‐Format
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
44
Datentyp Geometry – Multipolygon
Beispiel: Polygon mit Ausschnitt
INSERT INTO Districts (DistrictName, DistrictGeo)
VALUES ('Bibliothek',
geometry::STGeomFromText
('POLYGON(( 80 60, 100 100, 120 90, 100 50, 80 60 )' ‐‐ Ab hier der Ausschnitt "Innenhof" + ', ( 90 65, 100 90, 110 90, 100 60, 90 65))',0));
SELECT * FROM Districts;
GEOMETRY arbeitet „in der Ebene“:
Ein Polygon ist unabhängig der Ausrichtung eindeutig definiert
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
45
Datentyp Geography
Beispiel:
CREATE TABLE Gebiet
(GebietsId int IDENTITY (1,1), GebietsName nvarchar(20),
GebietGeo geography );
Anforderungen beim Datentyp Geography:
 Koordinaten werden in Breiten‐/Längengrad eingegeben
 Ändert sich zu Längengrad/Breitengrad vor RTM
 Koordinaten von außengelegene Polygonringe müssen „gegen den Uhrzeiger“ angegeben werden („Linke‐Hand“‐Regel), innen liegende (Löcher) „mit dem Uhrzeiger“
äußere Koordinaten innere Koordinaten
(Im Gegensatz dazu ist beim Datentyp GEOMETRY ist ein Polygon unabhängig der Ausrichtung eindeutig definiert)
 Ein einzelnes Geometrieobjekt kann nicht mehr als eine halbe logische Hemisphäre umfassen.
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
46
Koordinatentransformation beim Datentyp geography
001
002
003
004
005
006
N51 02.262 E13 44.212
N51 02.296 E13 44.107
N51 02.222 E13 44.117
N51 02.227 E13 44.074
N51 02.117 E13 44.144
N51 02.132 E13 44.070
109 m
109 m
110 m
110 m
111 m
111 m
Koordinatentransformation,
„Linke‐Hand“‐Regel beachten
INSERT INTO Gebiet VALUES ('HTW‘,
geography::STGeomFromText ( 'POLYGON (( 13.44212 51.02262
, 13.44107 51.02296
, 13.44074 51.02227
, 13.44117 51.02222
, 13.44070 51.02132
, 13.44144 51.02117
, 13.44212 51.02262 ) )’ ,4326) );
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
47
Polygon mit Ausschnitt beim Datentyp geography
INSERT INTO Gebiet VALUES ('Niedersachen‚
geography::STGeomFromText(
'POLYGON ( ( 10.7080 51.6387 , 10.5596 51.9899
, 10.9734 52.0562
(in Uhrzeigerrichtung)
…
, 7.0424 52.2062
, 7.6176 52.4459
, 8.0267 52.1244
, 8.5208 52.1644
, 8.3500 52.4635
, 9.1354 52.4687
, 9.7164 51.2969
, 10.7080 51.6387 )' ‐‐ Ab hier der Ausschnitt "Bremen" + ',
( 8.5009 53.2254
, 8.9835 53.1127
„Linke‐Hand“‐Regel
, 8.9287 52.9992
(gegen Uhrzeigerrichtung)
, 8.7099 53.0355
, 8.6237 53.1599
, 8.5009 53.2254) )'
SRID: Geographisches Koordinatensystem WGS84 , 4326));
(EPSG‐Code: 4326) in Dezimalgrad
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
48
Methoden auf spatiale Datentypen
Vielzahl von Methoden für
 Validierung von Geometrien
 Metrische Funktionen
 Geometrische Funktionen
 Verschneidungen
 Topologische Beziehungen
 Geometrische Aggregatfunktionen
 Koordinatentransformationen
…
STArea
STAsBinary
STAsText
STBoundary
STBuffer
STCentroid
STContains
STConvexHull
STCrosses
STDifference
• GEOMETRY implementiert alle OGC Properties und STDimension
STDisjoint
Methoden
• GEOGRAPHY implementiert die meisten OGC Eigenschaften STDistance
STEndpoint
und Properties
STEnvelope
STEquals
Siehe MSDN‐Library
STExteriorRing
STGeometryN
OGC‐Methoden für geometry‐Instanzen:
http://msdn.microsoft.com/de‐de/library/bb933960.aspx STGeometryType
STInteriorRingN
STIntersection
OGC‐Methoden für geography‐Instanzen:
STIntersects
STIsClosed
STIsEmpty
STIsRing
STIsSimple
STIsValid
STLength
STNumGeometries
STNumInteriorRing
STNumPoints
STOverlaps
STPointN
STPointOnSurface
STRelate
STSrid
STStartPoint
STSymDifference
STTouches
STUnion
STWithin
STX
STY
http://msdn.microsoft.com/de‐de/library/bb933802.aspx
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
49
Geometrische Methoden (1)
Validierung von Geometrien:
• Prüfung der Korrektheit von Geometrien
• wird (aufgrund des Rechenaufwands) standardmäßig nicht überprüft
• Funktionen zur Überprüfung: STIsValid
Metrische Funktionen:
• Länge eines Linienzuges: STLength bzw. Umfang von Flächen (STBoundary)
• Flächeninhalt einer Geometrie: STArea
• Abstand zwischen zwei Geometrien: STDistance
Beispiele: SELECT A.GebietName,
A.Gebiet.STArea() / 1000000 AS FlaecheKM2,
A.Gebiet.STLength() / 1000 AS UmfangKM
FROM Gebiet AS A;
DECLARE @punkt geography;
SET @punkt = geography::Parse('POINT(7.0424 52.2062)');
Neue Instanz als
Bezugspunkt
SELECT ID, GebietName, Gebiet.STDistance(@punkt) / 1000 AS [Abstand KM] FROM Gebiet ORDER BY Gebiet.STDistance(@punkt);
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
50
Geometrische Methoden (2)
Geometrische Funktionen:
Geometrische Funktionen, die zu einem Geometrieobjekt ein anderes Geometrieobjekt berechnen:
• Minimal umgebendes Rechteck: STEnvelope
• Konvexe Hülle: STConvexHull
• Pufferzone: STBuffer
Verschneidungen:
Verschneidungsoperationen zweier Geometrien, deren Ergebnis eine neue Geometrie ist
• STIntersection (Überschneidung)
• STUnion (Vereinigung)
• STDifference (Differenz)
• STSymDifference
Beispiel:
Prof. Dr. G. Gräfe
DECLARE @a geometry; DECLARE @b geometry;
SET @a = geometry::STGeomFromText('POLYGON((0 0, 0 2, 2 2, 2 0, 0 0))', 0);
SET @b = geometry::STGeomFromText('POLYGON((1 1, 3 1, 3 3, 1 3, 1 1))', 0);
SELECT @a.STIntersection(@b).ToString();
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
51
Geometrische Methoden (3)
Topologische Funktionen: ‐ Topologische Beziehung zweier Geo‐Objekte:
• STEquals (Gleichheit)
• STDisjoint (keinerlei Berührung)
DECLARE @pkt geography;
• STIntersects (nicht Disjoint)
• STTouches (Randberührung) SET @pkt = geography::Parse
('POINT(13.44107 51.02296)');
SELECT * FROM Gebiet
WHERE Gebiet.STDisjoint(@pkt) = 1;
Die Ränder von geom1und geom2schneiden sich, nicht aber deren Inneres.
• STCrosses (sich kreuzen)
Die Dimension des Schnitts von geom1mit geom2 ist kleiner als die maximale Dimension von geom1und geom2 und der Schnitt enthält innere Punkte von geom1und geom2 und der Schnitt ist nicht gleich geom1oder geom2.
• STOverlaps (Überlappung im strengen Sinne)
Die Dimension des Schnitts von geom1mit geom2ist gleich der Dimension von geom1und geom2 und der Schnitt ist nicht gleich geom1oder geom2.
• STWithin (sich innerhalb befinden)
• STContains (enthalten)
‐ Aufbau der topologischen Funktionen (auch hier „Richtung“ beachten!)
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
52
4.7. Anfragebearbeitung in Geodatenbanksystemen
Räumliche Basisanfragen (1)
Punktanfragen
Rechteckanfragen
Regionsanfragen
Abstandsanfragen
Geometrischer Verbund (Spatial Join)
Abbildungen: Brinkhoff: Geodatenbanksysteme Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
53
Rechteckanfrage
Räumliche Selektion mit Anfragegeometrien (z.B. Rechteckanfrage)
 Anfragegeometrien können direkt spezifiziert werden oder durch die Funktionen MakePoint(Float, Float)und MakeBox2D(Geometry, Geometry) konstruiert werden.
Beispiel einer Rechteckanfrage:
SELECT geo
FROM Stadt
WHERE geo && MakeBox2D(MakePoint(55,55), MakePoint(115,155)); Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
54
Räumliche Basisanfragen (2)
‐ NearestNeighborQuery (NNQ):  bestimmt zu einem Geoobjekt das nächstgelegene Objekt oder die k nächstgelegenen Objekte. Alternativ kann die Suche auch von einem Anfragepunkt p aus erfolgen.
 Verschiedene Varianten der NNQ:  einfache NNQ: bestimmt als Anfrageergebnis das Geoobjekt aus M, das den geringsten Abstand zu p aufweist
 k‐NearestNeighborQuery: bestimmt die k nächstgelegenen Nachbarn aus M zu p(k: ganze Zahl größer 0)  inkrementelle NNQ: bestimmt zunächst das zu p nächstgelegene Geoobjekt aus M. Danach kann wiederholt das (nächste)
Objekt mit der geringsten Distanz zu p abgerufen werden
Abbildung: Brinkhoff: Geodatenbanksysteme Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
55
Mehrstufige Anfragebearbeitung
Anfrage in mehreren Stufen durch Filterschritte:
• Identifikation von Kandidaten und Treffern in frühen Filterschritten durch schnell ausführbare Algorithmen und Datenrepräsentationen. • erst im letzten Schritt (Verfeinerungsschritt, Refinement Step): aufwändiger exakter Test der Anfragebedingung auf einer reduzierten Kandidatenmenge:
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
56
Approximationen (1) Konservative Approximationen • enthalten die Geometrie vollständig
• dienen in erster Linie dazu, Fehltreffer auszuschließen
• sind meist konvex, wodurch Berechnungen beschleunigt werden
Wichtigste konservative Approximation: MUR (Minimal umgebendes Rechteck) bzw. MBR (Minimum Bounding Rectangle) Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
57
Approximationen (2) Verschiedene Varianten der konservativen Approximation: MUR
gedrehtes MUR
Konvexe Hülle MU 5‐Eck Quelle: Brinkhoff: Geodatenbanksysteme Abwägen zwischen Genauigkeit (Minimierung der Fehlfläche) und Speicherbedarf sowie dem Aufwand beim Test einer Anfragegeometrie
 Beachtung des Zusammenhanges zu räumlichen Index
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
58
4.7. Indexierung von Geodaten
Indexstrukturen in klass. DBMS
B‐Baum
B*‐Baum
Ein B*‐Baum ist ein ausgeglichener sortierter Mehrweg‐Schlüsselbaum, in dessen Nichtblattknoten die Schlüssel und Zeiger zum nächsten Knoten und in dessen Blättern die Tupel (Sätze) stehen.




Schlüsselbaum:
Mehrweg:
sortiert:
ausgeglichen:
In den Knoten des Baumes sind Schlüssel abgespeichert.
Jeder Knoten kann mehrere Nachfolger haben (außer Blätter).
Die Schlüssel in den Knoten einer Ebene sind aufsteigend sortiert.
Die Äste des Baumes haben die gleiche Länge.
ABER: Eignung für Geodaten (Geometrieobjekte)? Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
59
Räumliche Indexe: Anforderungen
Räumliche Indexstrukturen müssen
 Approximationen von Punkten, Linien und Flächen verwalten
 Räumliche Basisanfragen effizient ausführen
 Daten, die räumlich benachbart sind (und daher in räumlichen Anfragen häufig gemeinsam eingelesen werden), sollten mit hoher Wahrscheinlichkeit in einem gemeinsamen Datenbankblock liegen
 Geoobjekte laufend einfügen, löschen und verändern können, wobei die Effizienz der Indexstruktur dadurch sich nicht (wesentlich) verschlechtern darf
 eine gute Speicherplatzausnutzung garantieren
 robust bzgl. Anfragezeiten und Speicherplatzausnutzung gegenüber Ungleichverteilungen der Geoobjekte im Datenraum sein
Räumliche Indexstrukturen wichtiges Instrument zur effizienten Ausführung von räumliche Filteroperationen in Geodatenbanksystemen Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
60
Quadtree
Prinzip: k‐dimensionaler Datenraum wird rekursiv in 2k gleich große Zellen („Kacheln“) unterteilt
 Varianten für Punkte, Linien und Flächen
Probleme dieses Ansatzes:
 Blöcke mit sehr wenigen Geo‐Objekten
 Was passiert beim Überlauf?
Beispiel: PR‐Quadtree (Point‐Region‐Quadtree)
Quelle: Brinkhoff: Geodatenbanksysteme Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
61
Spatial Indexes für Datentyp GEOMETRY in MS SQL (1)
1. Bevor Daten in einen räumlichen Index eingelesen werden, erfolgt eine einheitliche hierarchische Zerlegung des Raums. Während der Indexerstellung wird der Raum in eine vier Ebenen umfassende Rasterhierarchie zerlegt.
Quelle: Microsoft – SQL Server
2. Festlegung der Rasterdichte
Prof. Dr. G. Gräfe
Schlüsselwort
Rasterkonfiguration
Anzahl von
Zellen/Ebene
Anzahl Zellen auf Ebene 4
LOW
4X4
16
65.536
MEDIUM
8X8
64
16.777.216 HIGH
16X16
256
4.294.967.296
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
62
Spatial Indexes für Datentyp GEOMETRY in MS SQL (2)
CREATE SPATIAL INDEX index_name
ON <object> ( spatial_column_name )
USING GEOMETRY_GRID WITH ( BOUNDING_BOX = ( xmin=0, ymin=0, xmax=500, ymax=200 ), GRIDS = (LOW, LOW, MEDIUM, HIGH), CELLS_PER_OBJECT = 64);
Quelle: Microsoft – SQL Server
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
63
Spatial Indexes für Datentyp GEOGRAPHY in MS SQL (1)
Zur Zerlegung des Raums des geodätischen Ellipsoides unterteilt das Geografierastermosaikschema die Oberfläche des Ellipsoids in eine obere und eine untere Hemisphäre.
Schritte:
1. Jede Hemisphäre wird auf die Facetten einer vierseitigen Pyramide projiziert.
2. Die beiden Pyramiden werden auf eine Ebene reduziert. 3. Die vereinfachten Pyramiden werden verbunden, sodass sie eine nicht‐
euklidische Ebene bilden.
Prof. Dr. G. Gräfe
Quelle: Microsoft – SQL Server
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
64
Spatial Indexes für Datentyp GEOGRAPHY in MS SQL (2)
‐ Aufbau analog des Index für Datentyp geometry, aber Verwendung einer standardisierten Rasterstruktur
‐ sind für diesen Datentyp aus Performancegründen dringend erforderlich, einige OGC‐Methoden benötigen diesen Index zwingend
Beispiele:
CREATE SPATIAL INDEX indexname
ON <tabelle> (geography‐attribut) USING GEOGRAPHY_GRID
CREATE SPATIAL INDEX indexname
ON <tabelle> (geography‐attribut) WITH ( BOUNDING_BOX = ( 4033140, 5080080, 4885090, 6108780 ))
Vereinfachte obere Hemishäre
Vereinfachte untere Hemishäre
Quelle: Microsoft – SQL Server
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
65
R‐Baum: Idee
Alle bisher vorgestellten Verfahren haben den Datenraum in disjunkte Teile aufgeteilt.
 Objekte, die die Grenzen dieser disjunkten Blöcke überlappen, müssen mehrfach gespeichert werden müssen
 Anderer Ansatz: Speicherung von Blockregionen, die sich ggf. überlappen können, aber die jeweils die Geometrien vollständig enthalten Implementierung beruht auf dem GiST:
• Projekt der Datenbankgruppe der University of Berkeley
• B+‐Bäume, R‐Bäume und andere Indexstrukturen haben eine relativ ähnliche Grundstruktur und Einfüge‐, Lösch‐und Suchalgorithmen Bereitstellung einer verallgemeinerten, einfach anpassbaren Indexstruktur, die die Funktionalität all dieser Indexstrukturen in einem Programmpaket bereitstellt: GeneralizedSearchTree (GiST)
• http://gist.cs.berkeley.edu/
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
66
R‐Baum: Aufbau
Aufbau eines R‐Baums:
• Höhenbalancierter Baum • Datenknoten (= Blattseiten) enthalten MURs der Geometrieobjekte
• Directory‐Knoten enthalten Indexeinträge der Form (R, Ref) mit  R: Rechteck
 Ref: Referenz auf einen Teilbaum, wobei R die Datenrechtecke des zugehörigen Teilbaums minimal überdeckt Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
67
R‐Baum: Punkt‐und Rechteckanfragen
Bearbeitung Punktanfragen:
• Start bei der Wurzel: Bestimmung aller Einträge (Rechtecke), welche den Anfragepunkt enthalten
• Rekursive Fortsetzung auf jeder Ebene bis zu den Datenknoten
Bearbeitung Rechteckanfragen:
• Start bei der Wurzel: Bestimmung aller Einträge (Rechtecke), die das Anfragerechteck schneiden
• Rekursive Fortsetzung für jedes ermittelte Rechteck auf jeder Ebene bis zu den Datenknoten
Quelle: Brinkhoff: Geodatenbanksysteme Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
68
Vergleich Quadtree und R‐Baum
Welche Datenstruktur ist als Zugriffsstruktur für Geoobjekte geeigneter?
 Pauschal nicht zu beantworten, auch aufgrund der Fülle von Varianten
 Quadtrees sind die am häufigsten verwendeten räumlichen Zugriffsstrukturen in Geo‐Informationssystemen
 Vergleich der in Oracle verfügbaren Quadtrees mit R‐Bäumen zeigte jedoch, dass R‐
Bäume i. A. geeigneter sind (Quelle: Seeger)
 Trend in Geodatenbanksystemen heute eher zu R‐Bäumen Quadtrees und R‐Bäume sind wichtigste spatiale Indexstrukturen
 Vielzahl von Varianten für verschiedenste Geometrietypen (Quadtrees) bzw. unterschiedliche Split‐Strategien (R‐Bäume)
 Animation verschiedener Varianten: http://donar.umiacs.umd.edu/quadtree/
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
69
Erweiterungen von Geo‐DBS ‐ Verwaltung von Rasterdaten
1. einfachste Variante: Speicherung als BLOB
2. Spezielle Rasterdatenbanksysteme (rasdaman)
3. Erweiterungen „normaler“ DBMS – z.B. Oracle Spatial GeoRaster
•
Georeferenzierung
Umrechung Welt‐/Pixelkoordinaten
•
Anfrageunterstützung
Zugriff Pixelwerte/Teilbereiche
räumliche Indexierung
•
Speicherung
Komprimierung
Kachelung
Bildpyramiden
•
Technische Umsetzung
objektrelationale Typen mit entsprechenden Attributen und Methoden
Quelle: Brinkhoff: Geodatenbanksysteme Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
70
Erweiterungen von Geo‐DBS ‐ 3‐D‐Geodatenbanken
Anwendungen:
 3D‐Stadtmodelle
 Klimamodelle für Simulationen
 Luftfahrtinformationssysteme mit Flugplatz‐und Hindernisdaten
 Geologische Anwendungen
 AugmentedReality
Herausforderungen:
 3D‐Datenmodell (schon im abstrakten OGC Feature GeometryModel definiert, aber noch nicht in den Implementierungsstandards Simple Feature bzw. SQL/MM Spatial umgesetzt)
 3D‐Anfragebearbeitung
• Basisanfragen
• Indexierung
• Geometrische Algorithmen
Quelle: Bild: www.cybercity3d.com
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
71
Erweiterungen von Geo‐DBS ‐ Spatio‐Temporale Geo‐DBMS
Anwendungen:
 Umweltinformations‐und ‐analysesysteme
 Telematik‐Anwendungen  Location‐BasedServices
Herausforderungen:
 Geoobjekte besitzen zusätzliche Angaben (Transaction Time, ExpirationTime, Geschwindigkeit, Richtung, …)
 Räumliche, zeitliche und spatio‐temporale Basisanfragen müssen effizient unterstützt werden
Anfragen / Indexierung der Vergangenheit, Gegenwart (und Zukunft)
 Änderungen können genauso häufig wie Anfragen erfolgen
Quelle: Bild: www.geo.de
Prof. Dr. G. Gräfe
EDBT/MA ‐ 4. Geo‐Datenbanksysteme
|
72