Freitag, 12. Februar 2016

Präsentationen zum BIWA Summit 2016 online verfügbar

Auch dieser Summit ist jetzt schon wieder Geschichte. Und wie im vergangenen Jahr haben sich die Data Warehouse- und Business Intelligence-Interessierten mit den Spatial SpezialistInnen zusammengetan.
Aus Europa gab es erfreulich viel Beteiligung. Das kann gern so bleiben (oder noch mehr werden). Also reservieren Sie sich einfach schon mal die Zeit Ende Januar/Anfang Februar in 2017.

Beiträge gab es rund um die Themen:
  • Advanced Analytics
  • BI and Visualization
  • Big Data
  • Cloud Computing
  • Data Warehousing and ETL
  • Internet of Things
  • Oracle Spatial
Und hier ist der Link zum Download und Nachlesen der einzelnen Beiträge.

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.