Rasterdatenunterstützung in relationalen Datenbanksystemen
Werbung
Rasterdatenunterstützung in relationalen Datenbanksystemen Oberseminarvortrag zur gleichnamigen Studienarbeit 16. November 2004 Marco Pagel Themenüberblick 1. 2. 3. 4. 5. Geographische Daten Grundlagen Datenbanksysteme und Darstellungswerkzeuge Funktionale Anforderungen an eine Rasterdatenunterstützung Entwurf Themenüberblick 1. 2. 3. 4. 5. Geographische Daten Grundlagen Datenbanksysteme und Darstellungswerkzeuge Funktionale Anforderungen an eine Rasterdatenunterstützung 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: y Rasterzelle x 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 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 Polygone Punkte x Linienzüge 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. 2. 3. 4. 5. Geographische Daten Grundlagen Datenbanksysteme und Darstellungswerkzeuge Funktionale Anforderungen an eine Rasterdatenunterstützung Entwurf 2. Grundlagen Mosaik Pyramiden Zerlegung eines Bildes in mehrere gleichgroße Teile, die separat gespeichert sind Speichern der Rasterdaten in verschiedenen Auflösungen zur Leistungsteigerung Georeferenzieren Lokalisieren der Rasterdaten auf der Erdoberfläche Themenüberblick 1. 2. 3. 4. 5. Geographische Daten Grundlagen Datenbanksysteme und Darstellungswerkzeuge Funktionale Anforderungen an eine Rasterdatenunterstützung 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 Viewing Tools Oracle 10g Spatial Georaster Java/C/C++ Out Adaptor In Adaptor verschiedene Dateiformate SQL API verschiedene Dateiformate 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 realisiert Rasterdatentabelle Schicht n Schicht 1 Schicht 0 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 Indexe Indexe GeoRaster Tabelle* Rasterdaten Tabelle* (Blobs) GeoRaster Datenbank Metadaten in seperaten Tabellen * = GeoRaster Systemdaten = 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, rasterDataTableVarchar(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 pyramideLevel bandBlockNumber rowBlockNumber columnBlockNumber blockMBR rasterBlock Number, Number, Number, Number, Number, SDO_Geometry, 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 Städte Tabelle (ein Tupel pro Stadt, z.B. Jena) GeoRaster Type spatialExtent (SDO_Geometry) rasterdataTableName rasterID metadata SDO_GeoRaster Objekt RasterID, pyramide level,… MBR für diesen Block (SDO_Geometry) Rasterdatentabelle (SDO_Raster Objekt, ein Tupel für jeden Block) Daten des Blockes (BLOB) 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 an Browser SQL Query Application (VB, C++) MapInfo Pro MapX MapBasic Programming Web Server ODBC SQL Application Server MapMarker MapXtreme ODBC Geocoding Server ODBC MapInfo Data Products Data Load Utilities Informix, DB2 SQL Server SpatialWare MapMarker 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 müssen geographische Daten verwalten können Live Access Linked Table Downloaded Table 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 DBMSEbene 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 ArcInfo ArcEditor ArcPad ArcExplorer ArcView Stand-Alone Desktop Anwendungen (+ verschiedene Erweiterungen) ArcReader Webbrowser Client-Anwendungen ArcIMS ArcSDE Internet Map Server Datenbankgateway Server-Dienste ArcGIS Datenmodelle DB 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 name image SDE_ras_6 SDE_aux_6 raster_id raster_flags description rasterband_id type object SDE_bnd_6 SDE_blk_6 rasterband_id sequence_nbr raster_id name band_flags band_width band_height band_types block_width block_height block_origin_x block_origin_y rasterband_id rrd_factor row_nbr col_nbr block_data 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 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 USGS DOQ, USGS DRG, SPIN-2, Encarta Shaded Relief 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) SourceMetadataTable OrigMetaTag Metadaten (je Thema verschiedene Metadaten) • pro Thema wird eine separate Tabelle angelegt • ein Tupel je zerlegtem Bild ImageTable SceneID X Y Display-Status OrigMetaTag 28 weiter Felder (Metadaten, BLOB für Teilbild im JPG-Format) • pro Thema und Auflösung eine separate Tabelle • ein Tupel je 10kb Teilbild Themenüberblick 1. 2. 3. 4. 5. Geographische Daten Grundlagen Datenbanksysteme und Darstellungswerkzeuge Funktionale Anforderungen an eine Rasterdatenunterstützung 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 Mosaikzerlegung mit Bereichsanfrage reduziertes Anfrageergebnis 4. Implementierungsaspekte Mosaik - Strategie Anforderungen an die Rasterdaten 1. 2. ohne Verzerrungen (orthorectified) 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. 2. ohne Verzerrungen (orthorectified) 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 verbunden Rasterdaten 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 Zellgröße komplett gefüllte Zelle Zerlegung in quadratische Mosaikzellen zum Teil gefüllte Zelle Zellen werden in trotzdem gewählter Zellgröße gespeichert beim Hinzufügen von weiteren Originalen werden die leeren Stellen aufgefüllt 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 Originale Wahl der Startpixel für zusätzliche Bilder einzufügende Originale Zellen werden verschmolzen bestehendes Mosaik 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 Schicht n Vegetation Schicht 2 Höhenkarte Schicht 1 Infrarotaufnahme Schicht 0 Satellitenphoto (Basismosaik) Zellen sind nicht mehr eindeutig über Koordinaten identifizierbar Schichtnummer/ Schicht_ID einführen 4. Implementierungsaspekte Mosaik - Strategie Organisation des Mosaiks Spalte n 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 y Zeile m x Zelle durch Zeilen- und Spaltenadresse lokalisieren Lokalisierung durch geographische Koordinaten (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: je zwei begrenzende Koordinaten im Anfrageintervall Zellen für einen gesuchten Bereich zurückgeben Mittelpunkt-Variante erzwingt zusätzliche Verarbeitungsschritte xi xi+1 yi+1 yi je ein Eckpunkt im Anfragefenster Mittelpunkt nicht im Anfragefenster 4. Implementierungsaspekte Mosaik - Strategie überlappende vs. überschneidungsfreie Zellen Performancevorteile durch reduzierte Ergebnismengen Redundanz und zusätzliche Schritte bei Anfrageauswertung Zelle mit Überlappung gemeinsamer Bereich benachbarter Zellen 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“ Mosaik ohne Überschneidungen mögliche Struktur des Mosaiks bei dynamischer Überschneidungen 4. Implementierungsaspekte Mosaik - Strategie nötige Informationen zur Verwaltung eines Mosaiks Mosaik/Schichten Zellen ID (für Identifikation eines mehrdimensionalen Mosaiks) Schicht_ID Zellgröße Koordinaten und Projektionssystem Auflösung Farbanzahl (Farbmodell) und Farbtiefe 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 niedrigste Auflösung Pyramidenlevel n Mosaik mit nächstkleineren Auflösung Pyramidenlevel 1 Basismosaik mit der höchsten Auflösung Pyramidenlevel 0 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 mit unregelmäß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. 2. 3. 4. 5. Geographische Daten Grundlagen Datenbanksysteme und Darstellungswerkzeuge Funktionale Anforderungen an eine Rasterdatenunterstützung Entwurf 5. Entwurf Vorbetrachtung hierarchische Struktur Varianten: mehrdimensionales Mosaik mit Pyramide für jede Schicht oder mehrdimensionale Pyramide Schicht n Schicht 0 Schicht n Schicht n Schicht 0 Schicht 0 DBMS unterstützt Vektordaten und Projektionen 5. Entwurf E/R-Modell mehrdimensionales Mosaik mit Pyramiden Raster Raster Projektionsinformationen sind durch Entitätstyp Projektionssystem in DB gegeben 1 (1,*) 2 (1,1) (1,1) Schicht (0,*) Projektionssystem (1,*) 3 (1,1) Level (1,*) (1,*) 4 (1,1) Zelle 1 – verwendet 2 – hat 3 – besitzt 4 – besteht aus 5. Entwurf E/R-Modell (Raster) Koordinaten geben die überdeckte Fläche des Rasters an Beschreibung Name ProjSysID gibt verwendetes Projektionssystem an SRS_ID Koordinaten Raster Raster_ID (1,1) Zellgröße 1 (0,*) Projektionssystem ProjSysID 1 – verwendet 5. Entwurf E/R-Modell (Schicht/Level) Schicht_ID Farbmodell Schicht Beschreibung Farbtiefe Level Auflösung Level_ID 5. Entwurf E/R-Modell (Zelle) verschiedene Möglichkeiten für Speicherung der Koordinaten Fläche (Vektordatentyp) Bild Zelle Zell_ID xmin xmax Bild Zelle ymin ymax 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
