Geodaten für Alle: Oracle Spatial

Oracle sponsort das Geospatial World Forum 2012 vom 23.-27. April 2012 in Amsterdam

2011-11-09T15:16:00.000+01:00

Ein Geospatial World Forum in Europa gab es schon eine Weile nicht.
Aber jetzt ist eines in Vorbereitung und ich möchte alle diejenigen motivieren, sich aktiv daran zu beteiligen, welche tolle Projekte auf Basis von Oracle Spatial Technologien auf die Beine gestellt haben.
Abstracts können noch bis zum 20. November 2011 eingereicht werden.
Mehr Informationen zur Veranstaltung finden sich hier.

Beiträge zu "Spatial" auf der Oracle OpenWorld im Oktober 2011

2011-10-11T23:09:00.000+02:00

Die Beiträge zur Oracle OpenWorld 2011 sind bereits zum großen Teil aus dem Internet abrufbar, so auch die zu Spatial. Einfach den Content Catalog aufrufen, das Stichwort "Spatial" in das Suchfeld eintragen und auf die Schaltfläche Search klicken.

Standardkonforme Speicherung von Geodaten in der Oracle Datenbank jetzt auf Youtube

2011-10-11T22:52:00.000+02:00

Wir haben einen Überblick zu Oracle Spatial multimedial aufbereitet.
Sehen Sie jetzt also in 2 Teilen "Standardkonforme Speicherung von Geodaten":

Dank an den Oracle-Werkstudenten Peter Lenke in Potsdam dafür. Und natürlich an Michal.

Oracle Spatial auf der "DOAG2011" in Nürnberg

2011-09-27T17:17:00.001+02:00

Die Vorträge, die sich um das Thema Geodaten, Oracle Spatial, Locator und Maps drehen, sind im DOAG-Konferenzprogramm nicht so einfach zu finden. Für am Thema interessierte daher hier eine Zusammenstellung. Das gesamte Konferenzprogramm findet sich, wie immer auf der DOAG-Webseite.

Einsatz digitaler Landkarten in der Analyse von Business Informationen
Gerrit Schreiber, GfK Geomarketing GmbH
15.11.2011 14:00 - 14:45 Uhr - Raum Oslo
Get extreme performance with Oracle Spatial on Oracle Exadata
Hans Viehmann, Oracle Deutschland B.V. & Co KG
16.11.2011 10:00 - 10:45 Uhr - Raum Tokio
Management von standortbezogenen Daten mit Oracle Application Express
Prof. Dr. Petra Sauer, Beuth Hochschule für Technik Berlin
16.11.2011 13:00 - 13:45 Uhr - Raum Istabul
Geodaten intelligent nutzen
Joachim Figura, CISS TDI GmbH
16.11.2011 13:00 - 13:45 Uhr - Raum Neu Delhi
Das Navi in der Datenbank: Oracle11g has NAVTEQ on Board
Till Kreiler, NAVTEQ und Carsten Czarski, ORACLE Deutschland B.V. & Co KG
17.11.2011 12:00 - 12:45 Uhr - Raum Shanghai
Oracle Maps (Spatial) Karten in Java Anwendungen: How to... (ADF)
Bernhard Fischer-Wasels, ORACLE Deutschland B.V. & Co KG
17.11.2011 14:00 - 14:45 Uhr - Raum Istanbul

Und als "Bonus-Track" sei auch dieser Vortrag erwähnt - das Thema hat zwar nichts mit Geodaten zu tun, ist aber dennoch Bestandteil der Spatial-Option. Und daher gehört er auch auf die Liste

Ontologien und semantische Netze aus Sicht der Datenbank
Karin Patenge, ORACLE Deutschland B.V. & Co KG
16.11.2011 09:00 - 09:45 Uhr, Raum Seoul

Ich hoffe, ich habe keinen Vortrag übersehen.

Oracle und die INTERGEO 2011

2011-09-06T21:42:00.000+02:00

Wir werden auch dieses Jahr wieder auf der INTERGEO sein.

Bewährtermassen werden wir wie in den vergangenen Jahren an den Ständen einiger unserer Oracle-Partner aus dem GIS-Umfeld "Flagge zeigen".
Besuchen Sie uns also einfach hier:

Firma grit - graphische Informationstechnik GmbH in Halle 7A Stand C45
Firma CISS TDI in Halle 7 Stand C50
Firma GDV Gesellschaft für geografische Datenverarbeitung mbH in Halle 7A Stand D46

Wir können gemeinsam über spannende Themen berichten, z.B.:

Wie kann man in der Oracle Datenbank eine gitterbasierte Transformation von Gauss-Krüger nach ETRS89 durchführen?
Wie sehen OpenStreetMap-Daten im Netzwerkdatenmodell von Oracle Spatial aus?
Oder wie funktioniert das Routing in der Oracle Datenbank ebenfalls auf der Basis des Netzwerkdatenmodells?

Wir freuen uns schon jetzt auf Ihren Besuch!

Wie man Wartezeiten sinnvoll abkürzt oder wobei hilft mir SDO_JOIN?

2011-08-05T18:01:00.001+02:00

Was passiert eigentlich auf einem Standard Notebook mit der Oracle Datenbank an Bord, wenn man alle Geometrien einer Tabelle mit allen (oder so gut wie allen) Geometrien einer anderen Tabellen verschneiden will?

Das habe ich mal ausprobiert am Beispiel des GfK GeoMarketing Deutschlanddatensets. Dazu habe ich mir folgendes Result Set überlegt:

Ich brauche eine Auflistung der

administrativen Ebene 3 (Name und Gemeindekennziffer der Stadt- und Landkreise)
administrativen Ebene 4 (Name und Gemeidekennziffer Gemeinden)
und der den Gemeinden zugeordneten 5-stelligen Postleitzahlen.

Frisch ans Werk und sozusagen straight forward habe ich es mal mit dieser SQL-Abfrage probiert:

select 
  d.id , 
  d.name "Name Stadt-/Landkreis", 
  d.new___z "Anzahl EW Stadt-/Landkreis",
  g.id "ID Gemeinde", 
  g.name "Name Gemeinde", 
  g.new___z "Anzahl EW Gemeinde",
  p.id "PLZ"
from 
  de_municipalities_2010 g,
  de_districts_2010 d,
  de_5digpc_2010 p
where
  substr(g.id,1,5) = d.id and 
  sdo_relate(g.geometry, p.geometry, 'mask=anyinteract') = 'TRUE' and 
  p.id = '16515'
group by
  d.id , 
  d.name, 
  d.new___z,
  g.id, 
  g.name, 
  g.new___z,
  p.id
order by
  d.id , 
  d.name, 
  g.id, 
  g.name,
  p.id
/

Aus Erfahrung weiss man um die Nützlichkeit von Filtern, welche die zu vergleichenden Datenmengen zunächst erst einmal einschränken. Von daher die Betrachtung erst mal nur einer einzigen Postleitzahl.

Ein bisschen mutiger geworden, wird der Filter dann gelockert, um ihn ganz zu entfernen. Denn Ziel war ja, den kompletten Datenbestand beider Tabellen räumlich in Beziehung zu setzen, um auch die Postleitzahlen zu ermitteln, welchen den Gemeinden zugeordnet sind. Das sind knapp 11600 Gemeinden und gut 8200 PLZs.

So und das war es dann auch erst mal für den Nachmittag, den Abend ... und auch am nächsten Morgen hatte sich noch kein Result Set einstellen wollen.

Also muss es wohl noch besser gehen.

Folgende überlegungen führten dann zu weiteren Vesuchen:

Ich stelle sicher, dass für beide Tabellen der räumliche Index benutzt wird.
Ich nutze erst mal nur den Primary Filter, um ein annäherndes Ergebnis zu erhalten. Danach wird der exakte Vergleich nur noch mit dem dann schon eingeschränkten Datenset vorgenommen.

Mit diesen beiden Gedanken im Hinterkopf und ggf. auch noch mal einem Blick ins Oracle Spatial Handbuch, wird man bei SDO_JOIN fündig.

Wie funktioniert dabei SDO_JOIN?

select
  rowid1 as municipalities_id,
  rowid2 as plz5_id
from
  table(
    sdo_join(
   'DE_MUNICIPALITIES_2010',
   'GEOMETRY',
   'DE_5DIGPC_2010',
   'GEOMETRY',
   'mask=anyinteract'))
/

Und siehe da: Diese Abfrage dauert keine 2 Minuten.
Allerdings fehlt ja auch noch der Join mit der 3. Tabelle und auch group by und order by sollen schon sein und kosten die Datenbank so einiges an Ressourcen und damit Zeit.

Also muss der Rest auch noch her und ergibt dann diese SQL Abfrage:

with spatial_join_result as (
select
  rowid1 as municipalities_id,
  rowid2 as plz5_id
from
  table(
    sdo_join(
   'DE_MUNICIPALITIES_2010',
   'GEOMETRY',
   'DE_5DIGPC_2010',
   'GEOMETRY',
   'mask=anyinteract')))
select 
  d.name "Name Stadt-/Landkreis", 
  d.new___z "Anzahl EW Stadt-/Landkreis",
  g.name "Name Gemeinde", 
  g.new___z "Anzahl EW Gemeinde",
  p.id "PLZ"  
from
  spatial_join_result a, 
  de_municipalities_2010 g,
  de_5digpc_2010 p,
  de_districts_2010 d  
where
  a.municipalities_id = g.rowid and
  a.plz5_id = p.rowid and
  sdo_relate(g.geometry, p.geometry, 'mask=anyinteract') = 'TRUE' and
  substr(g.id, 1, 5) = d.id  
-- Hierarchische Verknüpfung Admin Ebene 3 mit Admin Ebene 4
group by
  d.name,
  d.new___z,
  g.name,
  g.new___z,
  p.id
order by
  d.name,
  d.new___z,
  g.name,
  g.new___z,
  p.id
/

Jetzt habe ich, was ich mir zum Ziel gesetzt hatte und zwar in einer Zeit von 14 Minuten. Das reicht zwar immer noch für einen Plausch mit den Kollegen zwischendurch. Aber diese Zeit ist erst mal akzeptabel.

Für diejenigen Leserinnen und Leser dieses Blogeintrags, die im Besitz einer (gern auch mehrerer) Oracle DB Enterprise Edition Lizenz sind, sei gesagt, dass sie damit noch mehr Optimierungspotential haben. Das verheissungsvolle Wort an dieser Stelle ist Parallisierung.
Wie das funktioniert, dafür verweise ich jetzt einfach mal auf diesen Link. Denn sonst verpasse ich vielleicht noch meinen Flieger in den Urlaub.

Aktueller MapViewer Patch (11g PS4) released

2011-07-04T15:47:00.000+02:00

Wir sind hier mit dem Oracle Spatial Blog zwar auf der Datenbank-Seite. Aber ohne Visualisierung sind Geodaten zwar zu benutzen im Sinne einer Prozessierung, aber halt nicht besonders anschaulich. Von daher sei die nachfolgende Mitteilung gestattet:

Der aktuelle Patch (11g PS4) für Oracle Fusion Middleware MapViewer (MapViewer version 11.1.1.5) steht hier zum Download bereit.

Geodatenschätze heben - Räumliche Analysen und Data Mining

2011-06-09T18:11:00.031+02:00

Über gängige räumliche Operatoren und Funktionen hinaus bietet Oracle Spatial Methoden, um den Einfluss von Nachbarschaftsbeziehungen auf der Basis der Verortung von Objekten zu untersuchen, abzuschätzen und vorauszusagen.

Diese sind den folgenden Anwendungsbereichen zugeordnet und im PL/SQL Package SDO_SAM implementiert:

Location Prospecting Analysis
Clustering Analysis
Spatial Mining
Neighborhood-Bases Estimation

Der heutige Blogeintrag gibt einen ersten kleinen Einblick in die von diesem Package bereitgetellten Methoden.

SDO_SAM.AGGREGATES_FOR_LAYER in Anwendung

Betrachten wir folgenden Anwendungsfall:

Für die Beurteilung der Auswirkungen von Fluglärm sollen die Bewohnerinnen und Bewohner im Umkreis von 5 km um die Flughäfen ermittelt werden.

Für die notwendige Analyse wird als Datengrundlage bewährtermassen das von der GfK GeoMarketing für die Oracle Datenbank bereitgestellte Deutschland-Datenset verwendet. Darin enthalten sind (u.a.) die Tabellen:

DE_AIRPORTS mit allen Flughäfen in Deutschland
DE_5DIGPC_2010 mit den 5-stelligen PLZ-Geometrien und u.a. der Population als Kennzahl

Diese nutzen wir ebenso wie die Prozedur AGGREGATES_FOR_LAYER im PL/SQL-Package SDO_SAM.
Im nachfolgenden SQL-Befehl, welcher einen View anlegt, sind die Parameter-Werte für die Prozedur kommentiert, um ihre Verwendung zu erklären.

-- Berechnet thematisches Aggregat für einen Geometrielayer 
create or replace view de_stats_pop_around_airports
as
select 
  a.name,
  a.type,
  round(b.aggregate_value) aggregate_value,
  b.geometry
from
  table(  
    sdo_sam.aggregates_for_layer(
      'DE_5DIGPC_2010',      -- Theme-Tabelle. 5-stellige PLZ Geometrien
      'GEOMETRY',            -- Geometriespalte der Theme-Tabelle
      'SUM',                 -- Aggregatsfunktion (Summe)
      'NEW___Z',             -- Zu aggregierender Wert (Bevölkerung absolut)
      'DE_AIRPORTS',         -- Data Mining Tabelle (Flughäfen)
      'GEOMETRY',            -- Geometriespalte in Data Mining Tabelle
      'distance=5 unit=km')  -- Distanzspezifikation (Umkreis von 5km um Flughäfen)
  ) b,
  de_airports a
where 
  b.region_id = a.rowid;

Die in diesem View aggregierten Daten sollen auf einer Karte dargestellt werden. Dafür benötigen wir zunächst einmal die Metadaten. Die Syntax für den entsprechenden INSERT-Befehl ist sichert vertraut.

-- Metadaten
insert into user_sdo_geom_metadata (
  table_name, 
  column_name, 
  diminfo,
  srid) 
values (
  'DE_STATS_POP_AROUND_AIRPORTS',
  'GEOMETRY',
  sdo_dim_array(sdo_dim_element('Lon',-180,180,0.005),
  sdo_dim_element('Lat',-90,90,0.005)),
  8307);

Der Rest ist dann Arbeit für den Oracle MapBuilder. Dort wird ein enstprechender Style definiert (Kreis roter Füllung und schwarzer Umrandung). Dieser Style wird für ein Theme verwendet, welches als Advanced Theme > Variable Marker definiert ist.
Das Ergebnis ist im nachfolgenden Bild dargestellt. Um die thematische Kartenebene räumlich besser einordnen zu können, wurde eine weitere Kartenebene hinterlegt, welche die Bundesländergrenzen von DE abbildet.

Thematische Karte mit Population im Umkreis von 5 km um Flughäfen dargestellt als Ranged Variable Markers
(basierend auf einem Deutschland-Datenset der GfK GeoMarketing für die Oracle DB)

Mit SDO_SAM.AGGREGATES_FOR_LAYER liegt damit ein Einstieg ins Thema vor. Weitere Tipps & Tricks zum Thema werden folgen.

Der Vollständigkeit halber sind nachfolgend noch die XML-Dokumente für den Advanced Style und das Theme eingefügt.

<?xml version="1.0" ?>
<AdvancedStyle>
  <VariableMarkerStyle basemarker="CITIES_OVER_100K" startsize="5" increment="4">
    <Buckets>
      <RangedBucket seq="0" label="<5K" low="-Infinity" high="5000" label_style="LABELS"/>
      <RangedBucket seq="1" label="5-10K" low="5000" high="10000" label_style="LABELS"/>
      <RangedBucket seq="2" label="10-20K" low="10000" high="20000" label_style="LABELS"/>
      <RangedBucket seq="3" label="20-50K" low="20000" high="50000" label_style="LABELS"/>
      <RangedBucket seq="4" label="50-100K" low="50000" high="100000" label_style="LABELS"/>
      <RangedBucket seq="5" label="100-200K" low="100000" high="200000" label_style="LABELS"/>
      <RangedBucket seq="6" label="200-500K" low="200000" high="500000" label_style="LABELS"/>
      <RangedBucket seq="7" label=">500K" low="500000" high="Infinity"/>
    </Buckets>
  </VariableMarkerStyle>
</AdvancedStyle>

<?xml version="1.0" standalone="yes"?>
<styling_rules>
    <hidden_info>
        <field column="NAME" name="Name des Flughafens"/>
        <field column="AGGREGATE_VALUE" name="Population absolut"/>
        <field column="TYPE" name="Typ des Flughafens"/>
  </hidden_info>
    <rule column="AGGREGATE_VALUE">
        <features style="V.DE_POP_AROUND_AIRPORTS"> </features>
        <label column="NAME" style="LABELS"> 1 </label>
  </rule>
</styling_rules>

Aus Oracle nach Google Earth mit Hilfe von KML

2011-05-30T16:12:00.003+02:00

Das SDO_UTIL Package (Utility) bietet seit der Version 11g der Oracle Datenbank neue Möglichkeiten für einen direkten Umgang mit der Keyhole Markup Language (KML).

So können beispielsweise spatiale Geometrien mit Hilfe der Funktion sdo_util.to_kmlgeometry in KML umgewandelt werden. Umgekehrt können mit Hilfe der Funktion sdo_util.from_kmlgeometry KML-Geometrien in spatiale Geometrien umgewandelt werden.

In diesem Artikel erfahren Sie, wie die Funktion sdo_util.to_kmlgeometry angewendet wird und wie Sie das Ergebnis zu einem vollständigen KML-Dokument, welches anschließend in Google Earth geladen wird, umwandeln können.

Schauen wir uns einen einfachen Anwendungsfall an:

SELECT sdo_util.to_kmlgeometry(geometry) KML

FROM M_ADMIN_AREA2
WHERE feature_name = 'BERLIN';

Als Ergebnis dieser Abfrage erhalten wir eine KML-Geometrie für das Bundesland Berlin:

KML

---------------------------------------------------------------------------

<Polygon><extrude>0</extrude><tessellate>0</tessellate><altitudeMode>relativeToGround</altitudeMode><outerBoundaryIs><LinearRing><coordinates>

13.56177,52.5804 13.54188,52.58915 13.53483,52.59068 13.50847,52.59241 13.49723,52.60583 13.49827,52.60961 13.50573,52.62563 13.51852,52.63162 13.52244,52.64464 13.5124,52.64478 13.49034,52.65466 13.48478,52.65872
...
...
13.65677,52.52511 13.65713,52.52987 13.62592,52.53013 13.62523,52.53815 13.63451,52.53879 13.63662,52.54234 13.58706,52.54958 13.58239,52.56993 13.56894,52.57295 13.56177,52.5804</coordinates></LinearRing></outerBoundaryIs></Polygon>

---------------------------------------------------------------------------

Wenn Sie dieses Ergebnis in einer KML-Datei abspeichern und diese Datei in Google Earth öffnen, dann wird die oben abgefragte Geometrie zunächst nicht angezeigt. Zu einem vollständigen KML-Dokument fehlen neben dem XML-Header noch einige Angaben, die wir mit Hilfe der XML DB, einem Feature welches in jeder Oracle Datenbank enthalten ist, ergänzen werden.

Überprüfen Sie zuerst, ob XML DB bei der Datenbank-Installation mit installiert wurde. Führen Sie dazu im SQL*PLUS die folgende Abfrage aus:

select comp_name, status from dba_registry where comp_name='Oracle XML Database';

Falls diese Funktionalität in Ihrer Datenbank nicht installiert sein sollte, dann können Sie das XML DB Repository mit Hilfe des folgenden Scripts nachinstallieren

$ORACLE_HOME/rdbms/admin/catqm.sql

Kommen wir zu unserer Ausgangsabfrage zurück und ergänzen diese um die fehlenden Angaben:

SELECT
xmlelement("kml",
   xmlattributes('http://www.opengis.net/kml/2.2' as "xmlns"),
   xmlelement("Document",
    xmlelement("Placemark",
     xmlelement("name", 'Berlin'),
     xmlelement("Description", 'Flaeche des Bundeslandes Berlin'),
     xmltype(sdo_util.to_kmlgeometry(geometry))
    )
   )
)
FROM M_ADMIN_AREA2 WHERE feature_name = 'BERLIN';

Das Ergebnis bildet ein vollständiges KML-Dokument:

<kml xmlns="http://www.opengis.net/kml/2.2">

<Document>

<Placemark>

<name>Berlin</name>

<Description>Flaeche des Bundeslandes Berlin</Description>

<Polygon>

<extrude>0</extrude>

<tessellate>0</tessellate>

<altitudeMode>relativeToGround</altitudeMode>

<outerBoundaryIs>

<LinearRing>

<coordinates>13.56177,52.5804 13.54188,52.58915 13.53483,52.59068 13.50847,52.59241 13.49723,52.60583 13.49827,52.60961 13.50573,52.62563 13.51852,52.63162 13.52244,52.64464 13.5124,52.64478 13.49034,52.65466 ...
...
...
13.62592,52.53013 13.62523,52.53815 13.63451,52.53879 13.63662,52.54234 13.58706,52.54958 13.58239,52.56993 13.56894,52.57295 13.56177,52.5804</coordinates>

</LinearRing>

</outerBoundaryIs>

</Polygon>

</Placemark>

</Document>
</kml>

Speichern Sie das Dokument ab und öffnen Sie es in Google Earth:

Spatiale Geometrie in Google Earth

Mit Hilfe der XML-Funktionen können Sie das KML-Dokument erweitern und weitere Attribute hinzufügen. Probieren Sie diese Abfrage aus:

SELECT

xmlelement("kml",

   xmlattributes('http://www.opengis.net/kml/2.2' as "xmlns"),

   xmlelement("Document",

    xmlelement("name", 'Berlin.kml'),

    xmlelement("StyleMap", XMLATTRIBUTES('mp' as "id"),

    xmlelement("Pair",

       xmlelement("key",'normal'),

       xmlelement("styleUrl",'#mp_border')

    )

    ),

    xmlelement("Style", XMLATTRIBUTES('mp_border' as "id"),

    xmlelement("LineStyle",

       xmlelement("color",'ffff0000'),

       xmlelement("width",'10')

    )

    ),

    xmlelement("Placemark",

     xmlelement("name", 'Berlin'),

     xmlelement("styleUrl", '#mp'),

     xmlelement("Description", 'Flaeche des Bundeslandes Berlin'),

     xmltype(sdo_util.to_kmlgeometry(geometry))

    )

   )
)
FROM M_ADMIN_AREA2 WHERE feature_name = 'BERLIN';

Als Ergebnis erhalten Sie einen blauen Rand um die angezeigte Geometrie:

Spatiale Geometrie mit blauer Umrandung in Google Earth

Toleranz und Performanz bei räumlichen Abfragen

2011-05-26T10:50:00.011+02:00

In diesem Blogeintrag soll es um die Frage gehen, ob unterschiedliche Werte für den Toleranzparameter Einfluss auf die Performanz räumlicher Abfragen haben.

Die Datenbank arbeitet mit Toleranzen sowohl bei der Definition der SDO-Metadaten als auch bei räumlichen Abfragen. Die Toleranz steht dabei für den Abstand, den 2 (Stütz-)Punkte maximal haben dürfen, um sie als identisch anzusehen. Die Toleranz ist somit ein Mass für die Genauigkeit räumlicher Daten.

Testsituation

Um die anfangs aufgeworfene Frage zu beantworten, wurden zwei Testreihen aufgesetzt, bei denen verschiedene räumliche Funktionen mit skalierenden Toleranzen zur Anwendung kommen. Zwei Testreihen deshalb, um die Auswirkungen für einen relativ kleinen (~8.200 Sätze) und einen größeren Datenbestand (~830.000 Sätze) zu untersuchen.
Die Testdaten, ausschliesslich Polygone mit den 5-stelligen Postleitzahlgeometrien von Deutschland, wurden vom Oracle-Partner GfK GeoMarketing bereitgestellt. Das verwendete Koordinatensystem ist 8307, die Metadaten sind mit einer Toleranz von 0,05 (5 cm) registriert.

An räumlichen Funktionen wurden verwendet:

SDO_GEOM.RELATE
SDO_GEOM.SDO_ALPHA_SHAPE
SDO_GEOM.SDO_AREA
SDO_GEOM.SDO_BUFFER
SDO_GEOM.SDO_CENTROID
SDO_GEOM.SDO_CONCAVEHULL
SDO_GEOM.SDO_CONVEXHULL
SDO_GEOM.SDO_CONCAVEHULL
SDO_GEOM.SDO_DIFFERENCE
SDO_GEOM.SDO_DISTANCE
SDO_GEOM.SDO_INTERSECTION
SDO_GEOM.SDO_TRIANGULATE
SDO_GEOM.SDO_UION
SDO_GEOM.SIMPLIFY_GEOMETRY

Die Toleranz wurde angefangen mit dem Wert 0.1 (10 cm) pro Iteration verdoppelt bis zum Maximalwert von ~205 (m).

Für die Testsituation wurden nach dem Anlegen der Testtabellen aktuelle Statistiken berechnet.

begin 
  DBMS_STATS.GATHER_TABLE_STATS (
    ownname => '"GFK"',
    tabname => '"TEST_TOL_IMPACT"',
    estimate_percent => 100
  );
end;

Außerdem wurden bei jeder Iteration sowohl Shared Pool als auch Buffer Cache geleert.

alter system flush buffer_cache;
alter system flush shared_pool;
-- Hierfür benötigt der Nutzer alter system Recht

Dieses Vorgehen ist ausdrücklich nicht für produktive Umgebungen zu empfehlen, dient aber hier der Vergleichbarkeit der Ausführungszeiten.
Diese wurden gemessen, indem für jede räumliche Abfrage vorher als auch hinterher die Total Time sowie CPU Time mittels zweier PL/SQL Funktionen gemessen wurde.

-- Gesamtzeit
create or replace function measure_total_time 
return 
  pls_integer
is
begin
  return dbms_utility.get_time;
end measure_total_time;
/
-- CPU Zeit
create or replace function measure_cpu_time 
return 
  pls_integer
is
begin
  return dbms_utility.get_cpu_time;
end measure_cpu_time;
/
-- Für die Ausführung benötigt der Nutzer das Recht EXECUTE auf dem Package dbms_utility

Die Differenz der vorher und nachher gemessenen Werte jeweils geteilt durch 100 ergibt die Ausführungs- bzw. CPU-Zeit in Sekunden.

Alle Messwerte wurden in 2 Ergebnistabellen festgehalten, mit APEX-Bordmitteln ausgewertet und grafisch als 2D Line Charts mit je einer Serie pro räumlicher Funktion aufbereitet. Die Ergebnisse sind in den Abbildungen am Ende dieses Blogeintrags zu sehen.

Welche Erkenntnisse liefern die Messwerte?

Die Annahme, dass die Ausführungszeiten mit geringer werdenden Toleranzwerten (also höherer Genauigkeit) korreliert, hat sich bei keiner der räumlichen Funktionen bestät.
Die gemessenen Zeiten für Testreihe 2 (~830.000 Sätze) sind vergleichbar mit denen von Testreihe 1 (~8.200 ätze).
Mit gemessenen CPU-Zeiten bis maximal 0,3 sec und durchschnittlichen Gesamtzeiten von 1,3 (Testreihe 1) und 1,5 (Testreihe 2) waren die Abfragen trotz flush shared_pool und flush buffer_cache recht performant.
Als Testsystem diente ein 64bit Laptop mit Intel i5 Prozessor und 4 GB als maximaler SGA Grösse.

An dieser Stelle möchte ich noch mal darauf hinweisen, dass im Gegensatz zu den Ausführungszeiten die jeweiligen Ergebnismengen nicht im Fokus der Tests standen.

Fazit

Räumliche Abfragen können jeweils mit einer im Hinblick

auf die Genauigkeit des Datenbestandes und
die erwartete Ergebnismenge

passenden Toleranz ausgeführt werden, ohne dass dies signifikante Auswirkungen auf die Performanz hat.

Abbildungen

Testreihe 1 - Total Time

Testreihe 1 - CPU Time

Testreihe 2 - Total Time

Testreihe 2 - CPU Time

Große Geodatenmengen: In Nullkommanix mit Transportable Tablespaces

2011-05-05T16:02:00.003+02:00

Gerade im Geodaten-Bereich ist das Übertragen größerer Datenmengen von einer Datenbank zur anderen nicht selten. Die Standardlösung ist meist Export und Import - ab Oracle10g gerne auch mit der Data Pump. Wenn man die dazu benötigte Zeit betrachtet, schlägt neben der Zeit, die das reine Bewegen der Daten benötigt, auch die Zeit zum Indexaufbau zu Buche; denn ein Export/Import ist im Grunde genommen nichts weiter als das automatisierte Neu-Erstellen der Tabellen, dann finden SQL-INSERT-Operationen zum Einfügen der neuen Daten statt und schließlich werden die Indizies neu gebaut. Und wenn die Datenmengen größer sind, muss man für den letzten Punkt schon etwas Zeit einplanen.

NAVTEQ stellt seine Daten für Oracle Spatial (Kartendarstellung, Geocoding und Routing in der Datenbank) daher als Transportable Tablespace bereit. 150G Daten für die EU lassen sich so in 15 Minuten einspielen - obwohl die Neu-Erstellung aller Spatial-Indizes alleine sicherlich mehrere Stunden brauchen würde. Und diese Möglichkeit ist nicht NAVTEQ alleine vorbehalten. Transportable Tablespaces können mit jeder Datenbank bereitgestellt werden (Export), möchte man sie importieren, so wird eine Enterprise Edition benötigt.

Verwendet man Transportable Tablespaces, so exportiert das Export-Werkzeug (expdp) nur noch die Metadaten - es wird keine einzige Tabellenzeile bewegt. Zum Übertragen der Daten wird dann schließlich die Orginal-Datendatei vom Quell- auf das Zielsystem kopiert. Beim Importieren der Metadaten wird die Datei schließlich in die Datenbank eingehängt und alle Daten sind sofort da - auch alle Spatial-Indizes stehen sofort bereit. Und im folgenden ist anhand eines Beispiels beschrieben, wie man mit Transportable Tablespaces arbeitet.

Export: Vorbereitungen

Zunächst muss überpüft werden, ob das Tablespace self-contained ist, das heißt, dass keine Abhängigkeiten zu Objekten in anderen Tablespaces vorhanden sind. Diese Prüfung muss man nicht selbst machen, die Prozedur DBMS_TTS.TRANSPORT_SET_CHECK übernimmt das. Der folgende Aufruf prüft also nach, ob der Tablespace GEOWS problemlos zu einer anderen Datenbank transportiert werden kann.

begin
  DBMS_TTS.TRANSPORT_SET_CHECK('GEOWS', TRUE, TRUE);
end;

Die Ergebnisse der Prüfung finden sich dann in der Dictionary View TRANSPORT_SET_VIOLATIONS.

SQL> select * from transport_set_violations;

no rows selected.

Wenn man auf einer 11.2-Datenbank arbeitet, kann der nächste Schritt übersprungen werden. Alle anderen müssen nun die Spatial-Indizes "vorbereiten"; es müssen Metainformationen aufgezeichnet werden, damit die Indizes auf der Zieldatenbank wiederhergestellt werden können. Das geht mit der Prozedur SDO_UTIL.PREPARE_FOR_TTS wie folgt (man muss als Eigentümer der Daten eingeloggt sein).

begin
  sdo_util.prepare_for_tts;
end;

Wie gesagt: Ab Datenbankversion 11.2 ist das nicht mehr nötig. Die dann folgenden Schritte müssen wiederum bei allen Datenbankversionen durchgeführt werden: Da die Datendatei mit Betriebssystem-Mitteln kopiert werden wird, darf die Datenbank sie nicht mehr verändern. Jetzt ist also der richtige Zeitpunkt, das Tablespace read only zu setzen. Also als DBA:

alter tablespace geows read only;

Export

Nun erfolgt das eigentliche Exportieren mit der Data Pump. Es wird ein Directory-Objekt benötigt, in welches die Data Pump das Dumpfile (welches nur noch Metadaten enthält) schreiben soll. Das wird als DBA angelegt.

create directory expdir as '/path/to/folder/for/dumpfile';

Und dann kommt das eigentliche Exportieren ... auch das wird als DBA durchgeführt und nicht als Schema-Eigentümer.

$ expdp userid=system/{password} 
        dumpfile=geows.dmp 
        directory=expdir 
        transport_tablespaces=geows 
        logfile=exp_geows.log

Export: Release 11.2.0.2.0 - Production on Thu May 5 13:44:03 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining
and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_TRANSPORTABLE_01":  userid=system/******** dumpfile=geows.dmp directory=homedir transport_tablespaces=geows logfile=exp_geows.log
Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
Processing object type TRANSPORTABLE_EXPORT/TABLE
Processing object type TRANSPORTABLE_EXPORT/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type TRANSPORTABLE_EXPORT/TABLE_STATISTICS
Processing object type TRANSPORTABLE_EXPORT/DOMAIN_INDEX/TABLE
Processing object type TRANSPORTABLE_EXPORT/DOMAIN_INDEX/INDEX
Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
Master table "SYSTEM"."SYS_EXPORT_TRANSPORTABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_TRANSPORTABLE_01 is:
  /path/to/folder/for/dumpfile/geows.dmp
******************************************************************************
Datafiles required for transportable tablespace GEOWS:
  /opt/oracle/oradata/orcl/geows01.dbf
Job "SYSTEM"."SYS_EXPORT_TRANSPORTABLE_01" successfully completed at 13:45:30

Die letzten vier Zeilen der Ausgabe beschreiben, wo die nötigen Dateien zu finden sind; diese können jetzt mit Betriebssystemmitteln kopiert, als Archiv gepackt und auf das Zielsystem übertragen, auf CD gebrannt oder zum Download bereitgestellt werden.

Import: Vorbereitungen

Auf dem Zielsystem muss zunächst das Datenbankschema angelegt werden. Es sollte (wie immer) alle Privilegien haben, die auch auf dem Quellsystem vorhanden waren. Als nächstes muss ein Blick auf die Betriebssystem-Plattformen von Quell- und Zielsystem geworfen werden.

Denn wie Oracle die Bytes in seinen Datendateien anordnet, hängt von der Plattform ab. Big Endian-Plattformen arbeiten anders als Little Endian-Plattformen. Aber die Datenbank weiß Bescheid.

SQL> SELECT * FROM V$TRANSPORTABLE_PLATFORM ORDER BY PLATFORM_NAME

PLATFORM_ID PLATFORM_NAME                        ENDIAN_FORMAT
----------- ------------------------------------ --------------
          6 AIX-Based Systems (64-bit)           Big
         16 Apple Mac OS                         Big
         21 Apple Mac OS (x86-64)                Little
         19 HP IA Open VMS                       Little
          4 HP-UX IA (64-bit)                    Big
         18 IBM Power Based Linux                Big
          9 IBM zSeries Based Linux              Big
         10 Linux IA (32-bit)                    Little
         11 Linux IA (64-bit)                    Little
         13 Linux x86 64-bit                     Little
          7 Microsoft Windows IA (32-bit)        Little
         12 Microsoft Windows x86 64-bit         Little
         17 Solaris Operating System (x86)       Little
          : :                                    :

Die Datendateien können also von einer Linux- problemlos auf eine Windows-Plattform übertragen werden, da beide Plattformen Little-Endian-Plattformen sind. Beim Übertragen von Windows auf bspw. HP-UX IA 64bit wird es dagegen Probleme geben - die Datenbank dort könnte die Dateien gar nicht lesen. Aber das ist kein Problem - denn die Dateien können konvertiert werden. Diese Konvertierung wird mit dem RMAN-Werkzeug und dem Kommando CONVERT entwieder auf dem Quell- oder auf dem Zielsystem durchgeführt - je nachdem, ob man die Zielplattform beim Exportieren schon kennt oder nicht.

Konvertiert man auf dem Quellsystem, so verwendet man das RMAN-Kommando CONVERT TABLESPACE.

$ RMAN TARGET /
 
Recovery Manager: Release 11.2.0.2.0
 
Copyright (c) 1982, 2009, Oracle.  All rights reserved.

connected to target database: ORCL (DBID=1277326448)

RMAN> convert tablespace geows
      to_platform = "HP-UX (64-bit)"
      format='/home/oracle/hpux%U';

Starting conversion at source at 05-MAY-11
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile conversion
input datafile file number=00008 name=/opt/oracle/oradata/orcl/geows01.dbf
converted datafile=/home/oracle/hpuxdata_D-ORCL_I-1277326448_TS-GEOWS_FNO-8_01mbiqgn
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:25
Finished conversion at source at 05-MAY-11

Konvertiert man auf dem Zielsystem, so nutzt man das Kommando CONVERT DATAFILE.

$ RMAN TARGET /
 
Recovery Manager: Release 11.2.0.2.0
 
Copyright (c) 1982, 2009, Oracle.  All rights reserved.

connected to target database: ORCL (DBID=1277326448)

RMAN> convert datafile '/home/oracle/geows01_hpux.dbf'
      TO PLATFORM="Linux IA (32-bit)"
      FROM PLATFORM="HP-UX (64-bit)"
      DB_FILE_NAME_CONVERT=
        '/geows01_hpux'
        '/geows01_linux';

Starting conversion at target at 05-MAY-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=61 device type=DISK
channel ORA_DISK_1: starting datafile conversion
input file name=/home/oracle/geows01_hpux.dbf
converted datafile=/home/oracle/geows01_linux.dbf
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:16
Finished conversion at target at 05-MAY-11

Importieren

Als nächstes wird die (ggfs. konvertierte) Datendatei dorthin kopiert, wo sie später liegen soll; auf den meisten Systemen dürfte das dort sein, wo auch schon die anderen Datenbankdateien liegen. Der nächste Schritt ist nun das Einspielen der Metadaten und das Einhängen der Datendatei in die Datenbank mit dem Data Pump-Werkzeug impdp.

$ impdp userid=system/oracle 
        dumpfile=geows.dmp 
        directory=homedir 
        transport_datafiles=/location/where/datafile/has/been/copied/to/geows01_linux.dbf 
        logfile=import.log

Import: Release 11.2.0.2.0 - Production on Thu May 5 14:26:10 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Produc               tion
With the Partitioning, Oracle Label Security, OLAP, Data Mining
and Real Application Testing options
Master table "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_01":  userid=system/******** dumpfil               e=geows.dmp directory=homedir transport_datafiles=/opt/oracle/oradata/orcl/geows               01.dbf logfile=import.log
Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
Processing object type TRANSPORTABLE_EXPORT/TABLE
Processing object type TRANSPORTABLE_EXPORT/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type TRANSPORTABLE_EXPORT/TABLE_STATISTICS
Processing object type TRANSPORTABLE_EXPORT/DOMAIN_INDEX/TABLE
Processing object type TRANSPORTABLE_EXPORT/DOMAIN_INDEX/INDEX
Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK
Job "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_01" successfully completed at 14:26:31

Dieser Vorgang dauert unabhängig von der Größe der übertragenen Tablespaces nur wenige Sekunden. Auch extrem große Datenmengen lassen sich so sehr einfach einspielen. Wenn impdp fertig ist, sind alle Daten im Schema vorhanden und man kann schon (fast) loslegen.

Spatial-Indizes initialisieren

Weiter oben wurde bereits geschrieben, dass die Spatial-Indizes mit SDO_UTIL.PREPARE_FOR_TTS "vorbereitet" werden müssen, wenn die Datenbankversion 11.1 oder niedriger ist. Ab Datenbankversion 11.2 ist der Schritt nicht nötig. Werden auf diese Weise "vorbereitete" Spatial-Indizes in das Zielsystem eingespielt, so müssen diese mit SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS initialisiert werden. Die Dokumentation beschreibt, wie das Kommando ausgeführt werden muss. Die Initialisierung muss auch durchgeführt werden, wenn das Quellsystem zwar eine 11.2-Datenbank ist, die Datendateien aber wegen unterschiedlicher Plattformen konvertiert werden mussten. Der Aufruf ist in beiden Fällen recht einfach:

begin
  sdo_util.initialize_indexes_for_tts;
end;

Wurden die Daten aus einer Datenbankversion "vor" 11.2 exportiert, so muss für jeden Spatial-Index noch folgendes Kommando ablaufen ...

ALTER INDEX {spatial-index-name} PARAMETERS ('CLEAR_TTS=TRUE');

Das kann recht einfach per Skript erledigt werden.

declare
  v_ddl varchar2(200);
begin
  for i in (
    select sdo.sdo_index_name
    from user_sdo_index_metadata sdo, user_tables ut 
    where ut.table_name = sdo.sdo_index_table
    and ut.tablespace_name = 'GEOWS'
  ) loop
    v_ddl := 'alter index ' || i.sdo_index_name || ' parameters (''CLEAR_TTS=TRUE'')';
    execute immediate v_ddl;
    dbms_output.put_line(v_ddl || ' executed.');
  end loop;
end;

Und dann ist der Vorgang abgeschlossen. Im Vergleich zu einem "normalen" Export und Import ist das sicherlich etwas aufwändiger und es sind mehr Dinge, auf die man achten muss ... aber die Vorteile kommen, sobald die Datenmengen etwas größer werden. Als ich vor einigen Wochen einen größeren Datenbestand (gezippt 400MB) einspielen musste, war der "klassische" Import ca. 2 Stunden beschäftigt. Mit Transportable Tablespaces wäre es eine Sache von drei Minuten gewesen. Und wenn man nun daran denkt, dass manche Datenbestände regelmäßig aktualisiert werden müssen ...

... ach ja: genau hier kann man auch von Anbietern wie NAVTEQ lernen. Denn bei regelmäßigen Aktualisierungen kommt es ja unter Umständen zur Situation, dass man das neue Tablespace gerne einspielen, die alte Version aber vielleicht gerne behalten möchte. In solchen Fällen ist es also durchaus sinnvoll, die "Versionsnummer" in den Namen des Tablespace und des Datenbankschemas aufzunehmen. NAVTEQ macht es so: Das ODF-Dataset Q3/2010 wird in den Tablespace ODF_EU_Q310 und das Datenbankschema ODF_EU_Q310 eingespielt. Für andere Schemas kann man die Daten ja dann mit GRANT- und CREATE SYNONYM-Anweisungen sichtbar machen.

SDO nach GPX konvertieren - ein Beispiel

2011-03-10T11:20:00.000+01:00

Für das Treffen der DOAG SIG Spatial nächste Woche in Potsdam bereite ich gerade meinen Vortrag zum Thema "Geodaten und XML in der Oracle-Datenbank" vor. Dabei werde ich (unter anderem) darauf eingehen, wie man mit den Mitteln der Datenbank aus einem SDO_GEOMETRY ein GPX-File erzeugen kann. Das kann interessant sein, wenn eine Geometrie eine Route repräsentiert und man diese auf ein Navigationsgerät laden möchte ...

Das Generieren der GPX-Datei ist (verwendet man die SQL/XML-Funktionen) sehr einfach. Hier ist eine PL/SQL-Funktion, die ein SDO_GEOMETRY entgegennimmt und ein GPX-File zurückgibt.

create or replace function make_gpx(
  p_name in varchar2,
  p_geom in sdo_geometry
) return xmltype is 
  v_gpx  xmltype;
  v_geom sdo_geometry;
begin
  -- CHECK FOR LINESTRING GEOMETRY
  if not p_geom.get_gtype() = 2 then   
   raise_application_error(-20000, 'CAN BUILD GPX TRACK ONLY FOR LINESTRING GEOMETRIES');
  end if;
  -- CHECK FOR LATLON GEOMETRY - TRANSFORM IF NOT 
  if p_geom.sdo_srid not in (4326, 8307) then
   v_geom := sdo_cs.transform(p_geom, 4326);
  else 
   v_geom := p_geom;
  end if;
  -- CONSTRUCT GPX XML 
  select
   xmlelement("gpx", 
    xmlattributes('http://www.topografix.com/GPX/1/1' as "xmlns"),
    xmlelement("trk",
     xmlelement("name", p_name),
     xmlelement("trkseg", 
     (
      select 
       xmlagg(
        xmlelement("trkpt",
         xmlattributes(v.y as "lat", v.x as "lon")
        )
       )
       from table(sdo_util.getvertices(v_geom)) v
      )
     )
    )
   ) into v_gpx 
  from dual;
  return v_gpx;
end;
/
sho err

Viel Spaß beim Ausprobieren ... und wer noch mehr zum Thema "Geodaten und XML" wissen möchte (und spontan ist), der kommt nächste Woche nach Potsdam zur DOAG SIG Spatial.

Treffen der DOAG SIG Spatial in Potsdam

2011-02-23T12:52:00.003+01:00

Am 15. März trifft sich die DOAG SIG Spatial in Potsdam. Auf der Agenda stehen interessante Themen wie OpenStreetMap-Daten in Oracle, Geodaten und XML, Tipps & Tricks, Netzwerke und Routing.

Und darüber hinaus steht natürlich das Kennenlernen und Networking im Vordergrund; ein wichtiger Termin der deutschsprachigen Oracle-Spatial-Community, den man sich nicht entgehen lassen sollte ...

SecureFiles - Ein kleiner Exkurs in die Niederungen der Oracle Datenbank

2011-01-27T17:03:00.000+01:00

Vor kurzem wurde ich von einem Kunden gefragt, welche Empfehlungen es in Bezug auf die DB Block Size für das Speichern von Rasterdaten als Large Objects (LOBs) gibt.
Für die Beantwortung dieser Frage ist das Wissen um Kernfunktionalität der Oracle Datenbank unabdingbar. Daher möchte ich einige Überlegungen an dieser Stelle mit anderen Interessierten teilen.
Seit Freigabe der Version 11.1 gibt es einen neuen Datentyp für die Speicherung von grossen Objekten in der Datenbank, SecureFiles genannt.
Einen sehr guten Einstieg in die Nutzung von SecureFiles gibt dieser Tipp in der deutschsprachigen Oracle DBA Community.
Darüberhinaus möchte ich auch noch auf diesen Artikel im Database Journal verweisen. Hat man sich durch die ersten beiden Kapitel gearbeitet, finden sich einige Hinweise auf u.a. relevante DB Parameter oder Tabellen-Eigenschaften.
Wichtig ist zunächst einmal zu wissen, dass bis Version 11 für LOBs nicht so sehr die DB Block Size wichtig ist - hier braucht man eigentlich nur darauf zu achten, dass diese möchst nicht grösser als das LOB selbst ist - , sondern die Grösse der sogenannten CHUNKs (zu deutsch: Brocken, Klumpen, großes Stück).
Seit 11.1 und SecureFiles hat die DB Block Size nur minimalen Einfluss auf die Performanz und auch die CHUNK Grösse muss nicht explizit angegeben werden. Die DB übernimmt es, nach bestem "Wissen und Gewissen" die optimale CHUNK Grösse zu bestimmen. Die variiert zwischen der DB Block Size (Minimum) und 64 MB (Maximum). Unsere DB EntwicklerInnen nennen das "Super Chunk".
Möchte man trotzdem Einfluss nehmen, so bleibt die Möglichkeit, das Minimum durch Setzen einer entsprechenden DB Block Size pro Tablespace zu regulieren.
Das ist auch schon das Stichwort für einen anderen Hinweis: In jedem Falle empfehle ich, einen eigenen Tablespace für LOBs vorzusehen, ggf. mehrere für unterschiedliche Arten von LOBs oder verschiedene Datenstände dieser.
Dann gibt es beim Anlegen von Tablespaces den wichtigen Begriff der Extents, bei denen es sich um physisch zusammenhängende Speicherbereiche handelt, in welche die Datenbankobjekte gespeichert werden. Je näher die Daten in zusammenhängenden Plattenbereichen liegen, umso geringer sind natürlich die Zugriffszeiten beim Lesen.
Eine Empfehlung an dieser Stelle ist also, die Grösse der Extents so zu anzugeben, dass möglichst wenige solcher während eines Ladevorgangs neu angelegt werden müssen.
Wem es generell auf Geschwindigkeit beim Ladevorgang ankommt, sollte sich überlegen, die Daten mit NOLOGGING zu laden, um das Mitschreiben von ReDo-Informationen zu reduzieren.
Nach dem Laden kann man wieder auf LOGGING setzen und am Besten gleich noch ein Online-Backup ziehen.

ALTER TABLE my_lob_tab NOLOGGING;

ALTER TABLE my_lob_tab MODIFY (lob_col CLOB)
  LOB(lob_col) STORE AS SECUREFILE (
    NOCACHE NOLOGGING       -- NOCACHE muss zusammen mit NOLOGGING gesetzt werden
  );

... 

ALTER TABLE my_lob_tab MODIFY LOB (lob_col) (CACHE);
ALTER TABLE my_lob_tab LOGGING;

Weitere Hinweise dazu finden sich in der Online-Dokumentation SecureFiles and Large Objects Developer´s Guide.
Was ist noch wichtig?
Datenbank-Objekte werden als sogenannte Segmente gespeichert. Es gibt einige unterschiedliche davon, z.B. Tabellen-, Index- oder auch LOB-Segmente.
Letztere werden standardmässig erzeugt, wenn die Grösse des LOBs > 4000 Bytes ist. Das nennt man dann Outline-Speicherung. Das Gegenteil davon Inline speichert die ganze Tabellenzeile inklusive LOB in einem Tabellen-Segment und ist das Standardverhalten bei LOBs < 4000 Bytes.
Will man ausschliesslich Outline speichern, z.B. um LOBs und die sonstigen (relationalen) Daten in verschiedene Segmente (möglicherweise wegen unterschiedlicher Tablespaces) aufzuteilen, so kann man in der Storage-Klausel der Tabellendefinition DISABLE STORAGE IN ROW spezifizieren.
Aber Achtung: Das muss man am zum Zeitpunkt des Anlegens der Tabelle bereits tun, da es sich nachträlglich nicht ändern lässt.

Und was hat das alles jetzt eigentlich mit SDO_GEOMETRY, SDO_GEORASTER zu tun, den Oracle Objekttypen für Vektor- und Rasterdaten zu tun? Beide und dazu auch SDO_PC (für Point Clouds) können SecureFiles verwenden. Bei einer Rasterdatentabelle sieht das dann z.B. so aus:

CREATE TABLE city_images_rdt OF SDO_RASTER (
  PRIMARY KEY (
    rasterID, 
    pyramidLevel, 
    bandBlockNumber,
    rowBlockNumber, 
    columnBlockNumber))
  TABLESPACE raster_im_tbs
  LOB(rasterBlock) STORE AS SECUREFILE lobseg(
    NOCACHE NOLOGGING)
/

Bei Vektordaten werden sowohl Stützpunkte (SDO_ORDINATE_ARRAY) als auch SDO_ELEM_INFO in VARRAYs gespeichert. Und auch diese können mit der Storage-Klausel STORE AS SECUREFILE angegeben werden. Die Syntax sieht beispielhaft so aus:

CREATE TABLE my_geom_tab (
  feature_name VARCHAR2(4000),
  geometry     SDO_GEOMETRY
)
VARRAY geometry.SDO_ORDINATES STORE AS SECUREFILE lob geom_ord
VARRAY geometry.SDO_ELEM_INFO STORE AS SECUREFILE lob geom_elem
/

Bevor dieser Blog-Eintrag jetzt zu lang wird und niemand mehr Lust hat, ihn bis zum Ende zu lesen, hebe ich mir das Thema Komprimieren von den als SecureFiles gespeicherten Stützpunkten für einen neuen Eintrag auf.

Hands On Workshop "Oracle Spatial & MapViewer" am 3. Februar 2011

2011-01-10T17:54:00.000+01:00

Es gibt eine Neuauflage des Hands On Workshops "Oracle Spatial & MAPS" ausgerichtet vom Oracle-Partner CISS TDI.
Der Kurs richtet sich an Kunden von Oracle und der CISS TDI, die erste Erfahrungen mit Oracle Locator und Spatial gesammelt haben und ihre Kenntnisse erweitern bzw. vertiefen wollen.

Termin ist der 3. Februar 2011.
Ort: CISS TDI GmbH, Barbarossastr. 36, 53489 Sinzig

Referenten:

Markus Lindner, CISS TDI GmbH

Carsten Czarski, Oracle Deutschland GmbH Preis: 300,- € pro Person
In der Kursgebühr sind Seminarunterlagen, Pausengetränke und Mittagssnack inbegriffen.

Kursbeschreibung:
Zu einer funktionierenden GDI gehört die zentrale Bereitstellung vor- bzw. aufbereiteter Daten zum Zwecke der Analyse, Auswertung und der Publikation von Geodaten. Der Gedanke, Daten nicht aus operativen Systemen direkt zu publizieren, sondern zunächst in einem Warehouse zu konsolidieren und vorzuhalten ist nicht neu. Ermöglicht dieser Ansatz doch, gepaart mit einer OGC-konformen offenen Datenhaltung eine globale Sicht auf die verschiedenen Datenbestände, die im Rahmen einer GDI zusammen kommen können. INSPIRE und ALKIS-Nutzung (Auskunfts- und Präsentationskomponente APK) können als reale Beispiele für einen solchen Ansatz gelten.
Lernen Sie, wie man Geodatenstrukturen anlegt, Geodaten in eine Oracle Datenbank mittels ETL am Beispiel von CITRA sinnvoll einbringt und auswertet. Vermittelt werden Auswertungen durch SQL, mit Oracle Maps und beispielhaft an verschiedenen GIS.
Lernen Sie, wie man Geodaten mit Oracle Maps schnell und einfach im Browser visualisieren kann - mit einer Oberfläche, die jeder aus dem Internet kennt. Erfahren Sie weiterhin, wie Sie externe Kartendienste im Hintergrund verwenden und dabei die Fachinformationen (Features Of Interest) aus Ihrer lokalen Datenbank nutzen können. Im Ausblick lernen Sie in einem Überblick die umfassenden Möglichkeiten von Oracle Spatial, z.B. Georaster, Geocoding und Topologie und die Auswertemöglichkeiten mit Apex kennen.

Voraussetzungen:

Für die Arbeit im Workshop ist ein eigener (W-LAN-fähiger) Laptop mit installiertem Web-Browser erforderlich

Grundkenntnisse in Oracle Locator/Spatial Zum Nachlesen und für die Anmeldung bitte auf diesen Link klicken.

Deadline für Oracle Spatial User Conference 2011

2011-01-07T12:38:00.000+01:00

Für die Oracle Spatial User Conference können noch Vorträge eingereicht bzw. Projekte für den Spatial Award nominiert werden. Stichtag dafür ist Montag, der 10. Januar 2011.
Wie im Blog schon angekündigt, findet die Konferenz am 19. Mai 2011 in Washington, DC statt.
Im Übrigen können Preisnominierungen auf von Oracle-Mitarbeiterinnen und Mitarbeitern eingereicht werden.
Für Richtlinien finden sich nachfolgende Informationen (auf Englisch):

Submission Guideline

Abstract Submission Form

Award Nomination Guidelines and Form

Was und wer wird prämiert? Diese Fragen beantwortet am besten ein Auszug aus dem Guideline Dokument, den ich hier der Einfachheit halber reinkopiere.

The annual Oracle Spatial Excellence Awards recognize top customers and partners for significant achievements using Oracle's spatial technologies. Awards are given to organizations and individuals in the categories below:

Innovator: Demonstrate novel, new uses of Oracle's spatial technologies not seen previously in the marketplace, to solve business problems. The innovation should be of interest and relevance to peers in the industry.

Integrated Enterprise:

Education and Research:

Partnership:

The public is invited to submit nominations for the awards. Organizations or individuals may selfnominate or accept a nomination by another organization or individual. Candidates worldwide are eligible for consideration.

Neue Version des GeoRaptor für den SQL Developer verfügbar

2011-01-03T11:28:00.001+01:00

Es geht immer weiter mit dem GeoRaptor für das kostenfreie DB-Entwicklungswerkzeug Oracle SQL Developer.
Die Autoren Holger Laebe, Matik Petek, Olaf Iseeger und Simon Greener haben über die Weihnachtsfeiertage auf SourceForge.net das Release 2.1.4 zum Download bereitgestellt.
Details bezüglich der neuen Features sind für Release 2.1.4 hier bzw. für das vorherige Release 2.1.2 hier zu finden.

Alles Gute für das Jahr 2011 ...

2011-01-03T09:49:00.000+01:00

... wünschen wir unseren Blog-Leserinnen und Lesern, allen aktuellen und zukünftigen Oracle Kunden und Partnern.

Ihr Oracle Spatial Team

Locator ich noch oder Spatial ich schon?

2010-12-01T14:46:00.000+01:00

Diese Frage stellen sich unsere Kunden immer mal wieder. Und sie zu beantworten, ist zugegebenermassen nicht so ganz einfach.
Deshalb wollen wir hier ein paar Hilfestellungen geben.

Da wäre zunächst einmal die grobe Einteilung in 2D-Vektordaten (Locator) und alles andere (Spatial), wie 3D-Vektordaten, Rasterdaten, Netzwerkdatenmodell, Topologien, Geokodierung, Lineare Bezugssysteme, Routing, Geodienste (ausser WMS), etc.

Was die 2D-Vektordaten betrifft, muss man dann noch mal genauer auf die von Locator unterstützten Features schauen. Diese sind im Detail in Tabelle B-1 im Oracle Spatial Developer’s Guide beschrieben. Was dort nicht aufgeführt ist, statt dessen aber in Tabelle B-2, ist Spatial.

Darüberhinaus kann man auch noch die sogenannte Feature Usage Statistics zu Rate ziehen. Nutzer/-innen mit DBA-Rechten können sich diese wie folgt anzeigen lassen:

select * 
from   dba_feature_usage_statistics 
where  lower(name) like '%locator%' or 
       lower(name) like '%spatial%';

Seit 11gR2 werden Locator und Spatial darin gesondert ausgewiesen.

Lauter kleine Helferlein

2010-11-30T10:53:00.001+01:00

Heute soll es darum gehen, Geometrien, die nicht Simple Feature-konform sind, soweit möglich zu korrigieren.

Für eine solche Korrektur steht seit 11gR1 die Funktion RECTIFY_GEOMETRY im Package SDO_UTIL bereit, welche die korrigierte (rektifizierte) Geometrie zurückliefert.

Ein Blick in die Oracle Spatial Online-Dokumentation verrät dabei, welche Fehler korrigierbar sind:

doppelte Stützpunkte (bezogen auf die Toleranz)
sich selbst schneidende Polygone
falsche Orientierung von innerem oder/und äusseren Ring(en) eines Polygons

Dort findet sich ebenso das Format beschrieben.

SDO_UTIL.RECTIFY_GEOMETRY(
  geom      IN SDO_GEOMETRY,
  tolerance IN NUMBER
) RETURN SDO_GEOMETRY;

Wie kann man nun diese Funktion in Anwendung bringen? Schauen wir uns das einfach mal genauer an.

Zunächst wird eine Tabelle angelegt, in welcher alle fehlerhaften Geometrien registriert werden sollen.

drop table geometry_errors purge;

-- Fehlertabelle anlegen
create table geometry_errors (
  table_name      varchar2(30),
  column_name     varchar2(30),
  obj_rowid       rowid,
  geometry        sdo_geometry,
  tolerance       number,
  error_code      char(5),
  error_message   varchar2(256),
  error_context   varchar2(256),
  is_fixed        number(1) default 0
);

Die eigentliche Prozedur zum Überprüfen der Geometrien, kann dann wie nachfolgend aussehen. Die problematischen Geometrien darunter werden in die Fehlertabelle übernommen.

-- Prozedur zum Prüfen auf invalide Geometrien im gesamten Schema
-- Achtung: Kann einige Zeit in Anspruch nehmen!
declare
  DEFAULT_TOLERANCE   number := 0.0000005;
  COMMIT_FREQUENCY    number := 100;
  geom_cursor         sys_refcursor;
  v_diminfo           sdo_dim_array;
  v_srid              number;
  v_tolerance         number;
  v_rowid             rowid;
  v_geometry          sdo_geometry;
  v_num_rows          number;
  v_num_errors        number;
  v_error_code        char(5);
  v_error_message     varchar2(256);
  v_error_context     varchar2(256);
  v_status            varchar2(256);
begin

  -- Alle Tabellen mit SDO_GEOMETRY Spalten prozessieren
  for t in (
    select table_name, column_name
    from   user_tab_columns
    where  data_type = 'SDO_GEOMETRY'
    order by table_name, column_name )
  loop
  
    -- Lies Toleranz aus den Metadaten
    begin
      select diminfo, srid into v_diminfo, v_srid
      from user_sdo_geom_metadata
      where table_name = t.table_name
        and column_name = t.column_name;
    exception
      when no_data_found then
        v_diminfo := null;
        v_srid := null;
    end;
 
    -- Bei fehlenden Metadaten, Default-Toleranz annehmen
    if v_diminfo is null then
      v_tolerance := DEFAULT_TOLERANCE;
    else
      v_tolerance := v_diminfo(1).sdo_tolerance;
    end if;
 
    -- Geometrien prozessieren
    v_num_rows := 0;
    v_num_errors := 0;

    open geom_cursor for
      'select rowid,' || t.column_name || ' from ' || t.table_name;
    loop
      v_status := NULL;
   
      -- Hole Geometrie
      fetch geom_cursor into v_rowid, v_geometry;
        exit when geom_cursor%notfound;
      v_num_rows := v_num_rows + 1;
   
      -- Validiere Geometry
      v_status := sdo_geom.validate_geometry_with_context (v_geometry, v_tolerance);
   
      -- Wenn Fehler, dann protokollieren
      if v_status <> 'TRUE' then
   
        -- Fehler hochzählen
        v_num_errors := v_num_errors + 1;
  
        -- Format the error message
        if length(v_status) >= 5 then
          v_error_code := substr(v_status, 1, 5);
          v_error_message := sqlerrm(-v_error_code);
          v_error_context := substr(v_status,7);
        else
          v_error_code := v_status;
          v_error_message := null;
          v_error_context := null;
        end if;
  
        -- Fehler wegschreiben
        insert into geometry_errors (
          table_name,
          column_name,
          obj_rowid,
          geometry,
          tolerance,
          error_code,
          error_message,
          error_context
        )
        values (
          t.table_name,
          t.column_name,
          v_rowid,
          v_geometry,
          v_tolerance,
          v_error_code,
          v_error_message,
          v_error_context
        );
      end if;
   
      -- Commit entsprechend COMMIT_FREQUENCY
      if mod(v_num_rows,COMMIT_FREQUENCY) = 0 then
        commit;
      end if;
    end loop;
  end loop;
  
  -- Finales Commit
  commit;
end;
/

Zu beachten ist dabei, dass das Ausführen der Prozedur eine Weile in Anspruch nehmen kann, je nach Anzahl der zu überprüfenden Geometrien.

Bevor es an die eigentliche Korrektur geht, schauen wir uns zunächst die Fehlertabelle genauer an.

-- Fehler pro Tabelle, Error Code
select table_name, error_code, error_message, count(*)
from geometry_errors
group by table_name, error_code, error_message 
order by table_name, error_code;

-- Fehler pro Error Code, Tabelle
select error_code, error_message, table_name, count(*)
from geometry_errors
group by error_code, error_message, table_name
order by error_code, table_name;

-- Fehlerdetails
select table_name, obj_rowid, is_fixed, error_message, error_context
from geometry_errors
where is_fixed = 0
order by table_name, obj_rowid;

Für die Korrektur wird nun die Funktion SDO_UTIL.RECTIFY_GEOMETRY eingesetzt.

-- Prozedur zum Korrigieren der Geometrien
declare
  -- Fehlerbehandlung für nicht korrigierbare Geometrien
  -- "ORA-13199: the given geometry cannot be rectified"
  cannot_rectify exception;
  pragma exception_init(cannot_rectify, -13199);
  v_geometry_fixed sdo_geometry;

begin
  -- Invalide Geometrien prozessieren
  for e in (
    select rowid, table_name, column_name, obj_rowid, tolerance, geometry
    from geometry_errors
    where is_fixed = 0
    order by table_name, column_name
  )
  loop
    -- Wenn möglich, Geometrie korrigieren mit SDO_UTIL.RECTIFY_GEOMETRY. 
    -- Andernfalls:
    --   In 11.1.0.6: Funktion gibt NULL zurück
    --   In 11.1.0.7 und 11.2: Funktion wirft ORA-13199 Fehler
    begin
      v_geometry_fixed := sdo_util.rectify_geometry (e.geometry, e.tolerance);
    exception
      when cannot_rectify then
        v_geometry_fixed := null;
    end;

    if v_geometry_fixed is not null then
      -- Korrigiere Geometrie
      execute immediate 'update ' || e.table_name || ' set '|| e.column_name || ' = :g where rowid = :r'
        using v_geometry_fixed, e.obj_rowid;

      -- Kennzeichne korrigierte Geometrien in Fehlertabelle mit is_fixed = 1
      update geometry_errors set is_fixed = 1 where rowid = e.rowid;
      -- Alternativ ist auch DELETE möglich
      -- delete from geometry_error where rowid = e.rowid;
    end if;

  end loop;
end;
/

Was wurde korrgiert? Was nicht? Das Ergebnis kann am Ende in der Fehlertabelle überprüft werden.

-- Fehler nach Tabelle, Korrekturstatus und Error Code
select table_name, is_fixed, error_code, error_message, count(*)
from geometry_errors
group by table_name, is_fixed, error_code, error_message 
order by table_name, is_fixed, error_code;

-- Fehler nach Korrekturstatus und Error Code
select is_fixed, error_code, error_message, count(*)
from geometry_errors
group by is_fixed, error_code, error_message
order by is_fixed, error_code;

-- Details
select table_name, obj_rowid, is_fixed, error_message, error_context
from geometry_errors
order by is_fixed, table_name, obj_rowid;

Möglicherweise konnten nicht alle fehlerhaften Geometrien auf diese Weise korrigiert werden, aber ein erster Schritt in Richtung Qualitätsverbesserung ist getan.
Wer die Fehlertabelle nach erfolgter Korrektur nicht mehr benötigt, sollte übrigens nicht vergessen, diese wieder zu entfernen.

drop table geometry_errors purge;

GPX-Dateien nach SDO_GEOMETRY umwandeln

2010-11-22T10:32:00.004+01:00

Jüngst habe ich für einen Kollegen einen GPS-Track in die Datenbank geladen. Ich hatte eine .gpx-Datei, die in etwa so aussieht ...

<gpx xmlns="http://www.topografix.com/GPX/1/1" tc2=" ...
   <trk>
       <name>2010-11-16T03:46:55Z</name>
       <trkseg>
           <trkpt lat="51.4799802" lon="7.9678522">
               <ele>270.7484131</ele>
               <time>2010-11-16T03:46:55Z</time>
           </trkpt>
           <trkpt lat="51.4799436" lon="7.9678679">
               <ele>264.0192871</ele>
               <time>2010-11-16T03:47:06Z</time>
           </trkpt>
           <trkpt lat="51.4797696" lon="7.9681059">
               <ele>264.4998779</ele>
               <time>2010-11-16T03:47:12Z</time>
           </trkpt>
           <trkpt lat="51.4797497" lon="7.9681919">
               <ele>264.9805908</ele>
               <time>2010-11-16T03:47:14Z</time>
           </trkpt>

Zunächst hatte ich ein wenig nach Converter-Software gegoogelt, wurde jedoch nicht so recht fündig (komische Lizenzbedingungen, keine Konvertierung nach GML oder KML, sondern nur in andere Formate). Da es aber um eine einfach zu verstehende XML-Datei geht, beschloß ich, mir einfach selbst eine Funktion zu schreiben, welche die Arbeit erledigt. Und hier ist sie ...

create or replace function convert_gpx_to_sdo(
 p_gpxfile in xmltype,
 p_lrs     in number default 0
) return sdo_geometry is
 v_ordinates sdo_ordinate_array := sdo_ordinate_array();
 v_gtype     number;

 v_cnt       pls_integer := 1;

 v_startts   timestamp;
 v_interval  interval day(9) to second;

 c_gpxns     varchar2(200) := 'xmlns="http://www.topografix.com/GPX/1/1"';
begin
 if p_lrs = 1 then
   v_gtype := 3302;
 else
   v_gtype := 2002;
 end if;

 for tp in (
   select
     extractvalue(value(tp), '/trkpt/@lon', c_gpxns) x,
     extractvalue(value(tp), '/trkpt/@lat', c_gpxns) y,
     extractvalue(value(tp), '/trkpt/time', c_gpxns) m
   from table(xmlsequence(extract(p_gpxfile, '//trkpt', c_gpxns))) tp
 ) loop
   if v_cnt = 1 then
     v_startts := to_timestamp(tp.m, 'YYYY-MM-DD"T"HH24:MI:SS"Z"');
   end if;
   if p_lrs = 1 then
     v_ordinates.extend(3);
   else
     v_ordinates.extend(2);
   end if;
   v_ordinates(v_cnt) := tp.x;
   v_cnt := v_cnt + 1;
   v_ordinates(v_cnt) := tp.y;
   v_cnt := v_cnt + 1;
   if p_lrs = 1 then
     v_interval := to_timestamp(tp.m,  'YYYY-MM-DD"T"HH24:MI:SS"Z"') - v_startts;
     v_ordinates(v_cnt) :=
      extract(MINUTE from v_interval) +
      extract(HOUR from v_interval) * 60 +
      extract(SECOND from v_interval) / 60;
     v_cnt := v_cnt + 1;
    end if;
 end loop;

 return sdo_geometry(v_gtype, 8307, null, sdo_elem_info_array(1,2,1), v_ordinates);
end convert_gpx_to_sdo;
/
sho err

Die Funktion nimmt das GPX-File (XMLTYPE) als ersten Parameter entgegen. Der zweite Parameter gibt an, ob eine Linear Referencing-Geometrie zurückgegeben werden soll. Wenn ja, werden die Measures in Minuten gespeichert. Gebt hier entweder "1" oder "0" an ... Man könnte hier sicherlich noch mehr machen: die GPX-Dateien enthalten eine Höhenangabe - man könnte also auch 3D-Geometrien bauen ...

Vielleicht jemand diese erste Version brauchen - viel Spaß damit!

Views mit SDO_GEOMETRY

2010-11-12T14:08:00.001+01:00

Auch für Geodaten-Tabellen werden recht häufig Views generiert. Daten aus verschiedenen Tabellen stehen damit quasi als "eine Tabelle" bereit. Und man kann mit den Views auch sehr gut arbeiten. Nur lassen sich die Views von vielen GIS-Werkzeugen und auch vom Oracle MapBuilder (das Werkzeug zum Einrichten der Kartendefinitionen für Oracle MAPS) nicht verwenden - die Auswahldialoge zeigen sie einfach nicht an.

Nun befindet sich auf der View zwar kein Spatial-Index, aber das ist ja auch richtig so; auf eine View kann kein Index gelegt werden. Der Grund ist die Spatial-Metadaten-View USER_SDO_GEOM_METADATA, die von all diesen Werkzeugen ausgelesen wird und meist Grundlage der Auswahllisten ist.

Die Lösung ist also einfach: Die View wird, wie die zugrundeliegende Spatial-Tabelle in USER_SDO_GEOM_METADATA eingetragen. Nehmt einfach dieses SQL hier als Vorlage.

insert into user_sdo_geom_metadata values (
  '{TABLE/VIEW NAME}',
  '{GEOM_COL_NAME}',
  sdo_dim_array(
   sdo_dim_element('X', {xmin}, {xmax}, {tolerance}),
   sdo_dim_element('Y', {ymin}, {ymax}, {tolerance})
  ),
  {SRID}
)
/

Einen Index könnt Ihr danach immer noch nicht anlegen - aber das braucht Ihr auch nicht - der View sollte nun in eurem GIS-Werkzeug oder im Oracle MapBuilder sicht- und auswählbar sein.

INSIDE, TOUCH ... oder etwa doch anders

2010-10-16T16:05:00.003+02:00

Wie kann ich eigentlich herausfinden, in welcher topologischen Beziehung sich 2 Objekte zueinander definden?

Die Funktion RELATE im Package SDO_GEOM liefert im Ergebnis die Lagebeziehung zwischen 2 Objekten.

select
  c2.feature_name,
  sdo_geom.relate(
    c2.geometry,
    'determine',    -- Maskierungsparameter
    c1.geometry, 
    0.05 ) topo_rel
from 
  m_admin_area1 c1, 
  m_admin_area1 c2
where 
  c1.feature_name = 'GERMANY';

Der Wert DETERMINE für den Maskierungsparameter ermittelt dabei diejenige Lagebeziehung zwischen 2 Objekten, welche der Realität am meisten entspricht.
Im Falle der obigen Abfrage wird anhand des kostenfrei bereitgestellten NAVTEQ Beispieldatensets für Oracle die Lagebeziehung zwischen Deutschland und allen anderen Ländern ermittelt.

Wird übrigens als Wert für den Maskierungsparameter ANYINTERACT angegeben, gibt die Funktion TRUE zurück für alle Lagebeziehungen, die ungleich DISJOINT sind.

SQL Developer 3.0 ist draußen: Mit Spatial-Unterstützung!

2010-10-14T16:35:00.004+02:00

Seit dem 13. Oktober ist das Early Adopter-Release des SQL Developer 3.0 draußen. Das besondere daran ist, dass nun eine Unterstützung für Spatial drin ist: out-of-the-box und ohne GeoRaptor. Hier ein Screenshot. Ihr sehr, dass es nun eine Map-Ansicht von Geodaten gibt und dass zu einer Tabelle (über den Eintrag Räumlich im Kontextmenü) Spatial-Bezogene Operationen angeboten werden.

Der SQL Developer wird mit Sicherheit nicht mit einem Spatial Commander oder einem ähnlichen GIS-Werkzeug konkurrieren können, aber die Basisoperationen (sprich: was ein SQL bzw. PLSQL-Entwickler braucht) sind nun out-of-the-box drin. Und das ist gut!

APEX und die Frage: Wo sind meine Metadaten geblieben?

2010-09-30T00:35:00.001+02:00

Wer schon mal eine kleine oder auch größere APEX-Geo-Anwendung erstellt hat, wird die nachfolgend beschriebene Situation vielleicht schon mal erlebt haben.

Jede Tabelle mit einer SDO_GEOMETRY-Spalte benötigt eine Registrierung in den SDO-Metadaten der Oracle Datenbank. Das ist ein INSERT in die Nutzer-bezogene View USER_SDO_GEOM_METADATA und kann z.B. so aussehen:

SQL> insert into user_sdo_geom_metadata (
  table_name, 
  column_name, 
  diminfo,
  srid) 
values (
  'GEOTAB',
  'geometry',
  sdo_dim_array(sdo_dim_element('X',-180,180,0.005),
  sdo_dim_element('Y',-90,90,0.005)),
  8307);

Entwickelt man eine Anwendung in APEX und benutzt für das Registrieren der SDO_GEOMETRY Spalte in den Metadaten den SQL Workshop, dann läuft das soweit auch ohne Probleme durch.

Dann wird ordentlicherweise auch gleich noch der Spatial Index angelegt und schon erscheint die Fehlermeldung ORA-00942: table or view does not exist.

Ein kurzes

SQL> select * from user_sdo_geom_metadata where table_name = 'GEOTAB';

bringt kein Ergebnis zurück.

Was ist passiert? Wo ist der Eintrag in die Metadaten geblieben?
Mit DBA-Rechten ist es recht einfach, in der entsprechenden Tabelle des Nutzers MDSYS nachzuschauen.

SQL> select * from mdsys.sdo_geom_metadata_table;

Dort ist in der Spalte SDO_OWNER dann anstatt des erwarteten Nutzers (hier im Beispiel SPATIAL) je nach dem von APEX verwendeten Web Listener entweder ANONYMOUS, APEX_PUBLIC_USER oder HTMLDB_PUBLIC_USER zu finden. Das ist der Nutzername der APEX-Session, in dessen Schema dann auch die SDO_GEOMETRY Metadaten registriert werden.

Wie kann das jetzt bereinigt werden?
Bitten Sie Ihren DBA, Ihrem Nutzer UPDATE-Rechte für die MDSYS-Tabelle SDO_GEOM_METADATA_TABLE zuzuweisen.

SQL> grant update on mdsys.sdo_geom_metadata_table;

Dann ändern Sie den SDO_OWNER-Eintrag wie folgt ab:

SQL> update MDSYS.SDO_GEOM_METADATA_TABLE
  set sdo_owner='SPATIAL'
  where sdo_table_name = 'GEOTAB' and sdo_owner = 'ANONYMOUS';

Wenn Sie jetzt die Metadaten überprüfen, sollte nunmehr alles im grünen Bereich sein.

Gauss-Krüger: EPSG oder nicht EPSG: Das ist hier die Frage!

2010-09-21T16:22:00.001+02:00

Seit Oracle10g Release 2 unterstützt die Oracle-Datenbank die EPSG-Systematik für Koordinatensysteme. Die Projektion Gauss-Krüger Zone 3 steht damit gleich zweimal bereit:

als "klassische" Oracle-SRID 82027
im EPSG-Standard als Code 31467

SQL> select srid,cs_name from cs_srs where srid in (31467, 82027)

      SRID CS_NAME
---------- ----------------------------------------
     31467 DHDN / Gauss-Kruger zone 3
     82027 GK Zone 3 (DHDN)

Man könnte auf den Gedanken kommen, dass es nun egal ist, welchen Code man verwendet. Aber das ist es leider nicht. Zwischen dem nach EPSG standardisierten System 31467 und der "Oracle-Version" gibt es Unterschiede ... und die möchte ich in diesem Blog Posting herausarbeiten.

Zunächst nehme ich die Koordinate von Oracle in München (mit dem Oracle-Geocoder, versteht sich) und rechne die nach EPSG:31467 um.

select sdo_cs.transform(
  sdo_geometry(2001, 8307, sdo_point_type(11.536734, 48.1800773, null), null, null), 
  31467
) transformed from dual;

TRANSFORMED
------------------------------------------------------------------------------------
SDO_GEOMETRY(2001, 31467, SDO_POINT_TYPE(3688714,69, 5341125,2, NULL), NULL, NULL)

Dies ist die absolut korrekte Koordinate im Koordinatensystem EPSG:31467. Man könnte aber auf den Gedanken kommen, diese mit der ID 82027 in die Datenbank zu speichern ... wenn's das gleiche Koordinatensystem ist, wäre das ja egal ...

Also rechnen wir die Koordinate wieder in WGS84 zurück und zwar einmal mit der SRID 31467 und einmal mit 82027.

select sdo_cs.transform(
  SDO_GEOMETRY(2001, 31467, SDO_POINT_TYPE(3688714.69, 5341125.2, NULL), NULL, NULL ),
  8307
) transformed from dual;

TRANSFORMED
------------------------------------------------------------------------------------
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(11,5367341, 48,1800773, NULL), NULL, NULL)

select sdo_cs.transform(
  SDO_GEOMETRY(2001, 82027, SDO_POINT_TYPE(3688714.69, 5341125.2, NULL), NULL, NULL ),
  8307
) from dual;

TRANSFORMED
------------------------------------------------------------------------------------
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(11,5391267, 48,180154, NULL), NULL, NULL)

Und man sieht, dass es nicht das gleiche ist. Wenn man die Well Known Texts vergleicht, lässt sich auch feststellen, dass es in den Parametern ein paar Unterschiede gibt. Die Abweichung liegt meist im Bereich von ca. 100 bis 200 Metern.

select sdo_geom.sdo_distance(
 sdo_cs.transform(
  SDO_GEOMETRY(2001, 31467, SDO_POINT_TYPE(3688714.69, 5341125.2, NULL), NULL, NULL ),
  8307
 ),
 sdo_cs.transform(
  SDO_GEOMETRY(2001, 82027, SDO_POINT_TYPE(3688714.69, 5341125.2, NULL), NULL, NULL ),
  8307
 ),
 1
) distanz from dual;

DISTANZ
-------------
   178,128988

Und was bedeutet das? Zuerstmal alles kein Problem! Man muss es, wenn man GK3-Koordinaten (bspw. aus Shapefiles) in die Datenbank lädt, nur beachten. Stellt man beim Betrachten der Daten Abweichungen im Bereich von 100 bis 200 Metern fest, sollte man die andere GK3-SRID versuchen. Meistens liegt man mit der neueren EPSG-Nummer 31467 richtig. Aber ich habe auch schon Fälle erlebt, in denen die 82027 genommen werden musste.

Rechnet man eine Geometrie von 82027 nach 31467 um, kommen (folgerichtig) auch nicht die gleichen Koordinaten heraus.

SQL> select sdo_cs.transform(
  2    SDO_GEOMETRY(2001, 82027, SDO_POINT_TYPE(3688714.69, 5341125.2, NULL), NULL, NULL ),
  3    31467
  4  ) TRANSFORMED from dual;

TRANSFORMED
-----------------------------------------------------------------------------------
SDO_GEOMETRY(2001, 31467, SDO_POINT_TYPE(3688892,31, 5341139,61, NULL), NULL, NULL)

Für die anderen in Deutschland gebräuchlichen Gauss-Krüger Projektionen gilt das analog.

SQL> select srid,cs_name from cs_srs where srid in (31466, 82015);

      SRID CS_NAME
---------- ----------------------------------------
     31466 DHDN / Gauss-Kruger zone 2
     82015 GK Zone 2 (DHDN)

SQL> select srid,cs_name from cs_srs where srid in (31468, 82032);

      SRID CS_NAME
---------- ----------------------------------------
     31468 DHDN / Gauss-Kruger zone 4
     82032 GK Zone 4 (DHDN)

Oracle Partner CISS TDI erweitert seine CITRA-Schnittstellenpalette

2010-09-20T23:07:00.000+02:00

Der Oracle Partner CISS TDI GmbH hat seine CITRA-Schnittstellenpalette um einen Reader für das OpenStreetMap-Daten im XML-Format erweitert.
Die Schnittstelle beinhaltet

eine Konfiguration für das Oracle Network Datenmodell sowie
eine sehr gut ausgestalteten Übersichtskarte in Oracle Spatial zur Verwendung im Oracle Fusion Middleware MapViewer

Mit dieser Schnittstelle schafft CISS TDI die Möglichkeit, OpenStreetMap-Daten nativ mit Oracle Spatial zu verwenden.

Weitere Informationen sind hier zu finden.

SDO_GEOMETRY Viewer für Oracle SQL Developer

2010-09-20T22:47:00.001+02:00

Für das kostenfreie DB-Entwicklungs- und Administrationswerkzeug SQL Developer gibt es eine Erweiterung, welche mit als SDO_GEOMETRY gespeicherten 2-dimensionalen Geometriedaten umgehen kann.

Der sogenannte GeoRaptor ist ein Open-Source-Projekt auf sourceforge.net.

Neben den eigentlichen "Features", wie z.B.

Kontextmenü für die Tabellen mit SDO_GEOMETRY-Spalte
Viewer mit den typischen Funktionen, wie Zoom, Rectangle Zoom, Pan, Copy sowie der Möglichkeit, die Signaturen der ausgewählten Geometrien festzulegen
SQL Code-Snippets

können auf den Projektseiten auch gleich neue Features angefragt bzw. Probleme mit vorhandenen berichtet werden.

Hinweise zur Installation gibt es hier.

Und wie sieht der Viewer in Aktion aus?

Bemerkung: Für die Darstellung wurden Daten aus dem frei für Oracle verfügbaren Datenset von NAVTEQ verwendet. Das ist zu finden unter Oracle Spatial Partners′ Data.

Oracle OpenWorld 2010 demnächst

2010-09-13T22:45:00.001+02:00

Vom 19.-23. September findet in San Francisco die Oracle OpenWorld 2010 statt.

Unter den vielen verschiedenen Themenbereichen wird auch ein Fokus auf "Oracle Spatial & Oracle MapViewer" gesetzt. Alle Veranstaltungen dazu sind hier zu finden.

De-aggregieren zusammengesetzter Geometrien

2010-09-08T09:36:00.026+02:00

Aus einer zusammengesetzten Geometrie (Multipolygon, welches mehrere Elemente, optional auch Subelemente/Ringe enthält) können mit Hilfe der Funktion EXTRACT einzelne Elemente herausgezogen werden.

Diese Funktion für 2D-Vektordaten, sowie analog EXTRACT3D für 3D-Vektordaten, steht im PL/SQL Package SDO_UTIL zur Verfügung. Letztere Funktion gibt es allerdings erst seit der DB Version 11.1 im Package.

Das Format ist wie folgt kurz beschrieben:
sdo_util.extract (
  geometry IN SDO_GEOMETRY,
  element IN NUMBER,
  ring IN NUMBER default 0
) return sdo_geometry; -- 2D

Und wie geht´s konkret?

Gegeben sei das Multipolgyon "Brandenburg" (SDO_GTYPE = 2007) aus dem World Sample NAVTEQ Data Bundle.

-- Extraction von Element 1, Ring 1
SQL> select sdo_util.extract(geometry, 1, 1) from m_admin_area2 where feature_name = 'Brandenburg';
-- Ergebnis ist der äußere Ring von Brandenburg

-- Extraction von Element 1, Ring 2
SQL> select sdo_util.extract(geometry, 1, 2) from m_admin_area2 where feature_name = 'Brandenburg';
-- Ergebnis ist der innere Ring von Brandenburg, gleichzeitig die administrative Grenze des Bundeslandes Berlin

-- Extraction von Element 2, Ring 2
SQL> select sdo_util.extract(geometry, 2, 1) from m_admin_area2 where feature_name = 'Brandenburg';
-- Ergebnis hier ist eine kleine Brandenburgische Exklave in Sachsen-Anhalt

Weitere Infos finden sich natürlich in der Online-Doku auf OTN (http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14255/sdo_util.htm#sthref1955).

Es geht los!

2010-09-02T11:37:00.002+02:00

Auf diesem Blog werden wir künftig Informationen, Tipps und Tricks zu Oracle Locator und Oracle Spatial veröffentlichen. Wir, das sind Karin Patenge, Bernhard Fischer-Wasels, Haitham Zyadeh und Carsten Czarski. Das Blog richtet sich an Entwickler und technisch Interessierte.