Rasterdatenunterstützung in relationalen Datenbanksystemen
Oberseminarvortrag zur gleichnamigen Studienarbeit
16. November 2004Marco Pagel
Themenüberblick
1. Geographische Daten2. Grundlagen3. Datenbanksysteme und
Darstellungswerkzeuge4. Funktionale Anforderungen an eine
Rasterdatenunterstützung5. Entwurf
Themenüberblick
1.1. Geographische DatenGeographische Daten2. Grundlagen3. Datenbanksysteme und
Darstellungswerkzeuge4. Funktionale Anforderungen an eine
Rasterdatenunterstützung5. Entwurf
1. Geographische Daten Geographische Informationssysteme (GIS)
verwenden verschiedene Datenformate um räumliche Informationen darzustellen
Vektordaten Rasterdaten
Zusätzlich werden beschreibende Informationen mit abgelegt
Metadaten
1. Geographische Daten
Rasterdaten Struktur:
regelmäßige Matrix gleich großer, rechteckiger Zellen
2 dimensional Pixel jede Zelle besitzt ein Attribut (Eigenschaft) für die zu
speichernde Information deckt bestimmte Fläche auf der Erde ab
Auflösung (m² pro Pixel) bestimmt Informationsgehalt und Datenqualität
y
x
Rasterzelle
1. Geographische Daten
Rasterdaten Zugriff auf Rasterzellen:
über geographische Koordinaten Spalten-Zeilen-Adressen der Matrixstruktur
Verwendung: für kontinuierlich im Raum verteilte Daten, z.B:
Bevölkerungsdichte, Temperaturverläufe, … Bilddaten wie Satelliten- oder Luftaufnahmen
1. Geographische Daten
Vektordaten dienen der Speicherung von Punkt- und Linieninformationen
sowie homogenen Flächen Elemente/Datentypen:
y
x
Polygone
Linienzüge
Punkte
1. Geographische Daten
Vektordaten dienen der Speicherung von Punkt- und Linieninformationen
sowie homogenen Flächen Elemente/Datentypen:
Punkte besitzen Koordinaten Standortdarstellung (z.B. Städte)
Linienzüge bestehen aus verbundenen Punkten Darstellung von Linieninformationen (z.B. Straßen)
Polygone sind geschlossene Linienzüge Abbildung homogener Flächen
allen Objekten können mehrere Attribute zur Speicherung von Informationen zugeordnet werden
1. Geographische Daten
Vektordaten Vorteil:
maßstabsunabhängige Darstellung von diskreten räumlichen Daten
Nachteil: für veränderliche Flächendaten ungeeignet, da nur
homogene Flächen darstellbar
Themenüberblick
1. Geographische Daten
2.2. GrundlagenGrundlagen3. Datenbanksysteme und
Darstellungswerkzeuge4. Funktionale Anforderungen an eine
Rasterdatenunterstützung5. Entwurf
2. Grundlagen Mosaik
Zerlegung eines Bildes in mehrere gleichgroße Teile, die separat gespeichert sind
Pyramiden Speichern der Rasterdaten in verschiedenen
Auflösungen zur Leistungsteigerung
Georeferenzieren Lokalisieren der Rasterdaten auf der Erdoberfläche
Themenüberblick
1. Geographische Daten2. Grundlagen
3.3. Datenbanksysteme und Datenbanksysteme und DarstellungswerkzeugeDarstellungswerkzeuge
4. Funktionale Anforderungen an eine Rasterdatenunterstützung
5. Entwurf
3. DBMS und Darstellungswerkzeuge
Datenbanksysteme (DB2) DB2
Spatial Extender als geographische Erweiterung unterstützt nur Vektordaten verwendet Geometrietypen die vom OpenGIS
Consortium spezifiziert wurden Punkte, Linienzüge, Polygone Verbundtypen für gleichartige Objekte (z.B.
ST_MultiPoint) Multipoint-Typ ermöglicht Umweg zur Speicherung
von Rasterdaten Pixel als Punkte innerhalb eines Multipoint-Objektes unter bestimmten Einschränkungen (DB2 erlaubt
maximal 300.000 Punkte innerhalb eines MultiPoint-Objektes)
3. DBMS und Darstellungswerkzeuge
Datenbanksysteme (Oracle) Oracle
Oracle Spatial zu Speicherung und Verarbeitung von geographischen Daten
unterstützt seit Version 10g Vektor- und Rasterdaten objektrelationales Modell wird verwendet
mittels des SDO_Geometry – Typs werden die vom OGC und in der SQL/MM-Norm spezifizierten Geometrietypen implementiert
Oracle Spatial wurde um GeoRaster-Paket erweitert um Rasterdaten verwalten zu können
3. DBMS und Darstellungswerkzeuge
Datenbanksysteme (Oracle) GeoRaster – Architektur
auf einem hohen Abstraktionsniveau stellt sich die GeoRaster-Architektur folgendermaßen dar
SQL APIViewing Tools Java/C/C++
Oracle 10gSpatial
Georaster
verschiedeneDateiformate
verschiedeneDateiformate
InA
da
pto
r
Ou
tA
da
pto
r
3. DBMS und Darstellungswerkzeuge
Datenbanksysteme (Oracle) GeoRaster – Datenmodell
generisches Datenmodell, das komponentenbasiert, multidimensional und in logische Schichten eingeteilt ist
den Kern der Daten bildet eine multidimensionale Matrix
Dimensionen werden durch Schichten realisiertRasterdatentabelle
Schicht 0
Schicht n
Schicht 1
3. DBMS und Darstellungswerkzeuge
Datenbanksysteme (Oracle) GeoRaster – Datenmodell
Daten lassen sich in eine Menge von Zelldaten und eine Menge von Metadaten unterscheiden
Metadaten werden in einer XML-Darstellung angegeben es existieren Metadaten für die GeoRaster-Objekte, die
einzelnen Schichten,…
BEM: fliegt wahrscheinlich wieder raus
3. DBMS und Darstellungswerkzeuge
Datenbanksysteme (Oracle) GeoRaster – Datenbank
GeoRasterDatenbank
GeoRaster Tabelle*
Metadaten in seperaten Tabellen
RasterdatenTabelle*
(Blobs)
* = GeoRaster Systemdaten
Indexe
Indexe
= GeoRaster Objekt
3. DBMS und Darstellungswerkzeuge
Datenbanksysteme (Oracle) GeoRaster – Objekttypen:
geographische Daten werden mittels der Objekttypen SDO_GeoRaster und SDO_Raster verwaltet
SDO_GeoRaster(rasterType Number,spatialExtend SDO_Geometry,rasterDataTable Varchar(32),rasterID Number,metadata XMLType)
3. DBMS und Darstellungswerkzeuge
Datenbanksysteme (Oracle) GeoRaster – Objekttypen:
Metadaten: z.B. objectDescriptionType:
liefert Informationen zu SDO_GeoRaster-Ojekten, wie z.B. Versionsinformationen, Defaultwerte für Farbkanäle, oder ob überhaupt Daten enthalten sind
zellenspezifische Metadaten:Art der Zelle (z.B. Quadrat), Zelltiefe, Dimensionsinformationen, …
weitere Metadaten:Informationen zu Blockbildung, Komprimierung, Pyramideneigenschaften, räumlichen Bezugssystem, …
3. DBMS und Darstellungswerkzeuge
Datenbanksysteme (Oracle) GeoRaster – Objekttypen:
SDO_Raster(rasterID Number,pyramideLevel Number,bandBlockNumber Number,rowBlockNumber Number,columnBlockNumber Number,blockMBR SDO_Geometry,rasterBlock BLOB)
Rasterzellen werden aus Platzgründen zu Blöcken zusammengefasst und dann gespeichert
3. DBMS und Darstellungswerkzeuge
Datenbanksysteme (Oracle) Zugriff auf die Rasterzellen:
verschiedene nutzerdefinierte Spalten SDO_GeoRaster Objekt
GeoRaster Type metadatarasterIDrasterdataTableNamespatialExtent
(SDO_Geometry)
RasterID, pyramide level,…
MBR für diesen Block(SDO_Geometry)
Daten des Blockes(BLOB)
Städte Tabelle(ein Tupel pro Stadt, z.B. Jena)
SDO_GeoRaster Objekt
Rasterdatentabelle(SDO_Raster Objekt, ein Tupel für jeden Block)
3. DBMS und Darstellungswerkzeuge
Datenbanksysteme (OGC) OpenGIS Consortium (OGC)
Unternehmensverbund zum Standardisieren von geographischen Objekten und Schnittstellenbeschreibungen für verschiedene verarbeitende Funktionen
Ziel: Zusammenarbeit von herstellerspezifischen Anwendungen zu ermöglichen bzw.
zu verbessern OGC Reference Model spezifiziert auch Datentyp für
Rasterdaten Coverage GML (Geographic Markup Language)
Beschreibungssprache für geographische Daten XML basiert enthält auch Beschreibung für Coverages
3. DBMS und Darstellungswerkzeuge
Datenbanksysteme (OpenSource)
PostgreSQL die Verarbeitung von Vektordaten ist möglich Rasterdaten werden nicht unterstützt
MySQL ist für die Verarbeitung von Vektordaten ausgelegt orientiert sich am OGC Reference Model die Speicherung von Rasterdaten ist nicht möglich
(nur der Umweg über den MultiPoint-Typ)
3. DBMS und Darstellungswerkzeuge
Darstellungswerkzeuge (GRASS)
GRASS (Geographical Resource Analysis Support System)
ist vom U.S. Militär entwickelt und Ende der 80er Jahre frei gegeben wurden
eines der umfangreichsten OpenSource-Produkte zur Erstellung von GIS-Anwendungen auf dem Markt
ist für die Bearbeitung von Vektor- und Rasterdaten ausgelegt
3. DBMS und Darstellungswerkzeuge
Darstellungswerkzeuge (GRASS)
GRASS – Datenbank
GRASS verwendet Dateisystem zur Ablage der Daten Rasterdaten können aus den meisten Datenformaten
importiert und bearbeitet werden
Anbindung relationaler DBMS ab Version 5.0 möglich (select, create, insert, delete – Anweisungen durch verschiedene Module implementiert)
Bearbeitung der Daten findet aber nur auf Anwendungsebene statt
3. DBMS und Darstellungswerkzeuge
Darstellungswerkzeuge (MapInfo) MapInfo ist ein kommerzielles Unternehmen bietet verschiedene Produkte zur Erstellung von GIS-
Anwendungen anBrowser
Web Server
Application Server
MapXtreme
Application(VB, C++)
MapX
MapInfo Pro
MapBasic ProgrammingSQL Query
MapMarkerGeocoding Server
MapInfo DataProducts
Data LoadUtilities
MapMarkerSQL
SpatialWareInformix, DB2SQL Server
ODBC
ODBC
ODBC
SQL
3. DBMS und Darstellungswerkzeuge
Darstellungswerkzeuge (MapInfo)
MapInfo Professional konzentriert sich auf Vektordatenverarbeitung basiert auf Schichtenmodell
jede Schicht besteht aus gleichartigen Objekten Karten erstellen durch Übereinanderprojezieren der
einzelnen Schichten Rasterdaten
nur als Hintergrund oder Zusatzinformation keine Auswertung von Inhalten der Rasterdaten
möglich Anbinden durch Registrierungsprozess MapInfo kann Rasterdaten aus Vektordaten erzeugen
3. DBMS und Darstellungswerkzeuge
Darstellungswerkzeuge (MapInfo) MapInfo – Datenbank:
Anbinden relationaler DBMS möglich Live Access Linked Table Downloaded Table
müssen geographische Daten verwalten können Erweiterungen wie Oracle Spatial, Spatial Extender
oder SpatialWare müssen vorhanden sein Vorgehensweise
Tab-Dateien für Datenspeicherung auf Anwendungsebene werden angelegt
MapCatalog für Registrierung der Datenbanktabellen auf DBMS-Ebene
3. DBMS und Darstellungswerkzeuge
Darstellungswerkzeuge (MapInfo)
MapInfo SpatialWare:
eigene DBMS-Erweiterung für Vektordaten spezielle Datentypen geographische Operationen zur Manipulation und
Auswertung Indexstrukturen für geographische Daten
für IBM DB2, Informix und Microsoft SQL Server keine separaten Datentypen für Rasterdaten
3. DBMS und Darstellungswerkzeuge
Darstellungswerkzeuge (ESRI) ArcGIS-Produktfamilie zur Speicherung, Verarbeitung und
Darstellung von geographischen Daten
Client-Anwendungen
Server-Dienste
Stand-AloneDesktop Anwendungen
(+ verschiedene Erweiterungen)
ArcInfo
ArcEditor ArcPad
ArcExplorer
ArcSDEDatenbankgateway
ArcIMSInternet Map Server
ArcReader Webbrowser
ArcView
DBArcGIS
Datenmodelle
3. DBMS und Darstellungswerkzeuge
Darstellungswerkzeuge (ESRI) ArcSDE als DBMS-Erweiterung für
geographische Daten für Oracle, Informix, DB2, SQL Server orientiert sich an SQL/MM-Norm und OGC-
Spezifikationen für Datentypen und Funktionen unterstützt auch vorhandene Datentypen wie
ST_Polygon vom Spatial Extender Datenbankgateway welches interne Repräsentation
der Daten (ArcSDE-Datentypen oder DBMS-Datentypen) von der äußeren Darstellung trennt
3. DBMS und Darstellungswerkzeuge
Darstellungswerkzeuge (ESRI) ArcSDE unterstützt Raster-
und Vektordaten Rasterdaten werden in einer
speziellen Struktur in der Datenbank (Geodatabase) abgelegt
Daten werden zerlegt, komprimiert, indiziert und mit Auflösungspyramiden versehen
Speicherung in mehreren Tabellen
Business-Tabelle enthält Spalte mit einem Rastertyp
4 zusätzliche Tabellen werden angelegt
city_photo
nameimage
SDE_ras_6
raster_idraster_flagsdescription
SDE_aux_6
rasterband_idtypeobject
SDE_blk_6
rasterband_idrrd_factorrow_nbrcol_nbrblock_data
SDE_bnd_6
rasterband_idsequence_nbrraster_idnameband_flagsband_widthband_heightband_typesblock_widthblock_heightblock_origin_xblock_origin_y
3. DBMS und Darstellungswerkzeuge
Terraserver von Microsoft Beispiel für existierendes GIS, welches auf Rasterdaten
in einem relationalen DBMS aufsetzt entstand im Zusammenhang mit dem Test und der
Demonstration der Skalierbarkeit von Microsoft SQL Servern
Internetanwendung Darstellung der Daten im Web-Browser bietet verschiedene Suchmethoden
Längen- und Breitengrade oder Gebiete angeben Sehenswürdigkeiten aus einer Liste Punkt auf einer Weltkarte auswählen
Zusatzinformationen lassen sich anzeigen Zoomen ist möglich …
3. DBMS und Darstellungswerkzeuge
Terraserver von Microsoft Daten werde bzgl. ihrer Quelle unterschieden theme
USGS DOQ, USGS DRG, SPIN-2, Encarta Shaded Relief Bilder werden in internettaugliche, 10 kbyte große Teile
zerlegt und gespeichert TerraCutter
Pyramide wird erzeugt und alle berechneten Auflösungen werden zusätzlich in der DB abgelegt
TerraScale keine nahtlose Darstellung der ganzen Welt, nur von
begrenzten Bereichen Szenen UTM-Zonen bzw. SPIN-2-Aufnahmen scene_id
3. DBMS und Darstellungswerkzeuge
Terraserver von Microsoft TerraCutter
zerlegt Ausgangsbilder in Teilbilder (entsprechend einer Zellgröße, z.B. 200 * 200 Pixel)
ordnet dabei jedem Teilbild x- und y-Koordinaten zu für SPIN-2-Bilder bezüglich des obersten linken Pixels beim Rest werden sie mittels der UTM-Koordinaten ermittelt
zusätzlich erhalten die Teilbilder scene_id, Auflösung, theme,…
für nahtlose Darstellung der Szenen müssen UTM-basierte (USGS) Datensätze noch zusammengefügt werden, da eine UTM-Zone meist aus mehreren Originalen besteht
wegen Überschneidungen der Originalbilder ist die Verschmelzung von Zellen notwendig
3. DBMS und Darstellungswerkzeuge
Terraserver von Microsoft TerraScale
erzeugt Bildpyramide auf der Basis der von TerraCutter gelieferten Daten
nur bestimmte Auflösungen werden unterstützt ( in Zweierpotenzen von 1/1024 bis 16384 Meter pro Pixel)
ausgehend von der höchsten Auflösung werden pro Stufe 4 Pixel vereinigt (z.B. durch Mittelwertbildung)
3. DBMS und Darstellungswerkzeuge
Terraserver von Microsoft Datenbankschema (ohne Ortsverzeichnis und
Suchtabellen)
OrigMetaTag Metadaten
(je ThemaverschiedeneMetadaten)
SourceMetadataTable
• pro Thema wird eine separate Tabelle angelegt• ein Tupel je zerlegtem Bild
SceneID 28 weiter Felder
(Metadaten,BLOB für Teilbild im JPG-Format)
X Y Display-Status OrigMetaTag
ImageTable
• pro Thema und Auflösung eine separate Tabelle • ein Tupel je 10kb Teilbild
Themenüberblick
1. Geographische Daten2. Grundlagen3. Datenbanksysteme und
Darstellungswerkzeuge
4.4. Funktionale Anforderungen an eine Funktionale Anforderungen an eine RasterdatenunterstützungRasterdatenunterstützung
5. Entwurf
4. Implementierungsaspekte
Mosaik - Strategie Gründe
Beschränkungen der DBMS machen Zerlegung von Rasterdaten notwendig (maximale BLOB-Größe von 2 GB)
nahtlose Darstellung großer Flächen durch Zusammenfügen benachbarter Bilder mit Mosaiken einfach möglich
reduzierte Ergebnismenge und Datentransfer für bestimmte Bereichsanfragen
Originalbild
reduziertesAnfrageergebnis
Mosaikzerlegungmit Bereichsanfrage
4. Implementierungsaspekte
Mosaik - Strategie Anforderungen an die Rasterdaten
1. ohne Verzerrungen (orthorectified)2. müssen genaue geographische Koordinaten mitliefern
Verzerrungen Zentralperspektive der Kamera bewirkt Verzerrungen
an den Rändern von Luftaufnahmen Höhenänderungen des photographierten Geländes
bewirken Maßstabsänderungen Wölbung der Erde führt zu Verzerrungen bei
Satellitenphotos Verschiebungen bei gescannten Karten oder
Luftaufnahmen
4. Implementierungsaspekte
Mosaik - Strategie Anforderungen an die Rasterdaten
1. ohne Verzerrungen (orthorectified)2. müssen genaue geographische Koordinaten
mitliefern
Verzerrungen - Folgen beim Zusammenfügen benachbarter Bilder treten
Risse oder Verschiebungen auf
mittels Orthophotoerstellung beseitigen
4. Implementierungsaspekte
Mosaik - Strategie Geographische Koordinaten
zur Lokalisierung und Positionierung der Rasterdaten innerhalb eines Koordinatensystems und dessen Abbildung auf die Erdoberfläche
geographische Koordinaten (Längen- und Breitengrade) sind für die Darstellung im zweidimensionalen Raum (Bildschirme, Karten) ungeeignet
Abstände und Längen sind nicht konstant, d.h. eingeschlossene Flächen sind verschieden groß im zweidimensionalen KS beides konstant
4. Implementierungsaspekte
Mosaik - Strategie zur Abbildung in zweidimensionalen Raum
werden Projektionen bzw. Projektionssysteme verwendet
Projektion = mathematische Transformation der dreidimensionalen
Darstellung in ein zweidimensionales System
Positionen innerhalb eines Projektionssystems werden mit (x,y)-Koordinaten in Bezug auf einen Koordinatenursprung angegeben (= Punkt auf der Erde)
Projektionen sind mit Verzerrungen verbundenRasterdaten liefern projizierte Koordinaten und verwendetes Projektionssystem als Metadaten mit
4. Implementierungsaspekte
Mosaik - Strategie Beispiel: USGS DOQ (Digital Orthophoto
Quadrangle) enthalten Koordinaten und Projektionsinformationen
UTM – Projektion mit Koordinaten in Metern Auflösung von 1 und 2 Meter pro Pixel verfügbar monochrom und mehrfarbig komprimiert und unkomprimiert
4. Implementierungsaspekte
Mosaik - Strategie Mosaik erstellen
Zerlegung erfolgt bzgl. einer konstanten Zellgröße (alle Zellen des Mosaiks sind quadratisch und gleich groß)
Wahl eines Startpixels (oben links) und ermitteln seiner Koordinaten
Ausschneiden des Teilbildes entsprechend der Zellgröße Teilbild bekommt Zeilen- und Spaltenadresse,
Koordinaten, … zugeordnet komprimieren und speichern der Zelle zeilen- oder spaltenweise die Zerlegung fortsetzen
4. Implementierungsaspekte
Mosaik - Strategie Problem von nur zum Teil gefüllten Zellen
Zellen werden in trotzdem gewählter Zellgröße gespeichertbeim Hinzufügen von weiteren Originalen werden die leeren Stellen aufgefüllt
Zellgröße
komplettgefüllte Zelle
zum Teilgefüllte Zelle
Zerlegung in quadratische Mosaikzellen
4. Implementierungsaspekte
Mosaik - Strategie Vereinigen von Bildern
Mosaike erleichtern das Verschmelzen mehrer Originalaufnahmen zur nahtlosen Darstellung größerer Gebiete
mehrere Bilder werden zerlegt und in einem Mosaik zusammengefasst
Probleme: überschneidende OriginaleWahl der Startpixel für zusätzliche Bilder
bestehendes Mosaik
einzufügende Originale
Zellen werdenverschmolzen
zusammengesetztes Mosaik
4. Implementierungsaspekte
Mosaik - Strategie Zellen verschmelzen
Bestimmen der Leere der neuen und alten Zellen und entscheiden ob die alte Zelle ersetzt, die neue verworfen oder beide verschmolzen werden.
Verschmelzung: leeren Stellen werden aufgefüllt Pixel für die zwei Werte existieren z.B. durch
Mittelwertbildung vereinigen (oder Ersetzen der alten Pixelwerte durch die neuen)
Startpixel bestimmen(x,y) = (xStartpixel + (Zellgröße * g1), yStartpixel + (Zellgröße *
g2))
4. Implementierungsaspekte
Mosaik - Strategie mehrdimensionale Mosaike
Zellen sind nicht mehr eindeutig über Koordinaten identifizierbar Schichtnummer/ Schicht_ID einführen
Satellitenphoto(Basismosaik)
Infrarotaufnahme
Höhenkarte
Schicht 0
Schicht 1
Schicht 2
VegetationSchicht n
4. Implementierungsaspekte
Mosaik - Strategie Organisation des Mosaiks
Matrixstuktur erlaubt Vergabe von Zeile- und Spaltenadressen
projizierte Koordinaten nutzen
Eckpunkte mittels Vektordatentyp speichern
Fläche als Polygon speichern
begrenzende x- und y-Werte speichern
Mittelpunkt als Vektordatentyp speichern
Spalte n
Zeile m
x
y
Zelle durch Zeilen- undSpaltenadresse lokalisieren
Lokalisierung durch geographischeKoordinaten (hier: des Mittelpunktes)
4. Implementierungsaspekte
Mosaik - Strategie Speicherung der Extremwerte xmax, xmin, , ymax
und ymin zur Lokalisierung der Zellen als Schlüssel verwendbar Vektordatenfunktionen können aber nicht genutzt
werden
Speicherung der Koordinaten mittels Vektordatendypen
Vektordatenfunktionen nutzbar künstlicher Schlüssel notwendig (ZellID)
4. Implementierungsaspekte
Mosaik - Strategie Beispielanfrage:
Zellen für einen gesuchten Bereich zurückgeben
Mittelpunkt-Variante erzwingt zusätzliche Verarbeitungsschritte
Mittelpunkt nichtim Anfragefenster
xi xi+1
yi
yi+1
je zwei begrenzendeKoordinaten imAnfrageintervall
je ein Eckpunktim Anfragefenster
4. Implementierungsaspekte
Mosaik - Strategie überlappende vs. überschneidungsfreie Zellen
Performancevorteile durch reduzierte Ergebnismengen
Redundanz und zusätzliche Schritte bei Anfrageauswertung
gemeinsamer Bereich benachbarter Zellen
Zelle mit Überlappung
Mosaikzellen ohne Überschneidung
Mosaikzellen mit Überschneidung
4. Implementierungsaspekte
Mosaik - Strategie konstante vs. variable Überschneidung
fester Wert für Überschneidung reguläre Struktur variable Überschneidungen Matrixstruktur geht
verloren irregulär
„reguläres“ Mosaikohne Überschneidungen
mögliche Struktur desMosaiks bei dynamischerÜberschneidungen
4. Implementierungsaspekte
Mosaik - Strategie nötige Informationen zur Verwaltung eines
MosaiksMosaik/Schichten
ID (für Identifikation eines mehrdimensionalen Mosaiks) Schicht_ID Zellgröße Koordinaten und Projektionssystem Auflösung Farbanzahl (Farbmodell) und Farbtiefe
Zellen Koordinaten eventuell ZellID
4. Implementierungsaspekte
Auflösungspyramiden Speicherung der Rasterdaten in verschiedenen
Auflösungen Leistungssteigerung durch reduzierte
Ergebnismengen bedeutet erhebliche Redundanz und erhöhten
Speicherplatzbedarf
Basismosaik mit derhöchsten AuflösungPyramidenlevel 0
Mosaik mit nächst-kleineren AuflösungPyramidenlevel 1
niedrigste AuflösungPyramidenlevel n
4. Implementierungsaspekte
Auflösungspyramiden Erzeugen der Pyramide
auf der Basis der Originaldaten werden die niedrigeren Auflösungen Stufe für Stufe berechnet
mögliche Verfahren: nächster Nachbar Mittelwertberechnung von n Pixeln der höheren
Auflösungsstufe (z.B. 4 1) nutzerdefinierte Pyramiden möglich
Pyramide mit regelmäßig verteilten Leveln
nutzerdefinierte Pyramide mitunregelmäßig verteilten Stufen
4. Implementierungsaspekte
Auflösungspyramiden Realisierung
Konzept der Schichten eines mehrdimensionalen Mosaiks für Stufen der Pyramide nutzbar Unterscheidung zw. Dimension und Auflösung nicht mehr möglich Level_ID einführen
d.h. Zellen in einem mehrdimensionalen Mosaik mit Pyramiden sind durch ID, Schicht_ID, Level_ID und ZellID (bzw. Koordinaten) eindeutig identifizierbar
Themenüberblick
1. Geographische Daten2. Grundlagen3. Datenbanksysteme und
Darstellungswerkzeuge4. Funktionale Anforderungen an eine
Rasterdatenunterstützung
5.5. EntwurfEntwurf
5. Entwurf
Vorbetrachtung hierarchische Struktur
Varianten: mehrdimensionales Mosaik mit Pyramide für jede Schicht oder mehrdimensionale Pyramide
DBMS unterstützt Vektordaten und Projektionen
Schicht 0
Schicht n
Schicht 0
Schicht n
Schicht 0
Schicht n
5. Entwurf
E/R-Modell mehrdimensionales
Mosaik mit Pyramiden Raster
Projektionsinformationen sind durch Entitätstyp Projektionssystem in DB gegeben
4
1 – verwendet2 – hat3 – besitzt4 – besteht aus
(1,*)
(1,*)
(1,*)
(1,1)
(1,1)
(1,1)
Raster
Schicht
Level
Zelle
1
Projektionssystem
(1,1)
(0,*)
3
2
(1,*)
5. Entwurf
E/R-Modell (Raster) Koordinaten geben
die überdeckte Fläche des Rasters an
ProjSysID gibt verwendetes Projektionssystem an SRS_ID
Raster_ID
Name
Zellgröße
Koordinaten
Beschreibung
Raster
1
Projektionssystem
(1,1)
(0,*)
ProjSysID 1 – verwendet
5. Entwurf
E/R-Modell (Schicht/Level)
Beschreibung
Schicht_ID
Farbtiefe
Schicht
Farbmodell
Level
Level_IDAuflösung
5. Entwurf
E/R-Modell (Zelle) verschiedene Möglichkeiten für Speicherung
der KoordinatenFläche
(Vektordatentyp)
Zell_ID
Bild Zelle
xmin
xmax
ymin
ymax
Bild Zelle
5. Entwurf
Relationale Umsetzung liefert vier Tabellen
kann sich ja jeder vorstellen
5. Entwurf
Relationale Umsetzung Problem: Zugriff auf Daten verursacht Join über 4 Tabellen
umständlich, vorallem bei eindimensionalen Mosaiken Tabellenanzahl verringern: Schichten- und Level-Tabelle
vereinigen
create Table Raster ( Raster_ID IDType, Name Varchar(100), Beschreibung Varchar(1000), ProjSysID Integer, Zellgroesse Integer, Flaeche ST_Polygon, foreign key (ProjSysID) references
Projektionssystem(ProjSysID), primary key (Raster_ID))
5. Entwurf
Relationale Umsetzung
create Table RasterDimPyr ( Raster_ID IDType, Schicht_ID IDType, Level_ID IDType, Aufloesung Integer, Farbmodell Integer, Farbtiefe Integer, Beschreibung Varchar(1000), foreign key (Raster_ID) references Raster(Raster_ID), primary key (Raster_ID, Schicht_ID, Level_ID))
5. Entwurf
Relationale Umsetzung
create Table Rasterdaten ( Raster_ID IDType, Schicht_ID IDType, Level_ID IDType, Zell_ID IDType, Flaeche ST_Polygon, Bild BLOB, foreign key (Raster_ID, Schicht_ID, Level_ID) references RasterDimPyr(Raster_ID, Schicht_ID, Level_ID), primary key (Raster_ID, Schicht_ID, Level_ID, Zell_ID))
5. Entwurf
Weitere Optimierung mehrere Rasterdatentabellen
???
Zusammenfassung einfaches Modell
leicht erweiterbar überlappende und überschneidungsfreie Mosaike
möglich alle vorgestellten Koordinatenvarianten leicht
implementierbar
Umsetzen des Entwurfes und Testen der verschiedenen Varianten