Rasterdatenunterstützung in relationalen Datenbanksystemen

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



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


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


Vektordaten dienen der Speicherung von Punkt- und Linieninformationen

sowie homogenen Flächen Elemente/Datentypen:

y

x

Polygone

Linienzüge

Punkte


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


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


2.2. GrundlagenGrundlagen3. Datenbanksysteme und



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)


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


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


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


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


Datenbanksysteme (Oracle) GeoRaster – Datenbank

GeoRasterDatenbank

GeoRaster Tabelle*

Metadaten in seperaten Tabellen

RasterdatenTabelle*

(Blobs)

* = GeoRaster Systemdaten

Indexe

Indexe

= GeoRaster Objekt


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)



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, …



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


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)


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


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)


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


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


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


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


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


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


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


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


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


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 …


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


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


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)


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


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


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


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


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


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


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


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


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


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


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))


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


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)


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)


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


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


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


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


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


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


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



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

Documents

Rasterdatenunterstützung in relationalen Datenbanksystemen