Wenn es darum geht, die Koordinaten in einer SDO_GEOMETRY-Spalte in ein anderes
Koordinatensystem umzurechnen, nutzt man SDO_CS.TRANSFORM - ein Beispiel:
Koordinatensystem umzurechnen, nutzt man SDO_CS.TRANSFORM - ein Beispiel:
create table m_admin_area4_t31467 as select feature_id, feature_name, area_id, name_langcode, feature_type, country_code_3, sdo_cs.transform(geometry, 31467) as geometry from m_admin_area4; Tabelle wurde erstellt. Abgelaufen: 00:06:14.40
Die Tabelle enthält knapp 14.000 Polygone - die Umrechnung dauerte etwas mehr als
6 Minuten. So weit, so gut. Die Frage wäre allerdings, ob es nicht noch schnellere
Varianten gibt - denn stellt man sich eine Tabelle mit 100.000 Polygonen vor, wären
wir schon bei einer Stunde - und so weiter und so fort.
Es ist nicht überall bekannt, dass es neben SDO_CS.TRANSFORM noch eine weitere
Funktion SDO_CS.TRANSFORM_LAYER gibt, welche eine ganze Tabelle auf einmal
umrechnet. TRANSFORM_LAYER soll lt. Dokumentation dabei effizienter arbeiten als TRANSFORM - dafür
ist der Umgang damit etwas aufwändiger. Testen wir das einmal: Die Tabelle, die
umrechnet werden soll, muss einen Eintrag in der View USER_SDO_GEOM_METADATA
haben - ein Spatial-Index dagegen kann, muss aber nicht vorhanden sein. Zuerst sollte
man dies überprüfen.
6 Minuten. So weit, so gut. Die Frage wäre allerdings, ob es nicht noch schnellere
Varianten gibt - denn stellt man sich eine Tabelle mit 100.000 Polygonen vor, wären
wir schon bei einer Stunde - und so weiter und so fort.
Es ist nicht überall bekannt, dass es neben SDO_CS.TRANSFORM noch eine weitere
Funktion SDO_CS.TRANSFORM_LAYER gibt, welche eine ganze Tabelle auf einmal
umrechnet. TRANSFORM_LAYER soll lt. Dokumentation dabei effizienter arbeiten als TRANSFORM - dafür
ist der Umgang damit etwas aufwändiger. Testen wir das einmal: Die Tabelle, die
umrechnet werden soll, muss einen Eintrag in der View USER_SDO_GEOM_METADATA
haben - ein Spatial-Index dagegen kann, muss aber nicht vorhanden sein. Zuerst sollte
man dies überprüfen.
select table_name, column_name, srid from user_sdo_geom_metadata where table_name like 'M_ADMIN%' TABLE_NAME COLUMN_NAME SRID -------------------------------- -------------------- ---------- M_ADMIN_AREA0 GEOMETRY 8307 M_ADMIN_AREA1 GEOMETRY 8307 M_ADMIN_AREA2 GEOMETRY 8307 M_ADMIN_AREA3 GEOMETRY 8307 M_ADMIN_AREA4 GEOMETRY 8307 : : :
Danach kann SDO_CS.TRANSFORM_LAYER ausgeführt werden.
begin
sdo_cs.transform_layer('M_ADMIN_AREA4', 'GEOMETRY', 'M_ADMIN_AREA4_DST', 31467);
end;
/
Abgelaufen: 00:01:38.95
Das ging schon wesentlich schneller - aber wenn wir uns die Ergebnistabelle ansehen,
dann bemerken wir schnell, dass wir noch nicht ganz fertig sind.
dann bemerken wir schnell, dass wir noch nicht ganz fertig sind.
SQL> desc M_ADMIN_AREA4_DST Name Null? Typ ----------------------------------------- -------- ---------------------------- SDO_ROWID ROWID GEOMETRY MDSYS.SDO_GEOMETRY
Denn diese Tabelle enthält die umgerechneten Geometrie-Objekte nebst einer ROWID aus
der Quelltabelle. Wenn man nun also die "finale" Tabelle erzeugen möchte, die
aus genau den gleichen Spalten wie die Quelltabelle besteht, so braucht es einen
weiteren Schritt.
der Quelltabelle. Wenn man nun also die "finale" Tabelle erzeugen möchte, die
aus genau den gleichen Spalten wie die Quelltabelle besteht, so braucht es einen
weiteren Schritt.
create table m_admin_area4_t31467 as select q.feature_id, q.feature_name, q.area_id, q.name_langcode, q.feature_type, q.country_code_3, i.geometry from m_admin_area4 q join m_admin_area4_dst i on (i.sdo_rowid = q.rowid) / Tabelle wurde erstellt. Abgelaufen: 00:00:20.68
Diese 20 Sekunden müssen noch hinzugerechnet werden - denn erst nun ist die
gewünschte Tabelle erstellt. Es ergeben sich also etwa 2 Minuten. Verglichen mit
den 6 Minuten und 14 Sekunden ist das doch eine erhebliche Verbesserung! Der Grund dafür
sind Initialisierungen, die bei SDO_CS.TRANSFORM immer wieder und bei TRANSFORM_LAYER
nur einmal aufgerufen werden. Allerdings ist
dieser Ansatz nicht für on-the-fly Transformationen geeignet, da man stets die
"Zwischentabelle" generieren muss. Aber im Rahmen von Ladeprozessen kann man hiermit
durchaus eine Menge Zeit sparen ...
gewünschte Tabelle erstellt. Es ergeben sich also etwa 2 Minuten. Verglichen mit
den 6 Minuten und 14 Sekunden ist das doch eine erhebliche Verbesserung! Der Grund dafür
sind Initialisierungen, die bei SDO_CS.TRANSFORM immer wieder und bei TRANSFORM_LAYER
nur einmal aufgerufen werden. Allerdings ist
dieser Ansatz nicht für on-the-fly Transformationen geeignet, da man stets die
"Zwischentabelle" generieren muss. Aber im Rahmen von Ladeprozessen kann man hiermit
durchaus eine Menge Zeit sparen ...
