Rasterdatenunterstützung in relationalen Datenbanksystemen
Oberseminarvortrag zur gleichnamigen Studienarbeit
16. November 2004Marco Pagel
Themenüberblick1. Geographische Daten2. Grundlagen3. Datenbanksysteme und
Darstellungswerkzeuge4. Funktionale Anforderungen an eine
Rasterdatenunterstützung5. Entwurf
Themenüberblick1.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 DatenRasterdaten 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 DatenRasterdaten 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 DatenVektordaten dienen der Speicherung von Punkt- und Linieninformationen
sowie homogenen Flächen Elemente/Datentypen:
y
x
Polygone
Linienzüge
Punkte
1. Geographische DatenVektordaten 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 DatenVektordaten 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überblick1. Geographische Daten2.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überblick1. Geographische Daten2. Grundlagen3.3. Datenbanksysteme und Datenbanksysteme und
DarstellungswerkzeugeDarstellungswerkzeuge4. Funktionale Anforderungen an eine
Rasterdatenunterstützung5. Entwurf
3. DBMS und DarstellungswerkzeugeDatenbanksysteme (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 DarstellungswerkzeugeDatenbanksysteme (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 DarstellungswerkzeugeDatenbanksysteme (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
daptor
Out
Adaptor
3. DBMS und DarstellungswerkzeugeDatenbanksysteme (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 DarstellungswerkzeugeDatenbanksysteme (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 DarstellungswerkzeugeDatenbanksysteme (Oracle) GeoRaster – Datenbank
GeoRasterDatenbank
GeoRaster Tabelle*
Metadaten in seperaten Tabellen
RasterdatenTabelle*
(Blobs)
* = GeoRaster Systemdaten
Indexe
Indexe
= GeoRaster Objekt
3. DBMS und DarstellungswerkzeugeDatenbanksysteme (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 DarstellungswerkzeugeDatenbanksysteme (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 DarstellungswerkzeugeDatenbanksysteme (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 DarstellungswerkzeugeDatenbanksysteme (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 DarstellungswerkzeugeDatenbanksysteme (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 DarstellungswerkzeugeDatenbanksysteme (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 DarstellungswerkzeugeDarstellungswerkzeuge (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 DarstellungswerkzeugeDarstellungswerkzeuge (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 DarstellungswerkzeugeDarstellungswerkzeuge (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 DarstellungswerkzeugeDarstellungswerkzeuge (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 DarstellungswerkzeugeDarstellungswerkzeuge (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 DarstellungswerkzeugeDarstellungswerkzeuge (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 DarstellungswerkzeugeDarstellungswerkzeuge (ESRI) ArcGIS-Produktfamilie zur Speicherung, Verarbeitung und
Darstellung von geographischen Daten
Client-Anwendungen
Server-Dienste
Stand-AloneDesktop Anwendungen
(+ verschiedene Erweiterungen)
ArcInfoArcEditor ArcPad
ArcExplorer
ArcSDEDatenbankgateway
ArcIMSInternet Map Server
ArcReader WebbrowserArcView
DBArcGIS
Datenmodelle
3. DBMS und DarstellungswerkzeugeDarstellungswerkzeuge (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 DarstellungswerkzeugeDarstellungswerkzeuge (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 DarstellungswerkzeugeTerraserver 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 DarstellungswerkzeugeTerraserver 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 DarstellungswerkzeugeTerraserver 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 DarstellungswerkzeugeTerraserver 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 DarstellungswerkzeugeTerraserver 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überblick1. Geographische Daten2. Grundlagen3. Datenbanksysteme und
Darstellungswerkzeuge4.4. Funktionale Anforderungen an eine Funktionale Anforderungen an eine
RasterdatenunterstützungRasterdatenunterstützung5. Entwurf
4. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteMosaik - 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. ImplementierungsaspekteAuflö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. ImplementierungsaspekteAuflö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. ImplementierungsaspekteAuflö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überblick1. Geographische Daten2. Grundlagen3. Datenbanksysteme und
Darstellungswerkzeuge4. Funktionale Anforderungen an eine
Rasterdatenunterstützung5.5. EntwurfEntwurf
5. EntwurfVorbetrachtung hierarchische Struktur
Varianten: mehrdimensionales Mosaik mit Pyramide für jede Schicht oder mehrdimensionale Pyramide
DBMS unterstützt Vektordaten und ProjektionenSchicht 0
Schicht n
Schicht 0
Schicht n
Schicht 0
Schicht n
5. EntwurfE/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. EntwurfE/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. EntwurfE/R-Modell (Schicht/Level)
Beschreibung
Schicht_ID
Farbtiefe
Schicht
Farbmodell
Level
Level_IDAuflösung
5. EntwurfE/R-Modell (Zelle) verschiedene Möglichkeiten für Speicherung
der KoordinatenFläche
(Vektordatentyp)
Zell_ID
Bild Zelle
xmin
xmax
ymin
ymax
Bild Zelle
5. EntwurfRelationale Umsetzung liefert vier Tabellen
kann sich ja jeder vorstellen
5. EntwurfRelationale 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. EntwurfRelationale 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. EntwurfRelationale 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. EntwurfWeitere 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