149-2009-K-SUN-Koch Arbeiten mit Geodaten in ? Arbeiten mit Geodaten in Oracle und MySQL Gemeinsamkeiten

  • Published on
    17-Sep-2018

  • View
    212

  • Download
    0

Transcript

Arbeiten mit Geodaten in Oracle und MySQL Gemeinsamkeiten und Unterschiede M. Sc. Thomas Koch Searchmetrics GmbH Berlin Schlsselworte: Geodaten, Oracle Spatial, Oracle Locator, MySQL Einleitung Nachdem Oracle am 20. April 2009 ankndigte Sun zu kaufen, existieren nun drei Mglichkeiten Geodaten zu speichern: Oracle Locator, Oracle Enterprise with Spatial Option und durch die bernahme von Sun auch MySQL. Der Beitrag gibt eine Spatial Einfhrung mit Hauptaugenmerk auf die funktionellen Unterschiede zwischen beiden Datenbanksystemen - Oracle und MySQL. Dabei wird die Konformitt zur OpenGIS-Spezifikation und zu diversen ISO-Normen (19125, 13249-3, 9075), sowie die systemeigenen Erweiterungen betrachtet. Ein weiterer Punkt ist die Migration in beide Systeme. Abgerundet wird der Beitrag mit einem kurzen berblick ber Google Maps und Oracle Maps, die zur Visualisierung rumlicher Daten dienen. Entstehungsgeschichte der Geodaten in den Datenbanksystemen Um die Unterschiede zwischen beiden Datenbanksystemen (DBS) besser zu verstehen, ist die Entstehungsgeschichte seit der ersten Einfhrung von Geodaten in das jeweilige Datenbanksystem bis zum heutigen Stand von Bedeutung. Mit der Version 7.1.6 von Oracle konnten die ersten Punkte (Multidimensional) gespeichert werden. Den richtigen Einstieg von Spatial schaffte Oracle mit der Version 7.3.3 (1997). Von da an wurde von Version zu Version der Funktionsumfang von Oracle Spatial erweitert (siehe Abb. 1). Abb. 1: Entwicklung von Oracle Spatial (angelehnt an [Czar2007]) MySQL hingegen untersttzt rumliche Datentypen mit der Version 4.1 (2003). Seit dem gibt es auer einigen Bugfixes keine nennenswerte weitere Entwicklungen im Bereich rumliche Daten. Vorherrschende Standards zur Speicherung von Geodaten Fr den GIS-Markt sind zwei Organisationen (OGC und ISO) zu nennen, welche sich seit den 90er-Jahren um die Standardisierung von Geodaten bemhen: das Open Geospatial Consortium (OGC) ein Zusammenschluss von Forschungseinrichtungen, Universitten, Firmen und ffentlichen Stellen und das Technische Komitee 211 Geographic Information/Geomatics (ISO/TC 211). Die Spezifikationen beschreiben, wie rumliche Daten in relationalen Datenbanken verwaltet und gespeichert werden. Sie definieren weiterhin Datentypen, Text- und Binrformate zur Darstellung geometrischer Daten, sowie eine Reihe von Funktionen zur Verarbeitung dieser geometrischen Daten. 1997 verffentlichte das OGC OpenGIS Simple Features Specifications For SQL. Auf dessen Basis beruht die ISO 19125, welche noch auf den SQL-Standard SQL-92 basiert, der auf einer relationale Datenbank beruht. Geoobjekte knnen hierbei nummerisch oder binr abgespeichert werden. Die definierten Datentypen sind der Abbildung 2 zu entnehmen. Weiterhin definiert das OGC geometrische und rumliche Analysefunktionen sowie ein einheitliches Geodatenformat, welches fr einen Austausch zwischen verschieden Systemen geeignet ist: WKT-Format (Well-Known Text Format) eine Textreprsentation und Well-Known Binary Format), die binre Umsetzung (64Bit-Fliekommazahl) der geometrischen Daten. Zum SQL:1999-Standard (ISO/IEC 9075:1999) wurden Erweiterungen festgelegt, die nicht aufgrund ihrer Komplexitt und Eigenstndigkeit mit dem SQL-Standard decken konnten. SQL/MM (SQL Multimedia and Application Package) ist der Oberbegriff, fr die in der ISO 13249 beschriebenen Erweiterungen. SQL/MM Spatial (ISO 13249-3) ist im Gegensatz zum Simple-Feature auf eine objektorientierte oder objektrelationale Datenbank angewiesen. Denn die Datentypen knnen nur als Objekte gespeichert werden. Weitere wichtige Normen sind auf der jeweiligen Webseite des OGC und ISO/TC 211 zu finden. Abb. 2: Hierarchie der geometrischen Objekte (aus ISO 19125, 2006, S.5) Verwaltung von Geodaten Die OpenGIS-Spezifikationen ist die Basis fr die Verwaltung rumlicher Daten in beiden DBS. Oracle hat die ISO 19125 vollstndig umgesetzt. Hingegen MySQL bisher nur eine Teilimplementierung vorweist. Speicherung von geografischen Daten Fr die Speicherung von rumlichen Daten bietet Oracle die generelle Klasse SDO_GEOMETRY, welche die verschiedenen Geometrien der Simple Feature Specification des OGC reprsentieren kann. Zustzlich bietet Oracle Erweiterungen an, die konform mit weiteren Standards (z.B. ISO 13249-3) sind. Mit Hilfe zweier Parameter (SDO_GTYPE, SDO_ELEM_INFO bzw. SDO_POINT_TYPE) des SDO_GEOMETRY-Konstruktors lsst sich die jeweilige Geometrie definieren. -- Punkt anlegen INSERT INTO tblGeometry(position) VALUES (SDO_GEOMETRY( 2001, -- Punkt 8307, -- SRID WGS84 SDO_POINT_TYPE(-79, 37, NULL), -- Punktkoordinaten (zweidimensional) NULL, NULL ) ); -- Polygon anlegen INSERT INTO tblGeometry(area) VALUES (SDO_GEOMETRY( 2003, -- zweidimensionales Polygon 8307, -- SRID WGS84 NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), -- Rechteck (1003 = exterior) SDO_ORDINATE_ARRAY(-79,38 , -79,39) -- Koordinaten ) ); Mit der Version 10g bietet Oracle Konstruktoren mit dem WKT/WKB-Format. -- Anwendung des WKT-Konstruktors INSERT INTO tblGeometry(position) VALUES (SDO_GEOMETRY( 'POINT(-79 37)', -- Point im WKT-Format 8307 -- SRID WGS84 ) ); MySQL bietet zur Speicherung von Geodaten kein eigenen implementierten Konstruktor, sondern eigene Konvertierungsfunktionen, die nur das WKT/WKB-Format mit zurzeit folgenden Datentypen untersttzen: Geometry, Point, LineString, Polygon, GeometryCollection, MultiPoint, MultiLineString und MultiPolygon. Alle weiteren definierten Klassen der Simple Feature Specification, sind bis jetzt nur als abstrakte Klassen implementiert, und somit fr den Endanwender nicht nutzbar. In den Datentyp Geometry knnen alle Geometrien abgelegt werden. Die restlichen geometrischen Datentypen sind fr die jeweilige Geometrie vorgesehen. -- Anlegen einer Geometrie in MySQL INSERT INTO tblGeometry(position) VALUES (GEOMFROMTEXT('POINT(-79 37)', 4326); Die SRID (EPSG-Code konform) ist optional und wird zurzeit von MySQL fr smtliche Funktionen ignoriert. Indexierung von Geodaten Beide DBS verwenden fr die Indexierung den R-Tree-Index. Der R-Tree basiert auf das minimal umschlieende Rechteck (MUR, engl. MBR) jeder Geometrie. In MySQL wird das SQL-Statement zum Erstellen des rumlichen Indexes, um das Wort Spatial erweitert. -- rumlicher Index in MySQL CREATE SPATIAL INDEX sdx_position ON tblGeometry(position) In Oracle hingegen kann der Index durch zustzliche Parameter spezialisiert werden. Auch ist es dort durch spezielle Parameter mglich, einen Quadtree-Index als rumlichen Index zu erstellen. -- Oracle: Quadtree-Index mit Hybrid Indexing CREATE INDEX qdx_hybrid_geometry ON tblGeometry(geometry) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS('SDO_LEVEL=4', SDO_NUMTILES=10); -- Oracle: nur bestimmte Geometrien (Polygone) erlaubt CREATE INDEX sdx_area ON tblGeometry(area) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS('LAYER_GTYPE=POLYGON'); Funktionen Die Funktionen fr rumliche Daten lassen sich in allgemeine Funktionen (gelten fr alle Geometrien), spezielle Funktionen (gelten nur fr bestimmte Geometrien) und Analysefunktionen (beschreiben die Beziehung zwischen den Geometrien) gliedern. Beide DBS untersttzen eine Vielzahl dieser Funktionen. Aber MySQL untersttzt hingegen nur eingeschrnkt bzw. nicht vollstndig die Simple-Feature-Specification des OGC. Auch gibt es Besonderheiten in MySQL, die kurz zu erwhnen sind: Da Length() bereits fr die Lnge einer Zeichenkette vergeben ist, heit die Funktion zur Ermittlung der Lnge eines LineString-Wertes Glength(). Die existierenden Analysefunktionen fr die Beziehung zwischen zwei Geometrien auf Basis der exakten Grenze, geben aber das gleiche Resultat wie die Funktionen, welche auf das MUR beruhen zurck. Die Oracle Analysefunktionen knnen sowohl die Analyse auf das MUR (SDO_FILTER) als auch auf die exakte Geometrie (SDO_RELATE). Weiterhin bietet Oracle Funktionen zur Distanzbestimmung und Umkreissuche (SDO_WITHIN_DISTANCE) sowie Nachbaranfragen (SDO_NN) und geometrischen Verbunden (SDO_JOIN). Dies alles ist bereits in Oracle Locator enthalten. Der Funktionsumfang fr rumliche Daten erstreckt sich mit der Spatial Option in der Enterprise Edition weiter auf fertige Komponenten (Routing, Geocoder, GeoRaster, LRS etc.) und vordefinierte Datenmodelle (z.B. Netzwerkdatenmodell) sowie eine komplette Java-API. Migration von Geodaten In beiden DBS ist das Einspielen der rumlichen Daten per SQL mit Hilfe des WKT/WKB-Formates mglich. Oracle bietet noch weitere Mglichkeiten: per SQL mit Hilfe des SDO_GEOMETRY-Konstruktors, Oracle Shapefile Converter (auf OTN downloadbar), den Oracle SQL*Loader sowie Softwareprodukte von anderen Herstellern (z.B. FME von Safe Software) und diverse Exportfunktionen in GIS-Produkten. Geodaten zwischen beiden DBS auszutauschen, ist ber das WKT-Format mglich. Jedoch ist ob acht auf der SRID zu geben. Oracle untersttzt die EPSG-Codes und bietet hauseigene SRID an, z.B. gibt es fr den EPSG-Code 4326 (WGS84, Grundlage fr GPS-Koordinaten) auch den SRID 8307. Fr eine sichere Transformation zwischen den Referenzellipsoiden, die die Basis fr alle Berechnungen auf der Erdoberflche bilden, bietet Oracle die Funktion transform() an. Visualisierung durch Maps Karten sind eine intuitive Darstellungsform von rumlichen Sachverhalten. Die Visualisierung von rumlichen Daten geschah bisher in GIS-Anwendungen als reine Desktopanwendung. Mit dem Einzug von AJAX in Internetanwendungen sind Maps zur Visualisierung von Geodaten in Browsern besonders beliebt, weil sie fr jedermann verfgbar gemacht werden knnen. Google Maps Google Maps sind in jede Webseite einbaubar. Das Kartenmaterial als auch Funktionen werden ber die JavaScript-API von Google bereitgestellt. Somit basiert die Visualisierung auf den Karten- und Datenbestand von Google. Ein nennenswertes Feature ist der eingebaute Geocoder. Damit lassen sich auch postalische Adressen lokalisieren. /** * Erstellung der Map im angegebenen -Bereich * @param {Object} id div-Bereich * @param {Object} lat Latitude * @param {Object} lon Longitude */ function buildMap(div_id, lat, lon, zoom) { // die Map (fr das div mit der id) var map = new GMap2(document.getElementById(id)); // mit Typ-Auswahl map.addControl(new GMapTypeControl()); // (Breitengrad, Lngengrad), Zoomstufe, Mapansicht map.setCenter(new GLatLng(lat, lon), 5, G_SATELLITE_MAP); } /** * nutzen des Geocoders, um eine Adresse auf der Map zu zeigen * @param {Object} address Adresse */ function showAddress(address) { if (geocoder) { //Koordinaten fr Adresse abfragen geocoder.getLatLng(address, function(point) { if (!point) { alert(address+ " not found"); } else { map.setCenter(point, 13); var marker = new GMarker(point); map.addOverlay(marker); marker.openInfoWindowHtml(address); } } ); } } Rumliche Daten knnen somit auf gleiche Weise aus beiden DBS mit Google Maps dargestellt werden. Oracle Maps Neben Google Maps stellt Oracle mit Oracle Maps ein Konkurrenzprodukt auf den Markt. Der Oracle MapViewer bentigt den Oracle Application Server Containers for J2EE (OC4J), eine Standardkomponente des Oracle Application Servers. Den OC4J gibt es ebenfalls als Standalone-Installation. Der MapViewer erzeugt Folien (Layer) auf Grundlage von Geo-, Sach- und Metadaten, die in Tabellen vorliegen bzw. berechnet werden knnen, und kombiniert diese zu digitalen Kartenwerken, die ber das Web abgerufen und betrachtet werden knnen. Die berlagerten Folien bilden zusammen gerendert die Map (siehe Abb. 3). Abb. 3: Oracle Maps bestehend aus Folien mit Geodaten aus verschiedenen Quellen Die Metadaten der Map (themes, symbols, styles) werden mit XML beschrieben. Oracle gibt fr die Erstellung der Maps den MapBuilder zur Hand. Zusammenfassung In diesem Beitrag wurden die beiden DBS Oracle und MySQL im Bezug auf die Verwaltung von Geodaten gegenber gestellt. Der Sieger dieses Vergleiches ist Oracle. Oracle Spatial wurde seit 1997 fortlaufend weiterentwickelt. Hingegen MySQL 2003 nur den ersten Schritt in Richtung Speicherung von rumlichen Daten getan hat. Fr Anwendungen, die nur einen rumlichen Datenspeicher bentigen, ist MySQL geeignet. Fr weitere Funktionalitten ist der Funktionsumfang zu gering. Als gnstige Alternative bietet sich Oracle in der Express-Edition an. Dort steht der volle Funktionsumfang von Oracle Locator zur Verfgung: Speicherung (SDO_GEOMETRY) und Indexierung von Geodaten sowie diverse Analysefunktionen. Erst mit der Oracle Spatial Option in der Enterprise Edition kommt die volle Funktionalitt zum Tragen: MapViewer, Network Data Model, Liniear Referencing System (LRS), Geocoder, GeoRaster etc. Die Arbeit mit Oracle Maps ist vielseitiger als mit Google Maps. Jedoch bietet Google Maps ein Geocoder kostenfrei mit an. Quellen: [Brin2005] Brinkhoff, Thomas: Geodatenbanksysteme in Theorie und Praxis. Herbert Wichmann Verlag Heidelberg, 2005. - ISBN 3-87907-433-X [KoBe2004] Kothuri, Albert; Beinat E.: Pro Oracle Spatial. Springer Verlag, 2004. - ISBN 1-59059-383-9 [Koch2008A] Koch, Thomas: Geoinformationssysteme und Datenbanken. VDM Verlag Saarbrcken, 2008 - ISBN 978-3-8364-7231-9 [Koch2008B] Koch, Thomas: Verwaltung von Geodaten in Oracle. VDM Verlag Saarbrcken, 2008 - ISBN 978-3-639-07482-6 [Kofl2005] Kofler, Michael.: MySQL 5. 3. Auflage. Addison-Wesley, 2005. ISBN 3-8273-2253-7 [Czar2007] Czarski, Carsten: Oracle Spatial: Der Stand der Dinge, 2007. - URL http://www.doag.org/pub/docs/sig/spatial/2007/02/Czarksi_Spatial_StandDerDinge.pdf Kontakt: M.Sc. Thomas Koch E-Mail: it@job-koch.com Internet: it.job-koch.com /ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 300 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile () /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False /Description > /Namespace [ (Adobe) (Common) (1.0) ] /OtherNamespaces [ > /FormElements false /GenerateStructure true /IncludeBookmarks false /IncludeHyperlinks false /IncludeInteractive false /IncludeLayers false /IncludeProfiles true /MultimediaHandling /UseObjectSettings /Namespace [ (Adobe) (CreativeSuite) (2.0) ] /PDFXOutputIntentProfileSelector /NA /PreserveEditing true /UntaggedCMYKHandling /LeaveUntagged /UntaggedRGBHandling /LeaveUntagged /UseDocumentBleed false >> ]>> setdistillerparams> setpagedevice

Recommended

View more >