Rasterdatenunterstützung in relationalen Datenbanksystemen

Rasterdatenunterstützung in relationalen Datenbanksystemen
Oberseminarvortrag zur gleichnamigen Studienarbeit 16. November 2004 Marco Pagel

Themenüberblick 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
y x Rasterzelle 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

1. Geographische Daten Rasterdaten
Zugriff auf Rasterzellen: über geographische Koordinaten Spalten-Zeilen-Adressen der Matrixstruktur Verwendung: für kontinuierlich im Raum verteilte Daten, z.B: Bevölkerungsdichte, Temperaturverläufe, … Bilddaten wie Satelliten- oder Luftaufnahmen

1. Geographische Daten Vektordaten
dienen der Speicherung von Punkt- und Linieninformationen sowie homogenen Flächen Elemente/Datentypen: y x Polygone Linienzüge Punkte

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

Vorteil: maßstabsunabhängige Darstellung von diskreten räumlichen Daten Nachteil: für veränderliche Flächendaten ungeeignet, da nur homogene Flächen darstellbar

2. Grundlagen Mosaik Pyramiden Georeferenzieren
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

3. DBMS und Darstellungswerkzeuge Datenbanksysteme (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 Punkte innerhalb eines MultiPoint-Objektes)

3. DBMS und Darstellungswerkzeuge Datenbanksysteme (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

GeoRaster – Architektur auf einem hohen Abstraktionsniveau stellt sich die GeoRaster-Architektur folgendermaßen dar SQL API Viewing Tools Java/C/C++ Oracle 10g Spatial Georaster verschiedene Dateiformate Adaptor In Out

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

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

GeoRaster – Datenbank GeoRaster Datenbank GeoRaster Tabelle* Metadaten in seperaten Tabellen Rasterdaten Tabelle* (Blobs) * = GeoRaster Systemdaten Indexe = GeoRaster Objekt

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)

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

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

Zugriff auf die Rasterzellen: verschiedene nutzerdefinierte Spalten SDO_GeoRaster Objekt GeoRaster Type metadata rasterID rasterdataTableName spatialExtent (SDO_Geometry) RasterID, pyramide level,… MBR für diesen Block Daten des Blockes (BLOB) Städte Tabelle (ein Tupel pro Stadt, z.B. Jena) Rasterdatentabelle (SDO_Raster Objekt, ein Tupel für jeden Block)

3. DBMS und Darstellungswerkzeuge Datenbanksysteme (OGC)
OpenGIS Consortium (OGC) Unternehmensverbund zum Standardisieren von geographischen Objekten und Schnittstellenbeschreibungen für verschiedene verarbeitende Funktionen Ziel: Zusammenarbeit von herstellerspezifischen Anwendungen zu ermöglichen bzw. zu verbessern OGC Reference Model spezifiziert auch Datentyp für Rasterdaten  Coverage GML (Geographic Markup Language) Beschreibungssprache für geographische Daten XML basiert enthält auch Beschreibung für Coverages

3. DBMS und Darstellungswerkzeuge Datenbanksysteme (OpenSource)
PostgreSQL die Verarbeitung von Vektordaten ist möglich Rasterdaten werden nicht unterstützt MySQL ist für die Verarbeitung von Vektordaten ausgelegt orientiert sich am OGC Reference Model die Speicherung von Rasterdaten ist nicht möglich (nur der Umweg über den MultiPoint-Typ)

3. DBMS und Darstellungswerkzeuge Darstellungswerkzeuge (GRASS)
GRASS (Geographical Resource Analysis Support System) ist vom U.S. Militär entwickelt und Ende der 80er Jahre frei gegeben wurden eines der umfangreichsten OpenSource-Produkte zur Erstellung von GIS-Anwendungen auf dem Markt ist für die Bearbeitung von Vektor- und Rasterdaten ausgelegt

3. DBMS und Darstellungswerkzeuge Darstellungswerkzeuge (GRASS)
GRASS – Datenbank GRASS verwendet Dateisystem zur Ablage der Daten Rasterdaten können aus den meisten Datenformaten importiert und bearbeitet werden Anbindung relationaler DBMS ab Version 5.0 möglich (select, create, insert, delete – Anweisungen durch verschiedene Module implementiert) Bearbeitung der Daten findet aber nur auf Anwendungsebene statt

3. DBMS und Darstellungswerkzeuge Darstellungswerkzeuge (MapInfo)
MapInfo ist ein kommerzielles Unternehmen bietet verschiedene Produkte zur Erstellung von GIS-Anwendungen an Browser Web Server Application Server MapXtreme Application (VB, C++) MapX MapInfo Pro MapBasic Programming SQL Query MapMarker Geocoding Server MapInfo Data Products Data Load Utilities SQL SpatialWare Informix, DB2 SQL Server ODBC

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

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

MapInfo SpatialWare: eigene DBMS-Erweiterung für Vektordaten spezielle Datentypen geographische Operationen zur Manipulation und Auswertung Indexstrukturen für geographische Daten für IBM DB2, Informix und Microsoft SQL Server keine separaten Datentypen für Rasterdaten

3. DBMS und Darstellungswerkzeuge Darstellungswerkzeuge (ESRI)
ArcGIS-Produktfamilie zur Speicherung, Verarbeitung und Darstellung von geographischen Daten Client-Anwendungen Server-Dienste Stand-Alone Desktop Anwendungen (+ verschiedene Erweiterungen) ArcInfo ArcEditor ArcPad ArcExplorer ArcSDE Datenbankgateway ArcIMS Internet Map Server ArcReader Webbrowser ArcView DB ArcGIS Datenmodelle

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

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 raster_id raster_flags description SDE_aux_6 rasterband_id type object SDE_blk_6 rrd_factor row_nbr col_nbr block_data SDE_bnd_6 sequence_nbr band_flags band_width band_height band_types block_width block_height block_origin_x block_origin_y

3. DBMS und Darstellungswerkzeuge Terraserver von Microsoft
Beispiel für existierendes GIS, welches auf Rasterdaten in einem relationalen DBMS aufsetzt entstand im Zusammenhang mit dem Test und der Demonstration der Skalierbarkeit von Microsoft SQL Servern Internetanwendung Darstellung der Daten im Web-Browser bietet verschiedene Suchmethoden Längen- und Breitengrade oder Gebiete angeben Sehenswürdigkeiten aus einer Liste Punkt auf einer Weltkarte auswählen Zusatzinformationen lassen sich anzeigen Zoomen ist möglich …

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

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

TerraScale erzeugt Bildpyramide auf der Basis der von TerraCutter gelieferten Daten nur bestimmte Auflösungen werden unterstützt ( in Zweierpotenzen von 1/1024 bis Meter pro Pixel) ausgehend von der höchsten Auflösung werden pro Stufe 4 Pixel vereinigt (z.B. durch Mittelwertbildung)

Datenbankschema (ohne Ortsverzeichnis und Suchtabellen) OrigMetaTag Metadaten (je Thema verschiedene Metadaten) 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 ImageTable pro Thema und Auflösung eine separate Tabelle ein Tupel je 10kb Teilbild

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 reduziertes Anfrageergebnis Mosaikzerlegung mit Bereichsanfrage

Anforderungen an die Rasterdaten 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

Anforderungen an die Rasterdaten ohne Verzerrungen (orthorectified) müssen genaue geographische Koordinaten mitliefern Verzerrungen - Folgen beim Zusammenfügen benachbarter Bilder treten Risse oder Verschiebungen auf mittels Orthophotoerstellung beseitigen

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

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

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

Problem von nur zum Teil gefüllten Zellen Zellen werden in trotzdem gewählter Zellgröße gespeichert beim Hinzufügen von weiteren Originalen werden die leeren Stellen aufgefüllt Zellgröße komplett gefüllte Zelle zum Teil Zerlegung in quadratische Mosaikzellen

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 bestehendes Mosaik einzufügende Originale Zellen werden verschmolzen zusammengesetztes Mosaik

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

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 Vegetation Schicht n

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- und Spaltenadresse lokalisieren Lokalisierung durch geographische Koordinaten (hier: des Mittelpunktes)

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)

Beispielanfrage: Zellen für einen gesuchten Bereich zurückgeben  Mittelpunkt-Variante erzwingt zusätzliche Verarbeitungsschritte Mittelpunkt nicht im Anfragefenster xi xi+1 yi yi+1 je zwei begrenzende Koordinaten im Anfrageintervall je ein Eckpunkt

ü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

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

nötige Informationen zur Verwaltung eines Mosaiks Mosaik/Schichten ID (für Identifikation eines mehrdimensionalen Mosaiks) Schicht_ID Zellgröße Koordinaten und Projektionssystem Auflösung Farbanzahl (Farbmodell) und Farbtiefe Zellen Koordinaten eventuell ZellID

4. Implementierungsaspekte Auflösungspyramiden
Speicherung der Rasterdaten in verschiedenen Auflösungen Leistungssteigerung durch reduzierte Ergebnismengen bedeutet erhebliche Redundanz und erhöhten Speicherplatzbedarf Basismosaik mit der höchsten Auflösung Pyramidenlevel 0 Mosaik mit nächst- kleineren Auflösung Pyramidenlevel 1 niedrigste Auflösung Pyramidenlevel n

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

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

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

5. Entwurf E/R-Modell mehrdimensionales Mosaik mit Pyramiden  Raster
4 1 – verwendet 2 – hat 3 – besitzt 4 – besteht aus (1,*) (1,1) Raster Schicht Level Zelle 1 Projektionssystem (0,*) 3 2 mehrdimensionales Mosaik mit Pyramiden  Raster Projektionsinformationen sind durch Entitätstyp Projektionssystem in DB gegeben

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_ID Auflösung

5. Entwurf E/R-Modell (Zelle)
verschiedene Möglichkeiten für Speicherung der Koordinaten Fläche (Vektordatentyp) Zell_ID Bild Zelle xmin xmax ymin ymax Bild Zelle

5. Entwurf Relationale Umsetzung
liefert vier Tabellen kann sich ja jeder vorstellen

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

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

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

Rasterdatenunterstützung in relationalen Datenbanksystemen

Ähnliche Präsentationen

Präsentation zum Thema: "Rasterdatenunterstützung in relationalen Datenbanksystemen"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Rasterdatenunterstützung in relationalen Datenbanksystemen

Ähnliche Präsentationen

Präsentation zum Thema: "Rasterdatenunterstützung in relationalen Datenbanksystemen"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback