Mdsys.sdo_relate Problem
Hi!
I'va got two Tables, one of them ("kante") has a Geometry - Column in it and a Quad - Tree Index is
Created, the other one ("kabelabschnitt") is linked to "kante" via a foreign key.
This Query is very fast:
SELECT k.* FROM kante k
where sdo_relate(geom, mdsys.sdo_geometry(2003,NULL,NULL, mdsys.sdo_elem_info_array(1,1003,3), mdsys.sdo_ordinate_array(34520, 253535, 34621, 253606)), 'mask=ANYINTERACT querytype=window') = 'TRUE';
But this takes about 20 s:
SELECT k.*, ka.* FROM kante k, kabelabschnitt ka
where ka.id_ka = k.id_kante
and sdo_relate(geom, mdsys.sdo_geometry(2003,NULL,NULL, mdsys.sdo_elem_info_array(1,1003,3), mdsys.sdo_ordinate_array(34520, 253535, 34621, 253606)), 'mask=ANYINTERACT querytype=window') = 'TRUE';
Can anynone tell me why??
Thanx in advance,
J
Hi,
It could be slower because the optimizer is choosing to use an index associated
with the join key between the tables instead of the spatial index.
Try adding the /*+ no_index (, index_name) */ hint, i.e.
SELECT /*+ no_index (K name_of_id_kante_index) k.*, ka.*
FROM kante k, kabelabschnitt ka
where ka.id_ka = k.id_kante
and sdo_relate(geom, mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(34520, 253535, 34621, 253606)),
'mask=ANYINTERACT querytype=window') = 'TRUE';
Hope this helps,
Dan
Similar Messages
-
Error using mdsys.sdo_relate()
Hi, I am using Oracle 8.1.5 and i am trying to execute the following sql statement
SQL> select p.name
2 from parks p
3 where mdsys.sdo_relate(p.shape,
mdsys.sdo_geometry(
3,null,null,
mdsys.sdo_elem_info_array(1,3,3),
4 mdsys.sdo_ordinate_array(10,10,20,20)),
5 'mask=anyinteract querytype=window')
= 'true';
But i recieved the following error message
ERROR at line 1:
ORA-29902: error in executing ODCIIndexStart() routine
ORA-13207: incorrect use of the [SDO_RELATE] operator
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 73
ORA-06512: at line 1
Do anyone know how to recify this?
Thanks!
nullOps, sorry it's TRUE not true
I managed to solved it. Thanks:>
brian
null -
Can mdsys.sdo_relate return FALSE?
I have the following query:
SELECT MIN (dtczas) dtczas
FROM sd_car_location
WHERE dyza_id = 2
AND dtczas > '24-JUN-2002 11:06:48'
AND mdsys.sdo_relate(
geom,
MDSYS.SDO_GEOMETRY( 2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3),
MDSYS.SDO_ORDINATE_ARRAY( 3734329.56686484, 5567865.09443332,
3735261.90177227, 5568277.30732063 )
'mask=ANYINTERACT querytype=WINDOW') = 'FALSE'
while executing this query I receive:
ORA-29902: error in executing ODCIIndexStart() routine
ORA-13207: incorrect use of the [SDO_RELATE] operator
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 84
ORA-06512: at line 1
so, is it possible to use sdo_relate in such way? When I try "<> 'TRUE'" or "AND NOT .... = 'TRUE'" index is not used.
Thanks in advance for help.
regards
KrzysztofIt is not possible. You must use ='TRUE'.
The reason for this is related to how the operators work.
First they do an index lookup to return the data that is
likely to interact, then they do further filtering to find the
data that actually interacts. All operators use the index
in this way.
If ='FALSE' was allowed, you'd get an answer that includes
only the geometries that were likely to interact (returned from
the index query), but that didn't interact, i.e. wrong answer.
You might be able to do something like this:
select min (dtczas) from
SELECT dtczas
FROM sd_car_location
WHERE dyza_id = 2
AND dtczas > '24-JUN-2002 11:06:48
MINUS
SELECT dtczas
FROM sd_car_location
WHERE dyza_id = 2
AND dtczas > '24-JUN-2002 11:06:48'
AND mdsys.sdo_relate(
geom,
MDSYS.SDO_GEOMETRY( 2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3),
MDSYS.SDO_ORDINATE_ARRAY( 3734329.56686484, 5567865.09443332,
3735261.90177227, 5568277.30732063 ) ),
'mask=ANYINTERACT querytype=WINDOW') = 'TRUE');
Hope this helps,
Dan -
Mdsys.sdo_relate slow, waiting on ALL_SDO_GEOM_METADATA
Database Oracle 8.1.7 Server Windows NT
Hello,
I have a query that uses sdo_relate which I have tested on two different oracle instances. On both instances I am testing the query on the same data. On one instance the query takes less that 10 seconds while on the second instance the query takes longer than then minutes.
Tracing the query on the second, slow instance shows many wait events while the server is executing the following query
PARSING IN CURSOR #3 len=126 dep=1 uid=346 oct=3 lid=346 tim=69164025 hv=1087985607 ad='48217d4'
SELECT DIMINFO FROM ALL_SDO_GEOM_METADATA WHERE OWNER = 'TESTUSER' AND TABLE_NAME = 'SPATIALTABLE' AND COLUMN_NAME = 'GEOM'
END OF STMT
PARSE #3:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=69164025
BINDS #3:
EXEC #3:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=69164029
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=319 p3=4
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=325 p3=2
WAIT #3: nam='db file scattered read' ela= 4 p1=1 p2=1515 p3=2
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=1518 p3=2
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=1528 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=7295 p3=2
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=7298 p3=6
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=12051 p3=2
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=12055 p3=8
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=12063 p3=3
WAIT #3: nam='db file scattered read' ela= 4 p1=1 p2=12651 p3=2
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=12654 p3=1
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=12656 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=12663 p3=4
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13307 p3=2
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13311 p3=8
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13319 p3=4
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13766 p3=8
WAIT #3: nam='db file sequential read' ela= 4 p1=1 p2=13774 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13776 p3=3
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=14163 p3=7
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=14171 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=14173 p3=4
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=14178 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=14643 p3=8
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=14651 p3=1
WAIT #3: nam='db file scattered read' ela= 4 p1=1 p2=14653 p3=2
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=15065 p3=2
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=16323 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=16326 p3=3
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=16334 p3=3
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=16338 p3=1
WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=18275 p3=1
WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=18277 p3=3
Is there some configuration change and tuning that I can do that will optimize this internal mdsys query?
It may be significant to note that the instance that the query is fast on is a 8.1.7.4 database, while the other is a 8.1.7.0. As well on the slow instance there are many more spatial indexes and many more entries in the table ALL_SDO_GEOM_METADATA.
Any suggestions?
Thanks in advance,
RickHi Rick,
I looked to see if there were any bug fixes between 8.1.7 and 8.1.7.4 regarding metadata fetching, and I didn't see anything that jumped out at me. That's not to say there weren't, however - I know there have been several metadata improvements that have been done over time.
Can you upgrade your 8.1.7 version to 8.1.7.4?
Thanks,
Dan -
is there anything that i can do to speed up the results of a
query such as this one. the civic table contains point data and
the parcels2 is polygons. Presently this query takes 23 secs
but the amount of pids can be much larger.
SELECT /*+ RULE */
CIVIC_ID,
PA.GEOMID
FROM MGIS.CIVIC C,
MGIS.PARCELS2 PA
WHERE PA.PID IN
('15710940','15706633','15706658','15706732','15706666','15706823
','15102726','15084833','15102734','15084783','15102742','1508446
0','15084411','15084841','15675713','15084429','15706781','150848
58','15102692','15084924','15084437','15084866','15084445','15102
684','15084916','15084874','15084452','15706740','15084908','1510
2676','15084882','15084890','15102668','15084932','15084940','157
10940','15710270','15710296','15102627','15101702','15706633','15
706807','15706815','15084726','15706658','15084734','15084601','1
5084593','15706773','15084585','15084742','15084544','15706799','
15084759','15084825','15084551','15084767','15084569','15084775',
'15084494','15696446','15706732','15706666','15084577','15084817'
,'15084486','15706823','15102700','15084809','15102726','15084791
','15084833','15084478','15102734','15084783','15102742','1508446
0','15084411','15084841','15675713','15084429','15706781')
AND SDO_RELATE(C.GEOM, PA.GEOM,'mask=ANYINTERACT
querytype=WINDOW') = 'TRUE'An excellent point about indexing PA.PID.
You might want to try the top part as:
select /*+ ordered */
CIVIC_ID,
PA.GEOMID
FROM MGIS.PARCELS2 PA,
MGIS.CIVIC C
Note the ordered hint, and reversing the table names in the from
clause. -
Problem with sdo_relate returning unexpected results
I am having a problem with an oracle spatial query not returning what I feel is an appropriate result.
I have a bounding box that has 6 points from a table that should be inside it. There are several hundred points total in this table. I perform the following query and oracle returns only 4 points, well 5 but we will get to that later, within the area of the search.
SQL> Select feature_id
From city_points A
where (MDSYS.SDO_RELATE(A.GEOM, mdsys.sdo_geometry(2003, 8307, NULL, mdsys.sdo_elem_info_array(1,1003,1), mdsys.sdo_ordinate_array(-101.8417,-52.8083,-23.8417,-52.8083,-23.8417,-13.8083,-101.8417,-13.8083,101.8417,-52.8083)), 'mask=ANYINTERACT querytype=join') = 'TRUE');
I used a different application to perform the same type of query. The difference is that the application does the spatial query, not oracle. Further the application gets all of the points and performs this query on the client. What the application returns is correct both visually and spatially.
Two of the points not returned in the oracle spatial query are 300km inside the bounding box. This far exceeds the .5 m tolerance used in our decimal degrees data set (SRID 8307).
I have experienced this problem on 9.2.0.1. I then patched that instance to 9.2.0.7 and duplicated the problem. I then exported the data and imported into a 10g release 1 database and again duplicated the problem. I have tried to re-index the data to no avail.
I have also tried different querytypes also yielding less than expected results.
The data looks like this:
243
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-58.45, -34.6, NULL),NULL, NULL)
254
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-56.18333, -34.883334, NULL), NULL, NULL)
377
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-70.666671, -33.449999, NULL), NULL, NULL)
385
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-68.149999, -16.5, NULL), NULL, NULL)
388
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-47.916667, -15.783333, NULL), NULL, NULL)
427
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-57.640066, -25.270295, NULL), NULL, NULL)
The number is the id field, the rest is the geometry.
The oracle spatial query above only returns id #s 359, 377,243,254,427
There are five returned records. The extra value is outside the bounding area. So it should not have been returned at all. It is all too strange.
I have seen this with different geometry types (points lines and area) as well.
If anyone has suggestions, I would appreciate your comments.
Thanks,
JohnJohn,,
What you are seeing is the behavior you should expect in the geodetic space.
When you have a very long line connecting from longitude -101 to -23, that line
does not follow the same latitude value.
Since these points are in southern hemisphere, the line connecting them
will curve downward (this is the great circle line).
If you really want a line connecting with constant latitude, you should
use the MBR type for the window geometry which densifies the
lines along constant latitude before passing it into relate.
SDO_GEOMETRY(2003, 8307, NULL,
sdo_elem_info_array(1,1003,3),
sdo_ordinate_array(-101.8417,-52.8083, 23.8417,-13.8083))
siva -
ORA-21779: duration not active error line 25 of MDSYS.AGGRUNION
I execute the following pl/sql (line 56/57 in
a procedure called RebuildSMZLabels)....
v_query := 'SELECT /*+ INDEX ( A BASE_SMZ_A_SHAPE ) NO_INDEX ( A BASE_SMZ_A_RETIREDATE ) */ MDSYS.SDO_AGGR_UNION(MDSYS.SDOAGGRTYPE(a.s
hape,:1)) FROM &owner.base_smz_a A WHERE MDSYS.SDO_RELATE(a.shape,:2,''mask=ANYINTERACT querytype=window'') = ''TRUE'' and retiredate is
null';
EXECUTE IMMEDIATE v_query INTO v_union_shape USING v_diminfo(1).sdo_tolerance, v_trans_shape ;
And I get...
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
DECLARE
ERROR at line 1:
ORA-21779: duration not active
ORA-06512: at "MDSYS.AGGRUNION", line 25
ORA-06512: at "MDSYS.AGGRUNION", line 25
ORA-06512: at line 1
ORA-06512: at "MDCADM.REBUILDSMZLABELS", line 57
ORA-06512: at line 5
Got me beat... anyone got any ideas?
Simon Greener
GIS Manager
Forestry TasmaniaDan
I reverted to the old 8i code (with individual
UNIONS) and it still fails:
DECLARE
ERROR at line 1:
ORA-21779: duration not active
ORA-06512: at "MDSYS.SDO_3GL", line 439
ORA-06512: at "MDSYS.SDO_GEOM", line 3096
ORA-06512: at "MDCADM.REBUILDSMZLABELS", line 74
ORA-06512: at line 5
Line 74 is:
v_union_shape := MDSYS.SDO_GEOM.SDO_UNION(v_union_shape,v_diminfo,v_shape,v_diminfo);
Any ideas as I need this to work in 9i ASAP (as it
doesn't work in 8i)?
PS Dan, it is the same database/code problem I sent
to you earlier this year. It is getting to the point
that I am going to have to rebuild all this database
centric code (which is where it needs to be in the
business process) within our GIS (ArcInfo) which is going
to be far more complex and not sustainable in the medium
term.
regards
Simon -
Sdo_relate in alternate user with views.
Hello,
I am using Oracle 8.1.7.2 and creating a view as follows.
CREATE OR REPLACE VIEW REPORT_STREETINFO AS
SELECT DT.ID, MKT.CODE MKT_CODE, PRIM_NAME,
NVL(MIN(DECODE(ST.FROMNRLE, 0, NULL, ST.FROMNRLE)),0)
MIN_FROMNRLE,
MAX(ST.TONRLE) MAX_TONRLE,
NVL(MIN(DECODE(ST.FROMNRRI, 0, NULL, ST.FROMNRRI)),0)
MIN_FROMNRRI,
MAX(ST.TONRRI) MAX_TONRRI,
MKT.NAME MKT_NAME, MKT.NAME2 MKT_NAME2, MKT.STREET MKT_STREET,
MKT.CITY MKT_CITY,
MKT.ZIP MKT_ZIP,
MKT.PO_BOX MKT_POBOX
FROM STREETINFO ST, DISTAREA DT, MARKET MKT, DISTAREA_WA
DTWA,WALKERAREA WA
WHERE PRIM_NAME IS NOT NULL AND
(ST.FROMNRLE != 0 AND ST.TONRLE != 0 OR
ST.FROMNRRI != 0 AND ST.TONRRI != 0) AND
DTWA.DISTAREA_ID = DT.ID AND
WA.WASID = DTWA.WASID AND
MKT.SRNO = DT.MARKET_ID AND
MDSYS.SDO_RELATE(ST.GEOLOC, WA.GEOLOC, 'mask=
(inside+coveredby+on)
querytype=window') = 'TRUE'
GROUP BY PRIM_NAME, MKT.CODE, DT.ID,
MKT.NAME, MKT.NAME2, MKT.STREET, MKT.CITY, MKT.ZIP, MKT.PO_BOX
ORDER BY PRIM_NAME
I grant the rights to this above view to an alternate user. When
I fire a query like
SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 22;
from the owner of the view I have no problems but when I fire
this query from alternate user I get error
ORA-03113 end-of-file on communication channel.
I checked out the documentation which states from physical
failure but this is definately not the case.
Any help on this problem will be appretiated.
Amol.Hello Ravi,
I am posting a spool file which shows the steps I have followed
and error that I get. I have taken care with the grants from
mdsys for the SDO_RELATE and all the other operators.
DEV>SHO USER
USER ist "GEODIS"
DEV>CREATE OR REPLACE VIEW REPORT_STREETINFO AS
2 SELECT DT.ID, MKT.CODE MKT_CODE, PRIM_NAME,
3 NVL(MIN(DECODE(ST.FROMNRLE, 0, NULL, ST.FROMNRLE)),0)
MIN_FROMNRLE,
4 MAX(ST.TONRLE) MAX_TONRLE,
5 NVL(MIN(DECODE(ST.FROMNRRI, 0, NULL, ST.FROMNRRI)),0)
MIN_FROMNRRI,
6 MAX(ST.TONRRI) MAX_TONRRI,
7 MKT.NAME MKT_NAME, MKT.NAME2 MKT_NAME2, MKT.STREET
MKT_STREET, MKT.CITY MKT_CITY,
8 MKT.ZIP MKT_ZIP,
9 MKT.PO_BOX MKT_POBOX
10 FROM STREETINFO ST, DISTAREA DT, MARKET MKT, DISTAREA_WA
DTWA,WALKERAREA WA
11 WHERE PRIM_NAME IS NOT NULL AND
12 (ST.FROMNRLE != 0 AND ST.TONRLE != 0 OR
13 ST.FROMNRRI != 0 AND ST.TONRRI != 0) AND
14 DTWA.DISTAREA_ID = DT.ID AND
15 WA.WASID = DTWA.WASID AND
16 MKT.SRNO = DT.MARKET_ID AND
17 MDSYS.SDO_RELATE(ST.GEOLOC, WA.GEOLOC, 'mask=
(inside+coveredby+on)
18 querytype=window') = 'TRUE'
19 GROUP BY PRIM_NAME, MKT.CODE, DT.ID,
20 MKT.NAME, MKT.NAME2, MKT.STREET, MKT.CITY, MKT.ZIP,
MKT.PO_BOX
21 ORDER BY PRIM_NAME
22 /
View wurde angelegt.
DEV>SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108;
PRIM_NAME
Altenhagener
Weg
Alter
Zollweg
Am
Knill
Am
Kroog
Am
Lehmberg
Babenstieg
Bargteheider
Strasse
Bekassinenau
Blomeweg
Boltenhagener
Strasse
Bublitzer
Strasse
Carlssonweg
Farmsener
Zoll
Finkenfurth
Grvmitzer
Weg
Grundherrenstrasse
Herwardistrasse
Hohenkamp
Hoher
Berg
Im
Wiesengrund
Jacobshagener
Weg
Kohvvedstrasse
Kvsliner
Strasse
Krohnsheide
K|hlungsborner
Strasse
Nienhagener
Strasse
Pfefferstrasse
Rahlstedter
Stieg
Rahlstedter
Weg
Raschweg
R|genwalder
Strasse
Rummelsburger
Strasse
Sandkule
Scharbeutzer
Strasse
Sierksdorfer
Strasse
Stargarder
Strasse
Thiessenweg
Timmendorfer
Stieg
Timmendorfer
Strasse
Treptower
Strasse
Wolliner
Strasse
41 Zeilen ausgewdhlt.
DEV>GRANT SELECT ON REPORT_STREETINFO TO PWEIH;
Benutzerzugriff (Grant) wurde erteilt.
DEV>CREATE SYNONYM PWEIH.REPORT_STREETINFO FOR
GEODIS.REPORT_STREETINFO;
Synonym wurde angelegt.
DEV>CONN PWEIH/PWEIH@DEVELOP
Connect durchgef|hrt.
DEV>DESC REPORT_STREETINFO;
Name Null? Typ
ID NOT NULL NUMBER(10)
MKT_CODE VARCHAR2(10)
PRIM_NAME VARCHAR2(40)
MIN_FROMNRLE VARCHAR2(40)
MAX_TONRLE NUMBER
MIN_FROMNRRI VARCHAR2(40)
MAX_TONRRI NUMBER
MKT_NAME VARCHAR2(40)
MKT_NAME2 VARCHAR2(40)
MKT_STREET VARCHAR2(40)
MKT_CITY VARCHAR2(40)
MKT_ZIP VARCHAR2(9)
MKT_POBOX VARCHAR2(40)
DEV>SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108;
SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108
FEHLER in Zeile 1:
ORA-03113: Unerwartetes \bertragungsende in Kommunikation
DEV>SPOOL OFF;
Regards,
Amol. -
SDO_RELATE and ORA-03113 error
Hello,
I am trying to use the SDO_RELATE function and I receive the following error:
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Using the following SQL
SELECT ufi FROM ROADLINE A
WHERE MDSYS.SDO_RELATE(
A.GEOMETRY, mdsys.sdo_geometry( 2003,null,null,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(132,-12,133,-11)),
'mask=ANYINTERACT querytype=WINDOW') = 'TRUE'
A similar search using the SDO_FILTER instead of SDO_RELATE and removing the mask=ANYINTERACT works ok.
Can anyone suggest anything?
Thanks in advance.
GunterHi Gunter,
It looks like there may be other issues. Can you post the version of Oracle you are using, and try debugging just a little bit more to try to narrow the problem down?
This might help to determine which geometry the failure is occuring at:
create table tt as select ufi,geometry
from roadline where rownum < 1;
declare
ufi number ;
window_geom mdsys.sdo_geometry := mdsys.sdo_geometry( 2003,null,null, mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(132,-12,133,-11));
theGeom mdsys.sdo_geometry ;
TYPE geomcursor is REF CURSOR ;
aCursor geomcursor;
relationship varchar2(30);
begin
open aCursor FOR 'SELECT ufi, geometry from roadline A WHERE SDO_filter( A.GEOMETRY,:WINDOW_GEOM, ''querytype=WINDOW'') = ''TRUE''' using window_geom;
loop
FETCH aCursor INTO ufi, theGeom ;
EXIT WHEN aCursor%NOTFOUND ;
execute immediate 'insert into tt values (:ufi,:theGeom)'
using ufi,theGeom;
execute immediate 'commit';
relationship := sdo_geom.relate(theGeom,'anyinteract',window_geom,0.05);
end loop;
end;
If you see the same error, hopefully it will be determining the relationship between the last geometry in the table tt and the query window. If you can check this, and if this is the case post the geometry that is failing as well as the contents of user_sdo_geom_metadata for roadline that would be great.
Dan -
Sdo.intersection ... problems
Hi all,
I use this simple query:
CREATE TABLE INTER2 AS
SELECT SDO_GEOM.SDO_INTERSECTION(G1.SHAPE, G2.SHAPE, 0.005) SHAPE
FROM RAIL G1, ROADS G2;
to find the intersections between these two layers. The first layer (rail) contains 47 lines and the second one (roads) 78 lines.
The new table that is constructed by running this query has 3666 rows (I think that this is because 78x47=3666) but when I visualize the layer in the spatial in the spatial index advisor I can see that only 40 points (intersections) exists.
So, I suppose that this query checks every possible pair from the two layers and creates a row which either has a point (intersection) in the shape column or has null value in this column.
My problem is that this layer cannot be inserted into ARCINFO (throught ARCSDE) because of its structure (every row must have a shape - geometry).
Can anyone tell me how can I perform this query and have as a result ONLY the rows with the points (intersections of the two layers)so I can visualize it in ARCINFO?
Thanks in advanceHello John:
Seems like you are missing something from your query. I think it would help eliminate those records that do not return a SHAPE by using SDO_RELATE in your where clause. The query would look something like this:
CREATE TABLE INTER2 AS
SELECT SDO_GEOM.SDO_INTERSECTION(G1.SHAPE, G2.SHAPE, 0.005) SHAPE
FROM RAIL G1, ROADS G2
WHERE
MDSYS.SDO_RELATE(G1.SHAPE, G2.SHAPE, 'mask=ANYINTERACT querytype=WINDOW') = 'TRUE';
BUT - you may have to "trick" ArcSDE into recognizing the table (or should I say "feature class"). You may have to use an ArcSDE command to create the feature class, then go into SQL and drop the table. This has the effect of putting the correct metadata into the SDE schema tables, such as LAYERS and SPATIAL_REFERENCES. When you drop the table using SQL, the metadata will remain.
Then, use the CREATE TABLE... to create and populate the "feature class". Be sure to create a spatial index - we have found that you do not have to use the same name for the index as the one created by ArcSDE when you did the ArcSDE command to create the "feature class".
This trickery is necesarry because ArcSDE really prefers that EVERYTHING is created and populated via ArcSDE commands or ArcCatalog, but there are ways to "fool" the ESRI software.
Let me know if this helps.
R Clement
Alaska DNR -
Geomtry to mdsys.sdo_geometry
Hi, i'm a newbie of Oracle Spatial, i'm working with sdoapi, i need to convert
geometries encoded with GML into valid geometries encoded in msdsys.sdo_geometry
to perform query throug SQL over other geoemtries stored into a table.
For example, if i've a box geometry in GML like this:
<gml:Box>
<gml:coord>
<gml:X>-103</gml:X>
<gml:Y>31</gml:Y>
</gml:coord>
<gml:coord>
<gml:X>-103.5</gml:X>
<gml:Y>31.5</gml:Y>
</gml:coord>
</gml:Box>
I would make a query like:
SELECT a.geometry
FROM My_Spatial_Table a
WHERE mdsys.sdo_relate(a.geometry, mdsys.sdo_geometry (2003, null, null,mdsys.sdo_elem_info_array (1,1003,3),mdsys.sdo_ordinate_array (-103,31,-103.5,31.5)),'querytype=WINDOW layer_gtype=notpoint') = 'TRUE';
I've look in sdoapi's samples that i can make an adapter from my
GML (XML) to Oracle's geometry, now i would know if i can map
this geometry into a mdsys.sdo_geometry form.
For geometries like point, box, there's no problems, but for geometries
like polygon, linestring, multipolygon i don't know how do this! :-(
Any tips or documentation for my problem?
Best Regards
LuigiAre you positive that the data is only being saved
with 6 places of precisions ?
As far as I remember SQLPlus only displays up to 6
decimal points, although there are more in the data.
I remember a similar thread on this before where
there was a Tip that suggested setting the SQLPlus
number format highr in order to display the full
coordinates.
e.g. SET NUMFORMAT 9999999999999999.99999999999999999999999;
Ro -
HELP!! SDO_RELATE inside Oracle procedure - ORA-13207: incorrect use of the
Hello,
I need help !
I have a problem with queries inside procedures/packages.
When execute sql
SQL> SELECT LOC_OBJ_ID
2 FROM VORO_LOC X, LBS_OZ_AREAS OZ
3 WHERE MDSYS.SDO_RELATE(X.SHAPE, OZ.GEOLOC, 'MASK=ANYINTERACT') = 'TRUE'
4 AND OZ.OZ_NAME='PTK' AND OZ.OZ_GROUP='GORCZEWSKA';
LOC_OBJ_ID
2211379
i have results - it's OK
The next sql is same, but with agregation
SQL> SELECT COUNT(*) ILOSC
2 FROM VORO_LOC X, LBS_OZ_AREAS OZ
3 WHERE MDSYS.SDO_RELATE(X.SHAPE, OZ.GEOLOC, 'MASK=ANYINTERACT') = 'TRUE'
4 AND OZ.OZ_NAME='PTK' AND OZ.OZ_GROUP='GORCZEWSKA';
ILOSC
1
it's OK
But when i want use this SQL inside proedurees in store result in variable i have problem
SQL> declare
2 V_NUMBER_NEI_LOC number;
3 begin
4 SELECT COUNT(*) ILOSC
5 INTO V_NUMBER_NEI_LOC
6 FROM VORO_LOC X, LBS_OZ_AREAS OZ
7 WHERE MDSYS.SDO_RELATE(X.SHAPE, OZ.GEOLOC, 'MASK=ANYINTERACT') = 'TRUE'
8 AND OZ.OZ_NAME='PTK' AND OZ.OZ_GROUP='GORCZEWSKA';
9 end;
10 /
declare
ORA-13207: incorrect use of the [SDO_RELATE] operator
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 259
ORA-06512: at line 4
ORA-06512: at line 4
Please help!This might be some issue with SQL in PL/SQL. We will check into this.
In the meantime, can you try the dynamic SQL to execute that
sdo_relate query to see if it works?
Here is the example with dynamic SQL:
declare
V_NUMBER_NEI_LOC number;
begin
EXECUTE IMMEDIATE
' SELECT COUNT(*) ILOSC ' ||
' FROM VORO_LOC X, LBS_OZ_AREAS OZ ' ||
' WHERE MDSYS.SDO_RELATE(X.SHAPE, OZ.GEOLOC, ' ||
' ''MASK=ANYINTERACT'') = ''TRUE'' ' ||
' AND OZ.OZ_NAME=''PTK'' AND OZ.OZ_GROUP=''GORCZEWSKA'' '
INTO V_NUMBER_NEI_LOC;
end;
/ -
Splitting dataset into regions using sdo_relate
Hi all,
I am having difficulty subdividing my dataset into different regions. I have the spatial data of the city auckland and found the co-ordinates of the lower left and upper right limits of the data. What I want to do now is to break up this dataset into 9 individual regions and assign an ID for each region. I have been trying to use to following query with not much luck...
select a.link_id from nz_testlinks_auck a where mdsys.sdo_relate(a.GEOM,
mdsys.SDO_GEOMETRY (2003,null,null,mdsys.SDO_ELEM_INFO_ARRAY(1,1003,3),
mdsys.SDO_ORDINATE_ARRAY(174.7083,-37.0141,174.7910,-36.9544)), 'mask=ANYINTERACT querytype=WINDOW')='TRUE';
When i put the outputted data into a table and view the data i notice that the rectangle has selected a lot more data than what was actually defined in the query. I have been using the network data model editor and MapBuilder to check the data and the co-ordinates.
And when i try to create another rectangle for another region next to the previous one like this...
select a.link_id from nz_testlinks_auck a where mdsys.sdo_relate(a.GEOM,
mdsys.SDO_GEOMETRY (2003,null,null,mdsys.SDO_ELEM_INFO_ARRAY(1,1003,3),
mdsys.SDO_ORDINATE_ARRAY(174.7910,-37.0141,174.8736,-36.9544)), 'mask=ANYINTERACT querytype=WINDOW')='TRUE';
it again selects a larger rectangle selecting about half the data from the previous rectangle selection as well.
Please assist me to solve this problem.
Look forward to your replies.
AvinashAvinash,
Do you have geometries that cross your rectangle boundary, like a long line, or a large polygon? Which rectangle would you expect such a line or polygon to appear in?
Or are you saying that geometries that are completely disjoint from your rectangle are getting selected? If you think that's the case, try the sdo_geom.relate function with the 'determine' mask to verify the relationship between your rectangle and one of the unexpected geometries.
http://download.oracle.com/docs/html/B14255_01/sdo_objgeom.htm#BGHCDIDG
If you want to be sure that nothing gets selected twice by your rectangles the ANYINTERACT mask probably isn't a good choice. A mask of mask=INSIDE+COVEREDBY will be better, but you'll still have to decide what to do with stuff that crosses.
Matt -
Problems with geometries of type 0
Hi All,
We have a problem with Oracle Spatial (8.1.6 Object-relational) Functions and operators on data consisting both
standard Oracle geometry types and elements of "unknown" type, wich the functions seem not to ignore, as the
documentation says it is supposed to do.
Below you can se examples with extent_of analysis of layers and sdo_relate queries. It seems the "unknown" type
elements are read as geometries, and when an "unknown" is present following geometries are ignored. Have any of you
seen this before or even better have a solution?
Thanks
-- Test with extent_of
-- Create table for test geometries
Drop table geom_test;
create table geom_test
(id number,
GEOMETRY mdsys.sdo_geometry);
-- Populate sdo_geom_metadata
delete from user_sdo_geom_metadata
where table_name='GEOM_TEST'
and column_name='GEOMETRY';
insert into user_sdo_geom_metadata
values ('GEOM_TEST', 'GEOMETRY',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('X', -380000000, 10, 1),
MDSYS.SDO_DIM_ELEMENT('Y', 0, 380000000, 1)),
null);
-- Test with no "unknown" elements
delete from geom_test;
insert into geom_test (id,geometry)
values(148855,
mdsys.sdo_geometry
(1, null, null,
mdsys.sdo_elem_info_array(1,1,1),
mdsys.sdo_ordinate_array(-253423935,216615534))
Select mdsys.sdo_tune.extent_of('GEOM_TEST', 'GEOMETRY') from dual;
-- Test with one "unknown" elements
delete from geom_test;
insert into geom_test (id,geometry)
values(148855,
mdsys.geometry
(2004, null, null,
mdsys.sdo_elem_info_array
(1,0,6000,
4,1,1),
mdsys.sdo_ordinate_array
(.956304,.292373,0,
-253423935,216615534))
Select mdsys.sdo_tune.extent_of('GEOM_TEST', 'GEOMETRY') from dual;
-- Test with two "unknown" elements
delete from geom_test;
insert into geom_test (id,geometry)
values(148855,
mdsys.geometry
(2004, null, null,
mdsys.sdo_elem_info_array
(1,0,6000,
4,1,1,
6,0,6000,
9,1,1),
mdsys.sdo_ordinate_array
(.956304,.292373,0,
-253423935,216615534,
.956304,.292373,0,
-254019015, 216442514))
select mdsys.sdo_tune.extent_of('GEOM_TEST', 'GEOMETRY') from dual;
-- sdo_relate test
-- Create table for test geometries
Drop table geom_test2;
create table geom_test2
(id number,
GEOMETRY mdsys.sdo_geometry);
-- Populate sdo_geom_metadata
delete from user_sdo_geom_metadata
where table_name='GEOM_TEST2'
and column_name='GEOMETRY';
insert into user_sdo_geom_metadata
values ('GEOM_TEST2', 'GEOMETRY',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('X', -380000000, 10, 1),
MDSYS.SDO_DIM_ELEMENT('Y', 0, 380000000, 1)),
null);
-- Populate dataset
delete from geom_test2;
insert into geom_test2 (id,geometry)
values(1,
mdsys.sdo_geometry
(1, null, null,
mdsys.sdo_elem_info_array(1,1,1),
mdsys.sdo_ordinate_array(-253423935,216615534))
insert into geom_test2 (id,geometry)
values(2,
mdsys.sdo_geometry
(2004, null, null,
mdsys.sdo_elem_info_array
(1,0,6000,
4,1,1),
mdsys.sdo_ordinate_array
(.956304,.292373,0,
-253423935,216615534))
insert into geom_test2 (id,geometry)
values(3,
mdsys.sdo_geometry
(2004, null, null,
mdsys.sdo_elem_info_array
(1,0,6000,
4,1,1,
6,0,6000,
9,1,1),
mdsys.sdo_ordinate_array
(.956304,.292373,0,
-253423935,216615534,
.956304,.292373,0,
-254019015, 216442514))
select mdsys.sdo_tune.extent_of('GEOM_TEST2', 'GEOMETRY') from dual;
drop index g_test2_spatidx;
create index g_test2_spatidx on geom_test2(GEOMETRY)
indextype is mdsys.spatial_index parameters
('sdo_level=4, sdo_commit_interval=1000, tablespace=indx');
-- Query by expected coordinates
select id
from geom_test2
where mdsys.sdo_relate
(geometry,
mdsys.sdo_geometry
(3,null,null,
mdsys.sdo_elem_info_array(1,3,3),
mdsys.sdo_ordinate_array(-250000000,210000000,-260000000,220000000)),
'mask=ANYINTERACT')='TRUE';
--Query by "unknown" type values
select id
from geom_test2
where mdsys.sdo_relate
(geometry,
mdsys.sdo_geometry
(3,null,null,
mdsys.sdo_elem_info_array(1,3,3),
mdsys.sdo_ordinate_array(0,0,1,1)),
'mask=ANYINTERACT')='TRUE';
nullHi,
This is a bug in the Oracle Spatial object model. A workaround for now is to
declare you etype 0's at the end of your ordinate array.
Correct expected behavior is for Oracle Spatial is for any non-zero SDO_GTYPE,
ignore all zero ETYPES.
We will try to get a fix into 8.1.7, and definitely into 8.2. Hope this helps. Thanks.
Dan
null -
SDO_FILTER and SDO_RELATE combined in the same query
Is it possible to combine these two operations?
I have a query that ideally should use SDO_RELATE for polygon data (some 25 million records). However it takes too long to run.
For curiosity's sake I tried using SDO_FILTER and again this takes hours. Again for curiosity's sake I combined the two and records are returned in about 2 mins. Please see the query below (to simplify matters I have used point data).
SELECT
FROM
table t
WHERE
MDSYS.SDO_RELATE(
t.geometry,
MDSYS.SDO_GEOMETRY( 2001,
null,
MDSYS.SDO_POINT_TYPE( 501900, 308000, null ),
null,
null
'mask=anyinteract querytype=WINDOW'
) = 'TRUE'
AND MDSYS.SDO_FILTER(
t.geometry,
MDSYS.SDO_GEOMETRY( 2001,
null,
MDSYS.SDO_POINT_TYPE( 501900, 308000, null ),
null,
null
'mask=anyinteract querytype=WINDOW'
) = 'TRUE'
As I see it, in this case SDO_FILTER is doing the primary filtering part. SDO_RELATE is doing primary filtering again followed by secondary filtering the resulting data which is why it is quicker. The data does appear to be correct.
Now am I barking up the wrong tree? Whether I am or not, why is this combination faster than individual use? I would appreciate any thoughts on this please.
Cheers guys
Jamessomething else is going on, although without seeing the real query it is hard to know.
SDO_RELATE is a supoerset of SDO_FILTER. With SDO_FILTER and index query is done, with SDO_RELATE an index query is done, then the relate is done on the geometries returned by the filter query.
What kind of index are you using?
What version of spatial are you using?
Can you post the query window?
Are your geometries valid?
Maybe you are looking for
-
How can I keep my iMac on the wireless network when it goes to sleep?
I have a new iMac (from Santa) and when it goes to sleep, so does its wifi connection. I use it for work and need to keep my instant messaging app open and running at all times, even when it's asleep. I also like to have all of my email waiting in t
-
When I try using Airplay to stream from Amazon Prime it tries to use Apple TV music. How can I get it it stream movies from Amazon Prime?
-
Copa derivation rule not working for Discount GL
Hi All, Kindly note that I have a distribution rule where company & plant combination is used where condtion is that customer group 3 should be 018 and then replace distribution channel to 03.However the rule is not working for discount GL posted in
-
With contacts who have more than 1 number assigned to them, I dial their name on the main screen, and then press the Send button, which is supposed to show me the various phone number choices to dial. It stopped doing this, and doesn't do anything un
-
Dealer Management System,Dealer Communication System,Spare Part System SAP?
Hi, Can anybody explain me "what are the oppurtunities for Dealer Management System(DMS), Dealer Communication System(DCS) and Spare Part System(SPS) on SAP ? All are for Auto and Track Dealers ? Thanks and best regards, Behcet Ahmet Aksoz.