Freitag, 16. Oktober 2015

Oracle Spatial: Releases und Patches

Für Betreiber von Oracle Spatial auf Datenbanken der Version 11.2 oder 12.1 gibt es eine Patch-Empfehlung aus dem Development.

Any customer running 11.2.0.4, 12.1.0.1 or 12.1.0.2 releases should have the following one off spatial patches applied:

  • 12.1.0.2:
    21453611: Performance and other fixes for spatial statistics generation 
              (supersedes patches 19544707, 20653340, 20808043)
    21376696: 12.1.0.2 spatial patch bundle - Also includes faster sdo_intersection 
              with spatial_vector_acceleration=true
    
  • 12.1.0.1 or 11.2.0.4
    21453611: Performance and other fixes for spatial statistic generations 
              (supersedes patches 19544707, 20653340, 20808043)

Beim nächsten anstehenden Wartungsfenster dürfte es also eine gute Idee sein, diese Patches einzuspielen. Nutzer von älteren Datenbankversionen (11.2.0.3 und älter) wird naheliegenderweise das Upgrade auf 11.2.0.4 (oder besser: 12.1.0.2) empfohlen.



Montag, 5. Oktober 2015

Liniengeometrien glätten direkt in der Datenbank

Geometrien zu vereinfachen (auch Generalisierung genannt) ist eines der grundlegenenden Probleme in der Kartografie. Ich möchte diese Thematik speziell für Linienzüge betrachten.

Ein Linienzug wird durch Herausnehmen von Stützpunkten vereinfacht oder geglättet. Wichtig dabei ist, dass dessen grobe Gestalt erhalten bleibt.
Die Oracle Datenbank unterstützt derzeit 2 Algorithmen für die Linienglättung über vorgefertigte Funktionen:
  1. den Douglas-Peucker Algorithmus über die Funktion SDO_UTIL.SIMPLIFY
  2. den Visvalingham-Whyatt Algorithmus über die Funktion SDO_UTIL.SIMPLIFYVW
Hinweis: Als Funktionen innerhalb des SDO_UTIL-Packages sind diese für jede Edition der Oracle Datenbank als Teil von Oracle Locator anwendbar.

Wie arbeiten diese beiden Algorithmen?
Beim Douglas-Peucker Algorithmus wird der Grad der Vergröberung gesteuert durch die Angabe des maximalen Abstandes zwischen den ursprünglichen Punkten und dem approximierten Linienzug. Dies ist ein recht einfacher, rekursiver Algorithmus.
Der Visvalingham-Whyatt Algprithmus betrachtet die effektiven Flächen der Stützpunkte und entfernt Stützpunkte dann auf Basis der kleinsten effektiven Flächen.

Die Glättung ist jeweils einfach aufgerufen. Ich benutze dazu wieder ein Testdatenset des Oracle Partners GfK GeoMarketing, speziell die Tabelle DE_MAJOR_HYDRO_LINES mit dem Koordinatensystem 8307 (Oracle SRID für WGS84) und einer Toleranz von 0.05:

select name,
       sdo_util.simplify(geometry, 1)   -- Douglas-Peucker
  from de_highways
/

bzw.

select name,
       sdo_util.simplifyvw(geometry,10) -- Visvalingham-Whyatt
  from de_highways
/

Der 2. Parameter bei SDO_UTIL.SIMPLIFY, in der Dokumentation als threshold bezeichnet, muss ein Wert größer 0 sein. Für geodätische Koordinatensysteme ist die Einheit immer Meter. Für alle anderen entspricht die Einheit dem für das Koordinatensystem.
Der 2. Parameter bei SDO_UTIL.SIMPLIFYVW, in der Dokumentation als vertex_threshold bezeichnet, ist eine Prozentangabe. Der Wert kann also zwischen 0 und 100 variieren. Je größer er ist, umso gröber fällt die Glättung aus.
Letzteres gilt auch für SDO_UTIL.SIMPLIFY.

Bevor ich die Ergebnisse in einer visualisierten Form darstelle für unterschiedliche threshold-Werte, will ich noch zeigen, wie die Anzahl der Stützpunkte verglichen werden können.
Dazu bedarf es nur eines einfachen SELECT.

select name, 
       sdo_util.getnumvertices(geometry) "#Verts orig", 
       sdo_util.getnumvertices(sdo_util.simplify(geometry,1)) "#Verts D-P",
       sdo_util.getnumvertices(sdo_util.simplifyvw(geometry,20)) "#Verts V-W" 
  from de_major_hydro_line
 where name = 'Weser'
/


Und so sehen die Ergebnisse aus.

D-P: threshold = 1 | V-W: threshold = 20
Orginal Liniengeometrie: scharz
D-P Liniengeometrie: gelb
V-W Liniengeometrie: rot


D-P: threshold = 10 | V-W: threshold = 30

D-P: threshold = 20 | V-W: threshold = 50

Die Unterschiede sind marginal bei den in den ersten 3 Abbildungen gewählten Threshold-Werten und der Skalierung. Sie werden besser erkennbar, wenn noch weiter in die Geometrie hineinge"zoomed" wird bzw. die Treshold-Werte noch größer gewählt werden.

D-P: threshold = 100 | V-W: threshold = 90









Freitag, 17. Juli 2015

Affine Transformationen direkt in der Datenbank - nutzbar bereits mit Oracle Locator

In meinem Posting vom 8. September 2014 hatte ich beschrieben, wie mittels einer eigenen PL/SQL-Funktion Offsets zu Koordinatenwerten hinzugefügt werden können.

Es gibt darüberhinaus noch (mindestens) einen weiteren Lösungsansatz, der eine bereits existente Funktion zum Einsatz bringt. Und damit meine ich die Funktion AFFINETRANSFORMS im PL/SQL Package SDO_UTIL. Die Anwendung von AFFINETRANSFORM für die konkrete Aufgabenstellung möchte ich nachfolgend kurz beschreiben.

Hinweis:
Das Package SDO_UTIL ist mit jeder Edition der Oracle Datenbank nutzbar, also Bestandteil von Oracle Locator. (Sehen Sie dazu auch noch mal Tabelle B-1 im Oracle Spatial Developer´s Guide.)

Was ist die Aufgabenstellung?
Für alle Geometrien einer Tabelle soll eine Translation von 100m nach Norden erfolgen.

Lösung mittels SDO_UTIL.AFFINETRANSFORM:

select
  sdo_util.affinetransforms(
  geometry => geometry,
  translation => 'TRUE'  -- Hier soll eine Translation stattfinden
  tx => 0.0,             -- keine Rechtswert-Verschiebung
  ty => 100.0,           -- Hochwert-Verschiebung um 100 m 
  tz => 0.0
  ) as geometry
from geom_tab;

Das ist erst mal ziemlich einfach. Die Tücke steckt wie immer im Detail.
Die Verschiebungswerte tx, ty, tz  sind natürlich im zusammenhang mit dem Koordinatensystem der Geometrien zu sehen. Eine Verschiebung ty = 100.0 für Geometrien in ETRS89 / UTM (hier ist die Einheit Meter) bedeutet natürlich etwas anderes als für WGS84. Für Letzteres sind die Koordinatenwerte in Dezimalgrad angegeben.

Wie kann man möglichst einfach damit umgehen?
Mein Vorschlag dazu ist, vorab in der Datenbank eine Transformation durchzuführen.
Mit SQL ausgedrückt, sieht das dann so aus:

select
  sdo_util.affinetransforms(
    geometry => geometry,
    translation => 'TRUE', -- Hier soll eine Translation stattfinden
    tx => 0.0,             -- keine Rechtswert-Verschiebung
    ty => 100.0,           -- Hochwert-Verschiebung um 100 m 
    tz => 0.0
  )
from (                     -- Subquery in FROM-Klausel für Transformation
  select
    sdo_cs.transform(geometry, 25833) geometry
  from
    geom_tab_wgs84);

Visuell stellt sich das Ergebnis bezogen auf eine einzelne Geometrie so dar:

[Abb. 1: Original-Geometrie gelb, verschobene Geometrie orange eingefärbt.]

SDO_UTIL.AFFINETRANSFORMATIONS kann übrigens nicht nur für Translationen verwendet werden. Möglich sind u.a. auch Skalierungen, Spiegelungen oder Rotationen.

Für Rotationen füge ich gleich auch noch ein Beipiel hinzu. Das basiert auf einer sehr einfachen Geometrie, einem Rechteck, welches im unteren linken Stützpunkt um 45 gedreht wird.
Hinweis:
Der Rotationswert (Parameter ANGLE) wird als Bogenmass angegeben. Der Einfachheit halber nutze ich die Funktion CONVERT_UNIT im Paclage SDO_UTIL, um mit Werten in Grad zu arbeiten.
-- Einfache Geometrie
select 
 sdo_geometry (
   2003,
   8307,
   null,
   sdo_elem_info_array (1,1003,1),
   sdo_ordinate_array (2,0,2,5,0,5,0,0,2,0))
from dual;
-- Einfache Geometrie gedreht um 45 Grad bezogen auf den 1. Stützpunkt
select sdo_util.affinetransforms(
  geometry => sdo_geometry (
                2003,
                8307,
                null,
                sdo_elem_info_array (1,1003,1),
                sdo_ordinate_array (2,0,2,5,0,5,0,0,2,0)),
  rotation => 'TRUE',
  p1 => sdo_geometry (2001,8307,sdo_point_type(2,0,null),null,null),
  line1 => NULL,
  angle => sdo_util.convert_unit(45, 'Degree', 'Radian'),  -- Bogenmass
  -- Bzw. für Drehung im Uhrzeigersinn:
  -- angle => sdo_util.convert_unit(-45, 'Degree', 'Radian')   
  dir => -1                                                -- Default
) from dual;
Visuelle Darstellung der Ergebnisse der SQL-Abfragen (Geometrien):
 [Abb. 2: Einfache Geometrie - Orignal]
 [Abb. 3: Einfache Geometrie - um 45 Grad gedreht]

Die gedrehte Geometrie als SDO_GEOMETRY-Objekt - mit Anfangs- und Endstützpunkt x=2, y=0:
MDSYS.SDO_GEOMETRY(
 2003,
  8307,
  NULL,
  MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),
  MDSYS.SDO_ORDINATE_ARRAY(
    2,0,
    -1.53553390593274,3.53553390593274,
    -2.94974746830583,2.12132034355964,
    0.585786437626905,-1.41421356237309,
    2,0)) 

Montag, 29. Juni 2015

"Call for Speakers" für den Spatial Summit @ BIWA 2016

Der "Call for Speakers" zum Oracle Spatial Summit auf der Oracle Big Data + Analytics User Conference 2016  ist da. Gesucht werden innovative und interessante Projekte rund um Oracle Spatial and Graph sowie Oracle Fusion Middleware MapViewer. Gern auch im Umfeld von Data Warehouse, Business Intelligence, Analytics, Big Data, Cloud, IoT.
Details zur Konferenz gibt es hier. Und auch Abstracts können bereits eingericht werden. Dazu finden Sie ganz unten auf dieser Seite einen Link auf das Einreichungsformular.

Wer noch mal nachschauen möchte, welche Spatial-/MapViewer-Beiträge es auf dem BIWA Summit im Januar 2015 gab, wird hier fündig.

Montag, 18. Mai 2015

Oracle Big Data Spatial and Graph ist draussen

Seit letzter Woche gibt es ein neues Produkt: Oracle Big Data Spatial and Graph.

Hier ist eine kurze Zusammenfassung (in Englisch) über die 2 wesentlichen Komponenten des neuen Produkts:
  1. A distributed property graph database with 35 built-in graph analytics to
    • Discover graph patterns in big data, such as communities and influencers within a social graph
    • Generate recommendations based on interests, profiles, and past behaviors
  2. A wide range of spatial analysis functions and services to
    • Evaluate data based on how near or far something is to one another, or whether something falls within a boundary or region
    • Process and visualize geospatial map data and imagery
Mehr dazu hat Jean Ihm auf dem neuen "Oracle Big Data Spatial and Graph" Blog veröffentlicht. Und wie immer gibt es als Einstieg natürlich auch die Webseiten zum Produkt im Oracle Technologie Network.

Das "Big Picture" zum Oracle Big Data Management sieht jetzt also so aus:


Donnerstag, 23. April 2015

PolygonToLine: Geht das auch umgekehrt?

Im PL/SQL Package SDO_UTIL findet sich die Funktion POLYGONTOLINE, welche ein Polygon in eine Linie konvertiert.
Für den umgekehrten Vorgang, eine Linie in ein Polygon umzuwandeln, gibt es (noch) keine solche Funktion im Package. Allerdings kann ich die gerade ganz gut brauchen. Denn für ein Set an Isolinien (SDO_GEOMETRY mit GTYPE=2002) sollen die abgedeckten Flächen berechnet werden. Flächenberechnungen mit SDO_GEOM.AREA sind aber nur für Polygone (inklusive Polygone mit Löchern) erlaubt.
Also schreiben wir uns selbst eine Funktion. Das ist auch nicht weiter schwierig, wie Ihr weiter unten sehen könnt.
Der besseren Lesbarkeit halber habe ich die wichtigsten Erläuterungen als Kommentar in den Code eingefügt.

Viel Spass beim Ausprobieren !

create or replace function line_to_polygon (
  p_line_geom sdo_geometry)
return sdo_geometry deterministic
is 
  p_polygon_geom sdo_geometry;
  k number;
begin
  /* 
   * Geometrietyp prüfen: Muss gleich 2002 für einfache 2D Linien-Geometrie sein.
   * Doku: http://docs.oracle.com/cd/B28359_01/appdev.111/b28400/sdo_objrelschema.htm#g1013735 
   */
  if p_line_geom.sdo_gtype <> 2002 then
    raise_application_error (-20001, 'Geometrie ist keine einfache 2D Linie.  GTYPE <> 2002.');
  end if;

  p_polygon_geom := p_line_geom;

  -- GTYPE neu setzen für einfache 2D Polygon-Geometrie.
  p_polygon_geom.sdo_gtype := 2003;

  /* 
   * ELEMENT_INFO_ARRAY neu setzen.
   * Doku: http://docs.oracle.com/cd/B28359_01/appdev.111/b28400/sdo_objrelschema.htm#SPATL494 
   */
  
  p_polygon_geom.sdo_elem_info := sdo_elem_info_array (1, 1003, 1);

  -- Anzahl der Stützpunkte bestimmen
  k := p_polygon_geom.sdo_ordinates.count;

  /* 
   * Polygon muss geschlossen werden. 
   * Daher prüfen, ob letzter Stützpunkt der Linie gleich dem 1. Stützpunkt ist. 
   * Wenn nicht, neuen Stützpunkt einfügen (SDO_ORDINATE_ARRAY wird erweitert um 2 Werte). 
   */

  if (p_polygon_geom.sdo_ordinates(k-1) <> p_polygon_geom.sdo_ordinates(1)
    or p_polygon_geom.sdo_ordinates(k) <> p_polygon_geom.sdo_ordinates(2))
  then
    p_polygon_geom.sdo_ordinates.extend(2);
    p_polygon_geom.sdo_ordinates(k+1) := p_polygon_geom.sdo_ordinates(1);
    p_polygon_geom.sdo_ordinates(k+2) := p_polygon_geom.sdo_ordinates(2);
  end if;
  
  -- Jetzt nur noch die Polygon-Geometrie zurückgeben
  return p_polygon_geom;
end line_to_polygon;
/
sho err
Diejenigen unter Euch, welche Anfang des Jahres im Oracle Spatial Workshop mit Albert Godfrind waren, finden die Funktion auch im Labs/07-processing-Ordner.

Freitag, 17. April 2015

Welche Geometrietypen sind in einer SDO_GEOMETRY-Tabelle zu finden?

Dieser Tipp fällt wieder einmal in die Kategorie: Lauter kleine Helferlein.

Fragen Sie sich auch manchmal, welche Geometrietypen eigentlich in einer Tabelle so alles zusammengefaßt sind?
Ohne groß weiter nachzudenken, ist ein Ansatz:
  select distinct g.geom.sdo_gtype
    from geom_tab g
order by 1;
Im Ergebnis erhalte ich die numerische Kodierung der verwendeten Geometrietypen.

Das Ganze könnte ich zum Beispiel mit DECODE nun noch so aufbereiten, dass auch nicht mit dieser Kodierung Vertraute den Inhalt verstehen.

Alternativ - und das ist an dieser Stelle meine Empfehlung - kann ich aber auch die Funktion MIX_INFO im SDO_TUNE-Package benutzen.
execute sdo_tune.mix_info('GEOM_TAB','GEOM');
Die gibt mir die Geometrietypen nicht nur in lesbarer Form zurück, sondern zusätzlich auch gleich noch:
  • die Gesamtzahl der Geometrien,
  • die Anzahl an Geometrien pro Geometrietyp sowie
  • die prozentuale Verteilung pro Geometrietyp
Das sieht für meine Beispiel-Tabelle dann so aus:
Total number of geometries: 5274896
   Point geometries:        0  (0%)
   Curvestring geometries:   0  (0%)
   Polygon geometries:      5274896  (100%)
   Complex geometries:      0  (0%)

Montag, 13. April 2015

Oracle Spatial und Twitter

Wir nutzen Twitter als Kommunikationskanal.
Häufig verwendete Hashtags sind: #oraclespatial #oraclemaps #spatial #LIOracleSpatial

Ihr könnt auch Carsten, mir und anderen aus der Spatial Community bei Oracle direkt folgen:
@cczarski @kpatenge @agodfrin @richpitts

Dienstag, 7. April 2015

Beispeilhaft den Nutzen von VPA testen - Ein kleines Skript für den Eigengebrauch


Im Anschluss an einen Workshop zu Oracle Spatial 12c hat einer der Teilnehmenden das Feature VPA (Vector Performance Accelerator) erfolgreich getestet.
Ich habe dazu eine kurze Nachricht in der Oracle Spatial and Graph Gruppe von LinkedIn geposted.

Für diejenigen, die VPA selbst mal ausprobieren wollen, habe ich hier ein kleines Skript. Dieses vergleicht die Ausführungszeiten einer SQL Query ohne VPA gegen die mit VPA. Es kann für eigene zu testende Abfragen entsprechend angepaßt werden.

Das Ergebnis für 3 beispielhafte Queries kann sich mehr als sehen lassen. Die Zusammenfassung findet Ihr am Ende.

Für die Tests habe ich Beispieldaten (Postleitzahlgebiete von DE) des Oracle Partners GfK GeoMarketing verwendet. (Den anzupassenden Teil habe ich rot gekennzeichnet.)
REM spatial_12c_vpa_perf_test.sql - collect performance information related to Oracle Spatial 12c
REM Run script as user SYSTEM
define SRDCNAME='SPATIAL_VPA_PERF_TRACE'
set TERMOUT off FEEDBACK off VERIFY off TRIMSPOOL on HEADING off
COLUMN SRDCSPOOLNAME NOPRINT NEW_VALUE SRDCSPOOLNAME
select 'SRDC_'||upper('&&SRDCNAME')||'_'||upper(instance_name)||'_'||
       to_char(sysdate,'YYYYMMDD_HH24MISS') SRDCSPOOLNAME from v$instance;
set TERMOUT on
REM
spool &&SRDCSPOOLNAME..txt
select '+----------------------------------------------------+' from dual
union all
select '| Diagnostic-Name: '||'&&SRDCNAME' from dual
union all
select '| Timestamp:       '||
          to_char(systimestamp,'YYYY-MM-DD HH24:MI:SS TZH:TZM') from dual
union all
select '| Machine:         '||host_name from v$instance
union all
select '| Version:         '||version from v$instance
union all
select '| DBName:          '||name from v$database
union all
select '| Instance:        '||instance_name from v$instance
union all
select '+----------------------------------------------------+' from dual
/

set HEADING on
set echo on feedback on termout on pages 999 lines 132 long 300000000

DEFINE OBJ_OWNER = &1
DEFINE OBJ_PASSWD = &2

/*
 * Grant necessary privileges
 */

grant alter system to &&OBJ_OWNER;
grant alter session to &&OBJ_OWNER;

connect &&OBJ_OWNER/&&OBJ_PASSWD
alter system flush shared_pool;

alter session set tracefile_identifier='SRDC_Spatial_VPA_Perf_Test';
alter session set events '10046 trace name context forever, level 12';
-- alter session set sql_trace = TRUE;

alter session set spatial_vector_acceleration = FALSE;

set timing on
REM -- ------------------------------------
REM -- Add query to be traced and analyzed
REM -- Run without VPA first
REM -- ------------------------------------

REM -- Begin of query
with test as (
  select sdo_aggr_union(sdoaggrtype(g.geometry,0.05)) aggr_geom 
    from de_5digpc_2010 g
   where substr(g.id,1,1) in ('0','1','2'))
select count(*) 
  from test;
REM -- End of query

set timing off

alter system flush shared_pool;
alter session set spatial_vector_acceleration = TRUE;
 
set timing on
REM -- ------------------------------------
REM -- Add same query
REM -- Run with VPA now
REM -- ------------------------------------

REM -- Begin of query
with test as (
  select sdo_aggr_union(sdoaggrtype(g.geometry,0.05)) aggr_geom 
    from de_5digpc_2010 g
   where substr(g.id,1,1) in ('0','1','2'))
select count(*) 
  from test;
REM -- End of query
  
set timing off

spool off

Im Ergebnis erhalte ich Faktoren von 10 bis 253, was die Ausführungszeiten betrifft.
Fazit:
Je grösser die Anzahl der zu aggregierenden Polygone, umso höher ist der Performancegwinn.

Und hier sind die Ergbnisse im Detail:

Anzahl der aggr. Objekte Geometrietyp Elapsed time in Sek. ohne VPA Elapsed time in Sek. mit VPA Faktor Abfrage
10 Polygon 18,33 1,78 10 with test as (
select sdo_aggr_union(sdoaggrtype(g.geometry,0.05)) aggr_geom
from de_1digpc_2010 g)
select count(*)
from test;
95 Polygon 151,66 2,44 62 with test as (
select sdo_aggr_union(sdoaggrtype(g.geometry,0.05)) aggr_geom
from de_2digpc_2010 g)
select count(*)
from test;
2168 Polygon 1338,65 5,29 253 with test as (
select sdo_aggr_union(sdoaggrtype(g.geometry,0.05)) aggr_geom
from de_5digpc_2010 g
where substr(g.id,1,1) in ('0','1','2'))
select count(*)
from test;

Mittwoch, 11. März 2015

DOAG Spatial Community Day - 7. Mai 2015 in Frankfurt

Nach einer etwas längeren Pause trifft sich die deutschsprachige Spatial / Geodaten Community zum DOAG Spatial Community Day - am 7. Mai 2015 in Dreieich bei Frankfurt. Im Mittelpunkt stehen diesmal unter anderem folgende Themen.

  • News Update zu Oracle Locator, Spatial und Oracle Maps
  • HERE (NAVTEQ)-Daten in der Oracle-Datenbank: Erfahrungen aus der Praxis
  • OpenStreetMap und Oracle Spatial im Zusammenspiel
  • Adressvalidierung mit Hilfe des Oracle-Geocoders
Wie jedes Mal kommen Diskussion und Austausch nicht zu kurz. Schaut euch die Agenda mal an - wenn's interessant ist, gleich anmelden unter:

http://www.doag.org/termine/termine.php?tid=496872

Freitag, 6. März 2015

Kleines Anwendungsbeispiel für PointInPolygon

Letztens erhielt ich mal wieder eine kleine Fragestellung, dessen Lösungsansatz ich hier vorstellen möchte.

Frage:
Wie kann mittels SQL festgestellt werden, welche Linien-Geometrien ihren Startpunkt in einem definierten Gebiet (Polygon) haben? (Abflüge, Startpunkte für Wege zu Fuss oder mit einem Fahrzeug, ...)

Visuell kann das Ergebnis einer solchen Frage wie in dieser Abbildung dargestellt werden:

Es gibt sprichwörtlich viele Wege nach Rom.

Einer davon ist mein Lösungsansatz mittels des ab Oracle DB 12c verfügbaren neuen SDO_POINTINPOLYGON Operators. (Infos dazu gibt es auch in diesem Blog-Posting.)

Und das ist mein SQL-Statement:

WITH temp AS (
  SELECT r.id, first_vertex(r.geom) coord, r.geom geom 
    FROM t_routen r)                    -- T_ROUTE: Tabelle mit Liniengeometrien
SELECT * FROM (
  TABLE(
    SDO_POINTINPOLYGON(
      CURSOR(                           -- X,Y müssen die ersten beiden Parameter sein
        SELECT t.coord.sdo_point.x x, t.coord.sdo_point.y y, t.id  
          FROM temp t),
      (SELECT g.geom FROM t_gebiet g),  -- T_GEBIET: Tabelle mit Polygon für das Startgebiet
      0.05,
      'mask=inside'))) a;               -- Mask=INSIDE: Startpunkt soll im Polygon liegen
Wie zu sehen ist, verwende ich darin eine Funktion, first_vertex von mir benannt, die den 1. Stützpunkt einer (2D) Linien-Geometrie ermittelt. Und so sieht die Funktion aus:
CREATE OR REPLACE FUNCTION first_vertex(geom SDO_GEOMETRY)
RETURN SDO_GEOMETRY DETERMINISTIC
IS
  vertx MDSYS.VERTEX_SET_TYPE;
BEGIN
  vertx := SDO_UTIL.GETVERTICES(geom);
  RETURN SDO_GEOMETRY(2001, geom.sdo_srid, sdo_point_type(vertx(1).x, vertx(1).y, NULL), NULL, NULL);
END;
/
Warum verwende ich im Lösungsansatz nicht SDO_INSIDE(geometry1, geometry2);?

Der Grund ist recht einfach: Ich benötige auf geometry1 einen Spatial Index.
Den habe ich zwar auf der Tabelle T_ROUTEN selbst, jedoch nicht auf dem 1. Stützpunkt der Geometrien. Ich müsste also einen Function-Based Index anlegen, damit SDO_INSIDE funktioniert. Das spare ich mir, weil es ja SDO_POINTINPOLYGON gibt.



Die Fragestellung kann dann noch sehr leicht dahingehend erweitert werden, festzustellen, ob irgendwo auf meiner Route bestimmte andere Gebiete (Bundesländer, Umweltzonen, etc.) durchfahren, überflogen, etc. wurden.

Dazu vergleiche ich das Ergebnis der Anfrage oben in der WHERE-Klausel mit einer 2. Polygon-Geometrie (hier Tabelle T_ZONE).

WITH temp AS (
  SELECT r.id, first_vertex(r.geom) coord, r.geom geom 
    FROM t_routen r)                    -- T_ROUTE: Tabelle mit Liniengeometrien
SELECT * FROM (
  TABLE(
    SDO_POINTINPOLYGON(
      CURSOR(                           -- X,Y müssen die ersten beiden Parameter sein
        SELECT t.coord.sdo_point.x x, t.coord.sdo_point.y y, t.id  
          FROM temp t),
      (SELECT g.geom FROM t_gebiet g),  -- T_GEBIET: Tabelle mit Polygon für das Startgebiet
      0.05,
      'mask=inside'))) a                -- Mask=INSIDE: Startpunkt soll im Polygon liegen
WHERE a.id IN  (
  SELECT r.id
    FROM t_zone z, t_routen r
   WHERE a.id = r.id 
     AND SDO_ANYINTERACT (r.geom, z.geom) = 'TRUE');

Viel positives Feedback zu den Oracle Spatial Workshops mit Albert Godfrind

Im Januar und Februar haben wir in Frankfurt zwei jeweils 2-tägige Workshops zu Oracle Spatial 12c durchgeführt. Beide Termine waren sehr gut besucht. Und wir haben sehr viel positives Feedback erhalten, wie dieses hier (was ich aus dem Gedächtnis zitiere):

"Ich wusste nicht, dass ich mit Oracle auf einer solch detaillierten technischen und fachlichen Ebene sprechen kann, wenn es raumbezogene Daten geht ..".

Ja, Leute: Wir können auch technisch. Und nicht nur eine/r oder zwei von uns, wird sind mehr ;-).
Wir teilen unser Wissen gern, so gern, wie wir auch auf das Wissen von Anderen immer wieder zurückgreifen. Denn auch wir müssen das Rad ja nicht jedes Mal neu erfinden.

In diesem Sinne also vielen Dank an alle, die aktiv durch Teilnahme, Diskussion und / oder Fragen zum Gelingen dieser Workshops beigetragen haben.

Besonderer Dank geht an:

Übrigens: Wiederholungen sind nicht ausgeschlossen.
Lasst Carsten und mich wissen, wenn Ihr daran Interesse habt.

Donnerstag, 19. Februar 2015

Alle Präsentationen vom BIWA / Oracle Spatial Summit 2015

Die Materialien vom Oracle Spatial Summit am 27.-28. Januar 2015 in Redwood Shores / CA sind jetzt online verfügbar.
Hier ist eine Auswahl mit direkten Links:
 Eine Übersicht zu allen Sessions mit den Verweisen auf die Download-Links findet sich hier.

Wer spannende Projekte im Umfeld der Oracle Spatial Technologies hat und diese gern auf dem nächsten Spatial Summit vorstellen möchte, sollte sich schon mal diesen Termin vormerken:
  • 26.-28. Januar 2016 im Oracle Conference Center in Redwood Shores
Mehr Infos gibt es auf den BIWA Summit Seiten. 

Dienstag, 20. Januar 2015

Vergleichender Test von Oracle DB 12 mit eingeschaltetem Vector Performance Accelerator (VPA)

Simon Greener hat die Auswirkungen des Oracle Spatial 12c Features "Vector Performance Acceelerator" auf die Performance von räumlichen Abfragen untersucht. Darüberhinaus hat er die Ergebnisse mit anderen Hersteller verglichen.
Vorgehensweise und Ergebnisse sind hier veröffentlicht. Die Ergebnisse gibt es auf Nachfrage per Formular oder als Zusammenfassung in diesem Foliensatz von der OOW 2014 (Folien 11 bis 13).

Die Nutzung von VPA ist sehr einfach, indem der entsprechende Datenbank-Parameter auf TRUE gesetzt wird. Damit l&aum;sst sich sehr schnell in der eigenen Umgebung evaluieren, welchen Nutzen das Feature haben kann.

ALTER SYSTEM SET SPATIAL_VECTOR_ACCELERATION = TRUE;
Es ist zu beachten, dass Simon bei diesen Tests keine weiteren performance-beeinflussenden Techniken wie z.B. Parallelisierung betrachtet hat.

Wenn jemand eigene Tests mit VPA und Parallelisierung aufsetzen möchte, kann sie oder er sich gern an uns wenden.