Rasterdatenunterstützung in relationalen Datenbanksystemen Oberseminarvortrag zur gleichnamigen...

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



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



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


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)


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

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


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



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

Rasterdatenunterstützung in relationalen Datenbanksystemen Oberseminarvortrag zur gleichnamigen...

Documents

Transcript of Rasterdatenunterstützung in relationalen Datenbanksystemen Oberseminarvortrag zur gleichnamigen...