Haben Sie schon mal drüber nachgedacht, Ihre Datenbank zu fragen, wie Sie von A nach B kommen? Nein? Ich schon.
Dafür braucht´s doch eigentlich nicht so viel. Lassen Sie mich mal "laut" denken:
Vom Start- als auch Endpunkt kenne ich die (ungefähre) Adresse.
Was ich jetzt brauche, ist ein Prozess, der Folgendes für mich erledigt:
- Suche in einem Straßennetz nach Start- und Zielpunkt.
- Berechne den kürzesten oder auch schnellsten Weg zwischen diesen beiden Punkten.
- Gib mir die ermittelte Route zurück sowohl in ihrer textlichen Beschreibung als auch grafisch in einer Karte dargestellt.
Ein Straßennetz als Datengrundlage
Wo bekomme ich ein Straßennetz her? Wie findet das seinen Weg in meine Datenbank?
Sie merken schon, ich verwende den Begriff Straßennetz. So ein Netz hat eine bestimmte Struktur, ist es doch aus Knoten und Kanten aufgebaut, das mit Hilfe des Netzwerkdatenmodells (NDM) (Funktionalität der DB EE Option Oracle Spatial) abgebildet wird. Soll das Netz noch "routingfähig" sein, so sind noch zusätzliche Dinge zu berücksichtigen. Um hier nicht „Hand anlegen“ zu müssen, kann man auf bekannte Datenanbieter zurückgreifen an, welche routingfähige Datensets für die Oracle Datenbank bereitstellen. Die Zauberformel hier heißt: Bitte im "Oracle Delivery Format" (ODF).
Für diesen Blog verwende ich ein Demo-Datenset für die Stadt San Francisco, welches vom Datenanbieter NAVTEQ kostenfrei abgegeben wird. Zwar war ich dort noch nicht, aber Start- und Endpunkte für Testanfragen zu finden, sollte nicht so schwer sein.
Also laden Sie sich das Datenset zunächst einmal herunter. Den entsprechenden Link darauf finden Sie auf den "Oracle Spatial – Partners´ Data Downloads" Seiten.
Nach dem Auspacken finden Sie typischerweise sowohl die eigentlichen Daten als .dmp-Datei sowie Installationsanleitung und Setup-Skript.
Die Daten sollen einem eigenen DB-Benutzer zugeordnet werden. Von daher lege ich diesen erst einmal an und statte ihn mit notwendigen Rechten aus.
sqlplus system/oracle
-- Neuen Datenbank-Nutzer anlegen als SYSTEM
create user navteq_sf identified by navteq_sf;
-- Nutzer NAVTEQ_SF mit notwendigen Rechten ausstatten
alter user NAVTEQ_SF default tablespace USERS quota unlimited on USERS;
grant connect,resource,create view to navteq_sf;
grant create any directory to navteq_sf;
-- Ausloggen
exit;
So jetzt geht´s daran, das San Francisco Datenset zu importieren. Bei diesem doch relativ kleinen Datenbestand von ca. 230MB reicht der altbekannte imp-Befehl aus.
REM Importieren der Daten
REM Vorher in das Verzeichnis wechseln, in welchem die Daten liegen
imp navteq_sf/navteq_sf file=NAVTEQ_SF_Sample.dmp log=NAVTEQ_SF_Sample.log full=yes
Im Installationsskript finden Sie Hinweise, dass anschliessend ein bisschen Postprocessing notwendig ist. Es müssen nämlich noch Darstellungsvorschriften für die spätere Visualisierung als Karte eingefügt werden. Und auch das Netzwerk ist zu registrieren sowie für eine effiziente Anfragebearbeitung zu partitionieren. Letzteres setzt übrigens
nicht die Option Partitioning voraus, sondern gehört zum Funktionsumfang von Oracle Spatial und dessen NDM.
sqlplus navteq_sf/navteq_sf
-- Postprocessing wie im Installationsskript bei NAVTEQ beschrieben
-- Metadaten einfügen
insert into user_sdo_maps select * from my_maps;
insert into user_sdo_cached_maps select * from my_cached_maps;
insert into user_sdo_themes select * from my_themes;
insert into user_sdo_styles select * from my_styles;
commit;
-- Anmelden als SYSTEM
connect system/oracle
-- DB Verzeichnis für die Log-Datei anlegen
create or replace directory sdo_router_log_dir AS '/tmp/NAVTEQ';
-- Zugriffsrechte sowohl auf DB- als auch OS-Verzeichnis einräumen
grant read, write on directory sdo_router_log_dir to navteq_sf;
call dbms_java.grant_permisssdo_router_partitionion( 'NAVTEQ_SF', 'SYS:java.io.FilePermission', '/tmp/NAVTEQ/sdo_router_partition.log', 'write' );
call dbms_java.grant_permission( 'MDSYS', 'SYS:java.io.FilePermission', '/tmp/NAVTEQ/sdo_router_partition.log', 'write' );
-- Anmelden als NAVTEQ_SF
-- Netzwerk einrichten
-- Parameter:
-- Name der Log-Datei (Default: 'sdo_router_partition.log')
-- Name des Netzwerkes (Default: 'NDM_US')
execute sdo_router_partition.delete_router_network('sdo_router_partition.log', 'NAVTEQ_SF_NET');
execute sdo_router_partition.create_router_network('sdo_router_partition.log', 'NAVTEQ_SF_NET');
-- Noch mal prüfen
select network from user_sdo_network_metadata;
-- Netzwerk partitionieren
-- Parameter:
-- Name der Log-Datei (Default: 'sdo_router_partition.log')
-- Max. Anzahl von anzulegenden Partitionen (Default: 10000)
-- Fahrseite (Default: 'R')
-- Name des Netzwerkes (Default: 'NDM_US')
-- Cleanup (Default: TRUE)
execute sdo_router_partition.partition_router('sdo_router_partition.log',1000,'R','NAVTEQ_SF_NET');
-- Partitionen prüfen
select count(*) from partition;
-- Remove the directory as user SYSTEM
connect system/oracle
drop directory sdo_router_log_dir;
Wie sieht mein soeben geladenes, registriertes und partitioniertes Netzwerk eigentlich aus?
Das überprüfe ich mit dem NDM Editor, einer Java-Anwendung, welcher im Verzeichnis $ORACLE_HOME/md/demo/network/editor liegt, sofern man die Oracle DB Examples installiert hat. Da dieser Editor "einst" für Demozwecke mit Spatial in der Oracle DB 10g entwickelt wurde, ist dessen Oberfläche schon "etwas in die Jahre" gekommen. Aber voilá, mein Netzwerk ist da.
Damit ist der 1. Teil auch schon geschafft.
Routing Engine aufsetzen
Im Gegensatz zu den Datensets (routingfähiges Netzwerk) ist die Routing Engine Bestandteil von Oracle Spatial. Über diese wird eine XML-basierter Web Service bereitgestellt, der entweder
- eine individuelle Route von A nach B und für diese Informationen zu Distanz, Richtung und voraussichtlicher Fahrzeit berechnet oder
- Mehrfachrouten von A nach B, C, D, ... berechnet und für jede der ermittelten Routen die Distanz sowie voraussichtlicher Fahrzeit ausgibt.
Start und Ziel können dabei sowohl Adressen, Knoten im Netzwerk oder Geokoordinaten sein.
Wenn für das Routing besondere Einschränkungen (sogenannte Netzwerk-Constraints wie z.B. gesperrte Bereiche, Abbiegeverbote) oder dynamische Kosten zu berücksichtigen sind, dann steht dafür eine Java-API bereit.
Die Routing Engine ist technisch gesehen eine J2EE Web-Anwendung, die ich auf einem WebLogic Server deployen werde. Dazu habe ich vorab über OTN den WebLogic Server 10.3.6 heruntergeladen (wls1036_dev.zip), ausgepackt und eine Domain (Name: route_domain / Port: 7001) angelegt. Hinweise für das Anlegen der Domain können der Online-Dokumentation entnommen werden.
Hinweise zum Deployment gibt es im Kapitel 13 des Oracle Spatial Developer´s Guide. Das Netzwerk hatten wir ja schon registriert. Dadurch können die Punkte 1 und 2 im Kap. 13.2 übersprungen werden. Auch die Default-Web-Seite wird im Moment nicht benötigt. Was ich jedoch benötige, ist das routeserver.ear-File aus $ORACLE_HOME/md/jlib. Hier folge ich genau der Handbuch-Beschreibung inklusive dem Kopieren von xmlparserv2.jar aus $ORACLE_HOME/LIB/ nach $routeserver.ear/web.war/WEB-INF/lib/.
Da wir für die Umwandlung von Adressen in Geokoordinaten auch einen Geocoding-Service benötigen, wird das geocoder.ear-File aus $ORACLE_HOME/md/jlib analog in die gleiche WebLogic-Domain deployed. Hinweise dazu gibt es im Kapitel 11.7 des gleichen Handbuchs.
Bevor die Admin Console des RouteServers das 1. Mal gestartet wird, um den RouteServer zu deployen, sollte noch die Speicherzuweisungen für die Java-Umgebung in $MW_HOME/user_projects/domains/route_domain/bin/setDomainEnv.sh erhöht werden. Ich habe die folgenden Werte für meine 32-bit Java Runtime Umgebung verwendet:
- -Xms512m
- -Xmx1024m
- -XX:PermSize=128m
- -XX:MaxPermSize=256m
Und jetzt kann der RouteServer gestartet werden.
cd $MW_HOME/user_projects/domains/route_domain/bin
./startWebLogic.sh
Um zu sehen, ob RouteServer als auch Geocoder richtig deployed sind, starte ich zunächst die Admin-Console auf der Route Domain. Einfach einen Browser öffnen und als URL http://localhost:7001/console eingeben.
Jetzt muss der RouteServer noch so konfiguriert werden, dass er auf das zuvor angelegt Straßennetz von San Francisco zugreift, um für diesen Bereich dann Routen berechnen zu können. Die Admin-Konsole kann geschlossen und der RouteServer gestoppt werden.Zum Stoppen reicht eine CTRL-C im Terminalfenster.
Die Konfigurationsdatei web.xml für den RouteServer liegt im Verzeichnis $MW_HOME/routeserver.ear/web.war/WEB-INF.
Die vorgenommenen Änderungen sind nachfolgend aufgeführt. In der Tabelle angegebene Parameterwerte bleiben unverändert.
| param-name | param-value |
| routeserver_schema_jdbc_connect_string | jdbc:oracle:thin:@localhost:1521:orcl |
| routeserver_schema_username | NAVTEQ_SF |
| routeserver_network_name | NAVTEQ_SF_NET |
| geocoder_http_url | http://localhost:7001/geocoder/gcserver |
| geocoder_schema_host | localhost |
| geocoder_schema_port | 1521 |
| geocoder_schema_sid | orcl |
| geocoder_schema_username | NAVTEQ_SF |
| geocoder_schema_password | navteq_sf |
| max_speed_limit | 100 |
| language | German |
Hinweis: Die Parameterwerte beziehen sich auf meine Testumgebung. Gegebenenfalls müssen Sie diese für Ihre Testumgebung anpassen.
Die Konfigurationsdatei geocodercfg.xml für den Geocoder liegt im Verzeichnis $MW_HOME/geocoder.ear/web.war/WEB-INF und ist nicht ganz so umfangreich. Hier genüt es, die Datenbank-Attribute im element geocoder abzuändern.
Um alle Änderungen zu aktivieren, starte ich den RouteServer noch mal wie oben bereits beschrieben. Im Browser geben sie dann die URL http://localhost:7001/routeserver ein. Was Sie dann erhalten, ist die nachfolgend abgebildete Webseite:
Mit diesem Schritt sind alle vorbereitenden Maßnahmen abgeschlossen und der RouteServer kann wie eingangs beschrieben verwendet werden.
Routen berechnen mittels XML Request und Response
Anfragen an den RouteServer werden nun als XML-Request gestellt. Ergebnisse kommen als XML-Response zurück.
Jetzt können einfache (simple) als auch Batch-Anfragen gestellt werden über die vorhandenen Links. Die Angaben im XML Dokument (Request) zu Start und Ziel(en) sind dabei auf das Datenset für San Francisco anzupassen. Auch die Angaben zu den Präferenzen im Element
route_request sind anpaßbar. Erläuterungen zu den gültigen Werten finden sich im
Handbuch.
Nachfolgend ein Beispiel:
<?xml version="1.0" standalone="yes"?>
<route_request id="10"
route_preference="fastest"
road_preference="local"
return_driving_directions="true"
distance_unit="km"
time_unit="minute"
return_route_geometry="true">
<start_location>
<input_location id="1">
<input_address>
<us_form2 street="3001 Taraval St" city="San Francisco" state="CA" zip_code="94116" />
</input_address>
</input_location>
</start_location>
<end_location>
<input_location id="2">
<input_address>
<us_form1 street="3010 Geary Boulevard" lastline="san francisco, ca" />
</input_address>
</input_location>
</end_location>
</route_request>
Das Ergebnis sieht dann so aus:
Für die Spezifikation der Adressen (Element
input_address) gibt es verschiedene formatierte als auch unformatierte Eingabemöglichkeiten. Detaillierte Informationen dazu finden sich in der
Geocoding Request XML Schema Definition.
Für den Eistieg in das Routing mit Oracle Spatial will ich es mit diesen Ausführungen bewenden lassen. Probieren Sie es einfach aus.
P.S. Zum besseren Verständnis sind die verwendeten Umgebungsvariablen nachfolgend aufgeführt:
ORACLE_HOME=/home/oracle/app/oracle/product/11.2.0/dbhome_2
JAVA_HOME=/usr/java/latest
MW_HOME=/home/oracle/middleware
WL_HOME=/home/oracle/middleware/wlserver
