API für die Nachverfolgung von Kontakten in der Oracle DB

Wer regelmäßig die AskTom Office Hours verfolgt, sollte es schon gesehen haben: Das Oracle Spatial Development Team hat eine Contact Tracing API für die Oracle DB geschrieben, die hervorragend z.B. in APEX-Anwendungen zum Einsatz kommen kann.
Seit Mitte September stehen 2 Versionen dieser API bereit. 

1. Swipe IN/OUT Contact Tracing
   Hierfür werden keine GPS Daten benötigt, sondern die zeitgleiche räumliche Nähe zu Sensoren. Die Analyse erfolgt dann auf der Basis der zeitlichen Überlappungen.
   
   
   
   
   
2. GPS-based Contact Tracing
   Hierfür werden GPS-Daten als Serie von Punktkoordinaten mit zugeordneten Zeitstempeln vorausgesetzt.
   
   
   
   
   

Die APIs sind Bestandteil jeder Oracle Datenbank Lizenz. Detaillierte Informationen gibt es 

• in diesem Foliensatz von Dan Geringer, 
• im Blog Post (Englisch) von Hans Viehmann am 13. September
• und auch als Note (# 2691413.1) in MyOracleSupport.

Ausprobieren ist ausdrücklich erwünscht. Dafür stehen nicht nur die Skripte sondern auch Testdaten bereit (Siehe Supplement Teil im vorher erwähnten Blog Post).

Geodaten in der Oracle DB: Ein Einstieg für Newbies

Ich gebe es zu: Ich bin fremdgegangen.

Meine Kolleg*innen haben mich gebeten, einen Beitrag zu Geodaten in der Oracle Datenbank für einen anderen Blog zu schreiben.
Die Chance, ein (noch) nicht so Geodaten-affines Publikum zu erreichen, hat mich natürlich gereizt. Ich habe mir also einen Open Data Datensatz (Ride & Bike Stationen in Düsseldorf) genommen, diesen in die Oracle DB geladen und anschließend mit SQL Developer, MapViewer und auch Oracle Application Express (aka APEX) visualisiert.

Wenn Ihr Interesse (und auch noch Zeit) habt, dann schaut einfach mal rein. Hier geht es zum Blog Post.

Neu in Oracle DB 18c: Räumliche Abfragen auch ohne Spatial Index

Eine der Neuerungen in der Version 18c ist, daß der Spatial Index nicht mehr erforderlich ist für räumliche Abfragen.

Probiert dies einfach mal aus. Eure Erfahrungen können gern als Kommentar an diesen Post geschickt werden.

Auch wenn es möglich ist, geht die Empfehlung dennoch dahin, Spatial Indexes anzulegen. Ihr könnt die Benutzung dieser auch "erzwingen", indem Ihr Event 54700 auf Level = 1 setzt.

alter session set events '54700 trace name context forever, level 1';

oder

alter system set events '54700 trace name context forever, level 1';

Der Default Wert steht auf 0.

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

Ein GeoRaster ETL Werkzeug als grafische Oberfläche für gdal zum Laden nach SDO_GEORASTER

In meinem letzten Blog-Posting, dem 1. zum Thema Rasterdaten, hatte ich den Georaster-Viewer vorgestellt.
Für den Einstieg ins Thema und den schnellen Erfolg, ein Rasterbild in die Datenbank zu laden, war das sicher erst mal hilfreich.
Was das Laden oder Exportieren von Rasterdaten betrifft, kommt man sicher an gdal nur schwer vorbei. Daher wird die Nutzung auch schon länger von Oracle empfohlen. Allerdings braucht es doch ein wenig Übung, auf Kommandozeilenebene damit umzugehen. (Infos u.a. hier)

Eine grafische Oberfläche vom Spatial Development Team schafft Abhilfe. Diese verwendet intern gdal. Die Rede ist vom Georaster Batch ETL Werkzeug (GDAL-based GeoRaster Concurrent Batch Loading and Exporting Wizard). Dessen neueste Version kann von den Oracle Spatial and Graph Sample Code Webseiten im OTN heruntergeladen werden. Es kann sowohl für die Version 12c als auch 11g verwendet werden. Ich habe einen ersten Test mit Version 12cR1 durchgeführt.

Nach dem Download, Auspacken und Anpassen des Shell- bzw. Batch-Skripts (startGeoRasterETL.sh bzw. startGeoRasterETL.bat) kann es auch schon losgehen. Für den Einstieg hilft zudem noch ein kleines Handbuch.
Wie der Name nahelegen soll, können mehrere Rasterdaten-Files gleichzeitig geladen werden. Diese werden ausgeählt, mit den entsprechenden Ladeparameter-Werten versehen (u.a. Blocking oder Anzahl der Pyramid Levels).

Alles zusammen wird als XML-Parameterdatei gespeichert und anschließend als Job ausgeführt.

Die vier in die Tabelle CITY_IMAGES geladenen Rasterdaten-Dateien überprüfe ich dann mit dem schon bekannten GeoRaster-Viewer. Sie wurden mit den (automatisch vergebenen) RasterIDs 49−52 geladen.

Was es mit Blocking und Pyramiden auf sich hat, darüber soll es dann in einem neuen Blog-Posting gehen.