Sdo_geom.relate operator (urgently)

i have got two roads features one from large scale second from small scale
my task is to extract features of common means intersection
i have drawn a buffer around the small scale feature
which has two records
NO UFI
1 BB06104925
2 BB06104928
other one
PFI
6318226
6028689
6028840
6029048
6029568
6030661
6029625
6029336
6318213
insert into integ_roads11 (pfi, ufi, geom) ( select b.pfi, c.ufi, c.geom from ora_tr_roads2 b, b_rectangle1 c
where b.pfi=lv_objectid and c.ufi=mv_ufi and
sdo_geom.relate( b.geom, 'inside', c.shape, 0.05)='INSIDE');
so logically it should return this values against becaseu this location is corresponding against to tose features BB06104925
PFI UFI
6318226 BB06104925
6028689 BB06104925
6028840 BB06104925
so logically it should return this values against BB06104929
PFI UFI
6029048 BB06104929
6029568 BB06104929
6030661 BB06104929
6029625 BB06104929
6029336 BB06104929
6318213 BB06104929
but this query doesnt give this output it retrieves
PFI UFI
6318226 BB06104925
6028689 BB06104925
6028840 BB06104925
6029048 BB06104925
6029568 BB06104925
6030661 BB06104925
6029625 BB06104925
6029336 BB06104925
6318213 BB06104925
PFI UFI
6318226 BB06104929
6028689 BB06104929
6028840 BB06104929
6029048 BB06104929
6029568 BB06104929
6030661 BB06104929
6029625 BB06104929
6029336 BB06104929
6318213 BB06104929
can anybody catch my error in this query.
Regards

I have got two Road features (GEo_Road, Road25). Road25 from large scale database and Geo_roads from small scale database. both occupied the same space.
my task is to extract features of common area means intersection from both features. The two roads might have some common area so i want to extract those area.
i have drawn a buffer around the small scale (Geo_Road) feature
which has two records. And then i used sdo_relate funtion to extract all those features from tr_roads which will come inside these buffer . ANd insert these values into another feature class. i have shown records of original tables but didnt copy the sdo field. I have created a small procedure which will work if i select "BB06104925" ufi from "geo_roads" then the control will pass to other database through cursor command and i used step 3 query and this query should give output as step 4. But the query gives output as displayed in step 5. Which is wrong. Sure this will help to understand. If not then i will give more details but plz i need an immediate help. Thanx
1. GEO_roads Table and data
NO UFI
1 BB06104925
2 BB06104928
2 .other one (TR_ROADS)
PFI
6318226
6028689
6028840
6029048
6029568
6030661
6029625
6029336
6318213
3. insert into integ_roads11 (pfi, ufi, geom) ( select b.pfi, c.ufi, c.geom from ora_tr_roads2 b, b_rectangle1 c
where b.pfi=lv_objectid and c.ufi=mv_ufi and
sdo_geom.relate( b.geom, 'inside', c.shape, 0.05)='INSIDE');
so logically it should return this values against becaseu this location is corresponding against to tose features BB06104925.
4. PFI UFI
6318226 BB06104925
6028689 BB06104925
6028840 BB06104925
so logically it should return this values against
5. BB06104929
PFI UFI
6029048 BB06104929
6029568 BB06104929
6030661 BB06104929
6029625 BB06104929
6029336 BB06104929
6318213 BB06104929
but this query doesnt give this output it retrieves
6.
PFI UFI
6318226 BB06104925
6028689 BB06104925
6028840 BB06104925
6029048 BB06104925
6029568 BB06104925
6030661 BB06104925
6029625 BB06104925
6029336 BB06104925
6318213 BB06104925
PFI UFI
6318226 BB06104929
6028689 BB06104929
6028840 BB06104929
6029048 BB06104929
6029568 BB06104929
6030661 BB06104929
6029625 BB06104929
6029336 BB06104929
6318213 BB06104929
can anybody catch my error in this query.
Regards

Similar Messages

Please reply: Why are indices not supported in sdo_geom.relate?

Hi,
I read somewhere in the newsgroup that the spatial indicesa re
used in the sdo_relate operator but not in the sdo_geom.relate
function. Could someone please let me know why this difference?
Thanks,
Hemant.R

Hi,
The SDO_GEOM.RELATE function should be used when comparing a
small number of geometries geometries with an area-of-interest.
The SDO_RELATE operator should be used when comparing an
area-of-interest with a layer, and it will use the index on the
layer.
There are reasons why the SDO_GEOM.RELATE function exists. If
you have two geometries that were created as part of an
application, however they aren't stored in a table and neither
one is indexed, sdo_geom.relate is a convenient way of testing or
determining what the relationship is between the geometries.
Regarding the SDO_LEVEL you are using for indexing - 17 seems
pretty high, and it might take a long time to create an index at
level 17 using geometries the size of states - you might want to
try increasing the SDO_LEVEL from 8 to 10 and see if that makes a
difference before going higher.
One thing you can do is look at the geometries using Spatial
Index Advisor - you can also see the fixed size tiles and do some
queries to get a sense of the amount of work being done by the
index as well as the work being done in the relate portion of the
operator.
Hope this helps,
Dan

Can you explain SDO_RELATE and SDO_GEOM.RELATE differences?

Ok, so I'm doing some spatial queries identifying geometries that interact with each other, and everything's groovy until the customer says, ok, get rid of the ones that just touch, which means that a call to SDO_RELATE with an ANYINTERACT mask no longer does the trick. First we tried setting a multiple mask and those queries ran like 9 hours. I figured that since we're burning that much time, we might as well build a table that stores the interaction as identified by DO_GEOM.RELATE with a DETERMINE mask.
Then I noticed an odd thing happening on the way to the forum. For some geometries I get SDO_RELATE with ANYINTERACT returning TRUE and then SDO_GEOM.RELATE returns DISJOINT with the same tolerance that is coded in the metadata (0.5). When tolerance is bumped up to 27, I get TOUCH back. The funny thing is that there are 3 geometries involved here, the reference geom, one that yields TOUCH, and the one that yields DISJOINT.
Stepping back from this behavior, doing some head-scratching and chin-stroking, I ran accross this statement in the Oracle® Spatial User's Guide and Reference 10g Release 2 (10.2) [here.|http://download.oracle.com/docs/html/B14255_01/sdo_operat.htm#i78531]
Unlike with the SDO_GEOM.RELATE function, DISJOINT and DETERMINE masks are not allowed in the relationship mask with the SDO_RELATE operator. This is because SDO_RELATE uses the spatial index to find candidates that may interact, and the information to satisfy DISJOINT or DETERMINE is not present in the index.
Now, how can a function that cannot determine DISJOINT relationships be reliable in determining ANYINTERACT relationships? Actually in this case, the answer we needed is given by SDO_RELATE, as we were looking for a touch relationship for all 3 geometries, except we got the DISJOINT with the SDO_GEOM.RELATE until we cranked up the tolerance.
These are the geometries involved:
Base geom:
SDO_GEOMETRY(2003, 8265, NULL), SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.9497222222222, 32.0836111111111, -82.2163888888889, 31.7502777777778, -81.9997222222222, 31.4002777777778, -81.9997222222222, 31.8502777777778, -81.9497222222222, 32.0836111111111))
Geom that yields ANYINTERACT and TOUCH:
SDO_GEOMETRY(2003, 8265, NULL), SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.77888889, 31.3330555608386, -81.59972222, 31.4252777808399, -81.99972222, 31.7997222208455, -81.99972222, 31.4002777808396, -81.88777778, 31.3330555608386, -81.77888889, 31.3330555608386))
Geom that yields ANYINTERACT and DISJOINT:
SDO_GEOMETRY(2003, 8265, NULL), SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.39166667, 31.6836111108438, -81.34972222, 31.8502777808462, -81.99972222, 31.8500000008462, -81.99972222, 31.7997222208455, -81.59972222, 31.4252777808399, -81.52472222, 31.4377777808401, -81.45805556, 31.5419444408417, -81.47055556, 31.6252777808429, -81.39166667, 31.6836111108438))
Both should touch the base geom along the -81.99972222 or at least both should be disjoint at a tolerance of 0.5 but one is and the other isn't.
So how do I know when to trust SDO_RELATE? How do I know what tolerance will give me consistency?
Oh, yeah, we have the query down to about 45 mins, by using SDO_GEOM.RELATE with DETERMINE and SDO_FILTER in the where clause. (comparing each geometry to each geometry in a table of about 10K rows)

ConSolTed,
It looks to me like the geometries in question are disjoint by 0.000247 meters.
Check my math:
-81.9997222222222 - -81.99972222 = -0.0000000022222 degrees
111,000 meters/degree @equator * -0.0000000022222 * cos(31.4) = -0.000247
So I would expect sdo_geom.relate to return TOUCH for both geometries, and sdo_anyinteract to return TRUE for both, when the tolerance is around .0005 and up. But I've never been good at this math stuff.
Anyone know why ConSolTed's query below, now with a tolerance of 26 meters, returns Disjoint?
SQL> select version from v$instance;
VERSION
10.2.0.4.0
SQL> SELECT
2 SDO_GEOM.RELATE(
3 SDO_GEOMETRY(2003, 8265, NULL, SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.9497
222222222, 32.0836111111111, -82.2163888888889, 31.7502777777778, -81.9997222222222, 31.400277777777
8, -81.9997222222222, 31.8502777777778, -81.9497222222222, 32.0836111111111))
4 , 'determine',
5 SDO_GEOMETRY(2003, 8265, NULL, SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.391666
67, 31.6836111108438, -81.34972222, 31.8502777808462, -81.99972222, 31.8500000008462, -81.99972222,
31.7997222208455, -81.59972222, 31.4252777808399, -81.52472222, 31.4377777808401, -81.45805556, 31.5
419444408417, -81.47055556, 31.6252777808429, -81.39166667, 31.6836111108438))
6 , 26) relationship
7 FROM dual;
RELATIONSHIP
DISJOINT

SDO_RELATE AND SDO_GEOM RELATE MASK PROBLEMS

I am trying to use the SDO_RELATE operator on my spatial table.
I have been experiencing problems.
I also get the same problems if I use the SDO_GEOM.RELATE geometry function.
Background
Table2 contains about 20 000 rows.
Table1 contains about 1 000 000 rows.
Both tables contain area geomteries.
I can not get the following 'masks' to return any results.
-- OVERLAPBDYINTERSECT
-- COVEREDBY
-- COVERS
-- OVERLAPBDYDISJOINT
The all return -
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Elapsed: 00:00:20.00
However the mask INSIDE does work!!! And it returns the correct results.
The query syntax I am using is below. And substituting any of the above mentioned masks for INSIDE results in the ORA-03113 error.
I have validated all the geometies in my table using SDO_GEOM.VALIDATE_LAYER. They are all valid.
Query Syntax
SELECT /* ORDERED */ count(g2.parcel_ref)
FROM table2 g2
WHERE 1 < (SELECT /*+ ORDERED */ count(*)
FROM table1 g1
WHERE SDO_RELATE (g1.geometry,
g2.geom,
'MASK=INSIDE querytype=WINDOW') ='TRUE');
SELECT /* ORDERED ORDERED_PREDICATES */ count(g2.parcel_ref)
FROM table2 g2
WHERE 1 < (SELECT /*+ ORDERED */ count(*)
FROM table1 g1
WHERE SDO_FILTER (g1.geometry, g2.geom, 'querytype=WINDOW')='TRUE'
AND SDO_GEOM.RELATE (g1.geometry, 'inside', g2.geom,0.001)='INSIDE');
Does anybody have any ideas why all the masks (except INSIDE) fail?
Thanks,
Bob

Dan,
I have finally got back to looking at my problem queries.
The first discovery I have found is that I can repeat the problem using one feature in one of the geometry tables.
You can see the syntax that I am using below. As I stated before, the INDSIDE query works, but the COVEREDBY fails.
OVERLAPBDYINTERSECT,COVEREDBY,COVERS,OVERLAPBDYDISJOINT also return the same ORA-03113 error.
SELECT /* ORDERED */ count(g2.parcel_ref)
FROM table2 g2
WHERE g2.id = 3658
AND 1 < (SELECT /*+ ORDERED */ count(*)
FROM table1 g1
WHERE SDO_RELATE (g1.geometry, g2.geom, 'MASK=INSIDE querytype=WINDOW') ='TRUE');
*** THIS ONE WORKS!
SELECT /* ORDERED */ count(g2.parcel_ref)
FROM table2 g2
WHERE g2.id = 3658
AND 1 < (SELECT /*+ ORDERED */ count(*)
FROM table1 g1
WHERE SDO_RELATE (g1.geometry, g2.geom, 'MASK=COVEREDBY querytype=WINDOW') ='TRUE');
*** THIS ONE DOES NOT WORK! The error is below.
SELECT /* ORDERED */ count(g2.parcel_ref)
ERROR at line 1:
ORA-03113: end-of-file on communication channel
I have also been running some other queries on my data.
Again, one query works, the other does not.
SELECT /*+ ORDERED ORDERED_PREDICATES */ count(*)
FROM table2 g1, table2 g2
WHERE g1.id = 194
AND SDO_FILTER (g2.geom, g1.geom, 'querytype=WINDOW')='TRUE'
AND SDO_GEOM.RELATE (g2.geom, 'overlapbdyintersect', g1.geom,0.0001)='OVERLAPBDYINTERSECT';
*** THIS ONE WORKS!
SELECT /*+ ORDERED */ count(*)
FROM table2 g1, table2 g2
WHERE g1.id = 194
AND SDO_RELATE (g2.geom, g1.geom, 'MASK=OVERLAPBDYINTERSECT querytype=WINDOW') ='TRUE';
*** THIS ONE DOES NOT WORK! Again, the error is below.
SELECT /*+ ORDERED */ count(*)
ERROR at line 1:
ORA-03113: end-of-file on communication channel
I have checked that the two problem geometries are 'valid'.
SQL> select sdo_geom.validate_geometry(geom, 0.001) from table2 where id=194;
SDO_GEOM.VALIDATE_GEOMETRY(GEOM,0.001)
TRUE
SQL> select sdo_geom.validate_geometry(geom, 0.001) from table2 where id=3658;
SDO_GEOM.VALIDATE_GEOMETRY(GEOM,0.001)
TRUE
Below is a print of the geometry of each of the problem features.
Have you got any ideas as to why the queries are failing?
Thanks in advance,
Bob
SQL> select geom from sample_lr_prm_iacs2002 where id=3658;
GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
SDO_GEOMETRY(2003, 81989, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_AR
RAY(475710.144, 133881.126, 475714.379, 133844.065, 475723.656, 133762.89, 47572
4.07, 133759.271, 475964.952, 133791.345, 475963, 133796.9, 475959, 133806.2, 47
5956.8, 133812.5, 475955.2, 133816.1, 475951.3, 133824.1, 475944.3, 133838.6, 47
5933.5, 133861.8, 475932, 133864.5, 475928.5, 133869.7, 475918.8, 133885.8, 4759
12.5, 133897, 475907.6, 133903.9, 475898.6, 133914.2, 475888.8, 133922.7, 475824
.2, 133974.3, 475809.9, 133976.2, 475808.1, 133974.6, 475805.5, 133972, 475796.3
, 133955.7, 475783.99, 133933.51, 475782.67, 133931.44, 475780.87, 133927.97, 47
5780.14, 133927, 475778.95, 133924.69, 475778.12, 133923.03, 475775.33, 133919.3
4, 475773.51, 133917.39, 475768.42, 133913.14, 475765.56, 133911.12, 475757.25,
133906.26, 475751.77, 133903.28, 475741.52, 133897.2, 475714.92, 133883.62, 4757
GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
10.86, 133881.5, 475710.144, 133881.126))
SQL> select geom from table2 where id=194;
GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
SDO_GEOMETRY(2003, 81989, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_AR
RAY(467345.544, 109699.287, 467345.379, 109699.279, 467345.288, 109698.752, 4673
44.9, 109696.5, 467339.8, 109665.2, 467325.9, 109583.1, 467311.35, 109500, 46730
9.1, 109487, 467308.27, 109482.113, 467308.242, 109482.142, 467307.491, 109478.1
99, 467307.44, 109477.435, 467307.3, 109475.9, 467307.331, 109475.837, 467307.02
4, 109471.295, 467306.963, 109471.307, 467306.831, 109471.334, 467306.831, 10946
9.765, 467307.192, 109469.68, 467310.196, 109468.973, 467345.545, 109459.288, 46
7363.626, 109453.84, 467395.576, 109447.4, 467444.616, 109440.217, 467457.247, 1
09439.474, 467460.715, 109437.245, 467461.458, 109436.255, 467467.251, 109435.39
6, 467468.145, 109435.264, 467468.264, 109435.663, 467481.7, 109435.2, 467487.2,
109435.3, 467488.8, 109435.4, 467490.6, 109435.5, 467493.4, 109435.9, 467495.6,
GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
109435.9, 467500, 109435.8, 467505.75, 109435.8, 467515.85, 109436.2, 467525.2,
109436.45, 467531.95, 109436.5, 467534.7, 109436.55, 467541.45, 109436.8, 46754
4.65, 109437.05, 467547.65, 109437.3, 467551.3, 109437.7, 467551.95, 109437.75,
467555.6, 109438.1, 467556.4, 109438.15, 467558.6, 109438.25, 467562.95, 109438.
35, 467585.5, 109439.1, 467593.55, 109439.35, 467597.5, 109439.35, 467600.45, 10
9439.3, 467603.65, 109439.35, 467606.8, 109439.3, 467607, 109439.3, 467610.15, 1
09439.2, 467613.35, 109439, 467615.7, 109438.8, 467618, 109438.55, 467620.3, 109
438.25, 467623.3, 109437.65, 467626.2, 109437.1, 467626.85, 109437, 467629.8, 10
9436.5, 467631.6, 109436.25, 467634.15, 109435.95, 467635.05, 109435.85, 467636.
95, 109435.7, 467637.35, 109435.65, 467639.25, 109435.4, 467640.1, 109435.25, 46
7641, 109435.1, 467643.7, 109434.5, 467644.3, 109434.3, 467652.15, 109432.45, 46
GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
7653.35, 109432.2, 467654.4, 109431.95, 467656.8, 109431.25, 467658.35, 109430.7
5, 467659.75, 109430.15, 467660, 109430.05, 467662.95, 109429.15, 467667.25, 109
427.9, 467667.8, 109427.8, 467668.5, 109427.7, 467670, 109427.5, 467670.7, 10942
7.4, 467671.45, 109427.35, 467671.7, 109427.35, 467678.95, 109427.45, 467680.4,
109427.5, 467681.75, 109427.55, 467683.2, 109427.55, 467684.55, 109427.5, 467685
.95, 109427.45, 467687.35, 109427.35, 467688.55, 109427.25, 467695.4, 109426.55,
467696.8, 109426.45, 467698.15, 109426.3, 467699.55, 109426.1, 467700.75, 10942
5.95, 467703.45, 109425.35, 467703.95, 109425.2, 467708.85, 109423.95, 467717.8,
109421.4, 467721.2, 109420.5, 467726.4, 109419.2, 467729.8, 109418.5, 467731.45
, 109418.15, 467735.95, 109417.45, 467737.5, 109417.25, 467742.8, 109417.05, 467
748.2, 109416.7, 467748.95, 109416.6, 467749.7, 109416.45, 467750.5, 109416.3, 4
GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
67752, 109415.9, 467752.75, 109415.65, 467753.4, 109415.45, 467753.95, 109415.2,
467754.55, 109415, 467755.1, 109414.75, 467755.6, 109414.45, 467756.15, 109414.
2, 467756.45, 109414, 467762.25, 109409.8, 467768.8, 109404.9, 467770.4, 109403.
7, 467771.3, 109403.1, 467771.513, 109402.932, 467772.658, 109403.214, 467772.92
9, 109403.281, 467777.496, 109404.803, 467790.963, 109405.789, 467804.758, 10940
7.103, 467810.013, 109407.431, 467821.181, 109409.73, 467831.035, 109410.716, 46
7843.188, 109412.03, 467849.757, 109412.686, 467853.992, 109414.38, 467854.15, 1
09416.85, 467854.85, 109427.6, 467855.35, 109436.3, 467855.75, 109443.95, 467856
.25, 109451.7, 467854.7, 109460.35, 467852.45, 109472, 467850.5, 109482.45, 4678
48.45, 109493.25, 467847.15, 109500, 467846.25, 109505.2, 467845, 109511.7, 4678
44.25, 109515.9, 467843.15, 109521.5, 467841.85, 109528.55, 467840.65, 109534.95
GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
, 467840.05, 109538.2, 467839.65, 109542.4, 467839.05, 109548.35, 467838.55, 109
553.6, 467837.9, 109560.6, 467837.2, 109568, 467836.45, 109576.3, 467836.05, 109
581.45, 467835.45, 109588.4, 467834.55, 109597.9, 467833.1, 109614.5, 467832.35,
109622, 467831.2, 109634.4, 467830.6, 109640.2, 467830.55, 109640.5, 467828.5,
109642.15, 467824.2, 109642.3, 467821.1, 109642.35, 467819.75, 109642.4, 467818.
9, 109642.4, 467818.6, 109642.45, 467818.4, 109642.45, 467818.25, 109642.5, 4678
18.05, 109642.5, 467817.85, 109642.55, 467817.65, 109642.5, 467817.45, 109642.5,
467817.2, 109642.55, 467816.95, 109642.55, 467816.7, 109642.6, 467816.45, 10964
2.6, 467815.85, 109642.7, 467815.35, 109642.7, 467814.65, 109642.8, 467812.25, 1
09643.05, 467811.4, 109643.1, 467810.55, 109643.2, 467809.1, 109643.4, 467807.1,
109643.7, 467805.75, 109643.85, 467804.45, 109643.95, 467800.55, 109644.5, 4677
GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
98.75, 109644.7, 467795.9, 109645, 467794.95, 109645.15, 467793.6, 109645.3, 467
792.15, 109645.55, 467790.65, 109645.75, 467787.25, 109646.05, 467782.8, 109646.
5, 467778.15, 109646.95, 467774.5, 109647.4, 467770.1, 109647.85, 467765.75, 109
648.3, 467760.85, 109648.9, 467753.35, 109649.65, 467748.7, 109650.1, 467745.15,
109650.45, 467741.05, 109650.85, 467739.95, 109650.95, 467736.45, 109651.35, 46
7732.1, 109651.95, 467729.1, 109652.3, 467724.95, 109652.7, 467723.05, 109652.95
, 467720.5, 109653.2, 467716.65, 109653.75, 467712.05, 109654.45, 467708.65, 109
654.9, 467704.45, 109655.4, 467700.35, 109655.95, 467695.65, 109656.65, 467692.4
, 109657.1, 467690.4, 109657.25, 467682.65, 109657.8, 467679, 109658.1, 467676.1
5, 109658.35, 467674.75, 109658.5, 467674.3, 109658.5, 467674.1, 109658.55, 4676
73.7, 109658.55, 467673.3, 109658.65, 467673, 109658.7, 467672.7, 109658.8, 4676
GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
72.1, 109658.9, 467671.4, 109659, 467670.9, 109659.1, 467670, 109659.25, 467669.
75, 109659.3, 467668.75, 109659.4, 467668.3, 109659.4, 467667.85, 109659.45, 467
665.4, 109659.65, 467661.9, 109660.05, 467659.5, 109660.3, 467656.65, 109660.7,
467652.55, 109661.25, 467648.35, 109661.8, 467644.65, 109662.25, 467641.7, 10966
2.65, 467639.5, 109662.9, 467636.75, 109663.25, 467633.25, 109663.6, 467631.7, 1
09663.75, 467631.5, 109663.8, 467631.1, 109663.8, 467630.9, 109663.85, 467630.55
, 109663.85, 467630.35, 109663.9, 467630.2, 109663.95, 467629.85, 109663.95, 467
629.05, 109664.05, 467628.35, 109664.15, 467628.05, 109664.2, 467627.7, 109664.3
, 467625.95, 109664.55, 467623.15, 109665.1, 467622.85, 109665.15, 467622.6, 109
665.25, 467622.3, 109665.3, 467622.05, 109665.35, 467621.9, 109665.35, 467621.65
, 109665.4, 467621.4, 109665.4, 467621.15, 109665.45, 467620.95, 109665.5, 46762
GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
0.7, 109665.6, 467620.5, 109665.65, 467620.3, 109665.65, 467619.8, 109665.75, 46
7619.5, 109665.8, 467619.15, 109665.8, 467618.45, 109665.9, 467616.8, 109666.1,
467613.2, 109666.6, 467610.15, 109667.05, 467608, 109667.3, 467605.85, 109667.5,
467603.75, 109667.7, 467602.25, 109667.9, 467601.05, 109668, 467597.05, 109668.
35, 467592.6, 109668.8, 467589.7, 109669.1, 467587.1, 109669.4, 467583.65, 10966
9.75, 467580.7, 109670.1, 467576.3, 109670.65, 467567, 109671.85, 467562.25, 109
672.4, 467556.85, 109673, 467553.95, 109673.3, 467550.35, 109671.95, 467545.1, 1
09670, 467540.35, 109668.3, 467539.9, 109668.15, 467539.75, 109668.15, 467539.6,
109668.1, 467539.5, 109668.05, 467539.35, 109668, 467539.2, 109668, 467539, 109
667.95, 467538.75, 109667.95, 467538.55, 109667.9, 467538.35, 109667.9, 467534.8
, 109667.7, 467530.65, 109667.35, 467523.9, 109666.75, 467519.5, 109666.4, 46751
GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
6.2, 109666.1, 467511.8, 109665.65, 467508.1, 109665.3, 467504.85, 109664.9, 467
501.35, 109664.5, 467500, 109664.4, 467498.7, 109664.3, 467480.5, 109673.4, 4674
73.7, 109677, 467468.4, 109680, 467461.5, 109683.8, 467453.2, 109688.1, 467448.1
, 109690.4, 467441.4, 109693, 467439.6, 109693.6, 467430, 109696.2, 467424, 1096
97.7, 467420.3, 109698.5, 467419.444, 109698.653, 467419.409, 109698.708, 467397
.983, 109702.395, 467373.562, 109709.767, 467362.964, 109719.213, 467362.94, 109
718.668, 467362.504, 109719.213, 467347.528, 109705.39, 467346.459, 109701.945,
467346.01, 109700.498, 467345.636, 109699.291, 467345.544, 109699.287))

SDO_GEOM.RELATE or SDO_CONTAINS

Hallo,
I have two tables:
- table1 with id-column, geometry-column --> about 5 million records with point-geometry
- table2 with id-column, geometry-column --> about 10000 records with polygons
Now I want to query for each record in table2 the records in table2 that are within the area.
That means for each area in table2 the points from table1 that are in the area of table2.
How can I do this so that is is not so time consuming?
1.
select table1.id, table2.id from table1, table2
where SDO_GEOM.RELATE(table1.geo, 'contains', table2.geo, 0.005);
2.
select table1.id, table2.id from table1, table2
where SDO_CONTAINS(table1.geo, table2.geo) ='TRUE';
Is there another way more efficient way to do that?
Thanks a lot

1. there is big difference between sdo_geom.relate FUNCTION and sdo_relate OPERATOR. The operator will use the spatial index, the FUNCTION does not.
2. In this case a spatial join could be used. SDO_JOIN (http://download.oracle.com/docs/html/B14255_01/sdo_operat.htm#BGEDJIBF)
SELECT /*+ ordered */ a.id, b.id
FROM TABLE(SDO_JOIN('TABLE1', 'GEO',
'TABLE2', 'GEO',
'mask=ANYINTERACT')) c,
table1 a,
tabel2 b
WHERE c.rowid1 = a.rowid AND c.rowid2 = b.rowid
use ANYINTERACT if points can be on one or more polygon boundaries, otherwise use CONTAINS.
Luc

SDO_GEOM.RELATE... speed up!

With 8.1.7, I run the following querry to check if one geometry(GEOM1) is the same as the other geometry(GEOM2).
SELECT MDSYS.SDO_GEOM.RELATE(GEOM1, v_DIMINFO,'EQUAL',GEOM2,v_DIMINFO) INTO v_OUT FROM DUAL;
IF v_OUT='FALSE' THEN
BUT I FOUND it will take TWO OR THREE MINUTES to complete. Because both of these geometries are not indexed, I can not use operator like SDO_RELATE.
Another option is to run the following querry:
IF MDSYS.SDO_GEOM.SDO_XOR(GEOM1, v_DIMINFO, GEOM2, v_DIMINFO IS NOT NULL THEN;
But it took more than FOUR minutes.
Is there any other suggestion to speed it up???
Thanks in advance.
Jerry

Thanks for Dan's help.
I will check the tolerance and the complicity of the geometry.
Now the geometries are both linestrings.
It is what I worry about that the query may take quite long time for complicate geomerties.
Another interesting thing I just found.
Because GEOM2 is always a part or all of the GEOM1. That is, GEOM1 should never be inside GEOM2.
So, If I run the following query:
SELECT MDSYS.SDO_GEOM.RELATE(GEOM1, v_DIMINFO,'EQUAL+INSIDE', GEOM2, v_DIMINFO) INTO v_OUT FROM DUAL;
IF v_OUT='FALSE' THEN.......
The determinant part of the mask is 'equal' and it will do the same thing as the query:
SELECT MDSYS.SDO_GEOM.RELATE(GEOM1, v_DIMINFO,'EQUAL',GEOM2,v_DIMINFO) INTO v_OUT FROM DUAL;
BUT, I found it(equal+inside) faster(+50% improvement!) than just using 'equal' as mask.
Anyone can tell me the reason? Is this cheating safe if I assume GEOM1 is never inside GEOM2??
Thanks in advance!!!

VERY slow SDO_GEOM.RELATE funcktion call

Hi,
I have the table definition below. The table contains over 3,5 million records. What we experience is that the following query runs terribly slow. With 100 thousand records it takes 14 seconds, with 3,5 million records we can not wait till it executes.
Is the relate function supposed to handle this amount of data? We are using oracle 11g on Windows.
Regards,
Tamas
*======= SLOW RUNNING QUERY ===================*
function FM_SELECT_OG_BY_GEOM_CUR(I_OG mdsys.SDO_GEOMETRY,
I_MASK varchar default G_MASK ,
I_TOLERANCE number default G_TOLERANCE )
return SYS_REFCURSOR is
L_REC_SET SYS_REFCURSOR;
begin
open L_REC_SET for
select OG.AZONOSITO
from OBJEKTUM_GEOMETRIAK OG
where MDSYS.SDO_GEOM.RELATE(OG.OBJEKTUM_GEOMETRIA,
I_MASK,
I_OG,
I_TOLERANCE) != 'FALSE';
return L_REC_SET;
exception
when others then
open L_REC_SET for 'select null AZONOSITO from dual where 1=2 ';
return L_REC_SET;
end;
*======= TABLE DEFINITION ======================*
create table OBJEKTUM_GEOMETRIAK
AZONOSITO number( 10 ),
OBJEKTUM_SZIMBOLIKA number( 10 ) not null,
OBJEKTUM_AZONOSITO number( 10 ) not null,
OBJEKTUM_GEOMETRIA sdo_geometry, -- pontatlan
MAP_ID number( 10 ) not null,
COLOR number( 5 ),
STYLE number( 2 ), -- STYLE
WEIGHT number( 2 ), -- WEIGHT
FONT_ID number( 3 ), -- FONT
WIDTH number( 9,3 ), -- WIDTH
HEIGHT number( 9,3 ), -- HEIGHT
JUSTIFICATION_ID number( 2 ), -- JUSTIFICATION
FELIRAT varchar( 256 ),
FORGATAS number(10,3),
OBJEKTUM_KOMPONENS number( 10 ) not null
) tablespace MIR_TAB_MST;
alter table OBJEKTUM_GEOMETRIAK add (primary key (AZONOSITO));
create index IDX_OBJEKTUM_GEOMETRIAK_2
on OBJEKTUM_GEOMETRIAK( MAP_ID )
tablespace MIR_IDX_MST;
insert into USER_SDO_GEOM_METADATA
values ( 'OBJEKTUM_GEOMETRIAK',
'OBJEKTUM_GEOMETRIA',
MDSYS.SDO_DIM_ARRAY( MDSYS.SDO_DIM_ELEMENT( 'X',
600000,
900000,
0.001 ), MDSYS.SDO_DIM_ELEMENT( 'Y',
150000,
400000,
0.001 ) ),
null );
create index IDX_OBJEKTUM_GEOMETRIAK_1 on OBJEKTUM_GEOMETRIAK ( OBJEKTUM_GEOMETRIA ) indextype is MDSYS.
SPATIAL_INDEX
parameters(' ') noparallel;
create index IDX_OBJEKTUM_GEOMETRIAK_3
on OBJEKTUM_GEOMETRIAK (OBJEKTUM_AZONOSITO )
tablespace MIR_IDX_MST;

HI,
Just want to add some information between the performance difference between a spatial operator and spatial function:
A spatial operator takes advantage of spatial indexes while a spatial function does not.
In your case, sdo_geom.sdo_relate is a spatial operator and sdo_geom.relate is a spatial function.
They serve the same functionality but might have huge performance difference if you have a big table.
In general, the complexity (performance) for spatial operators is O(ln N) and, spatial functions, O(N), while N is the number of geometry you will query against.
This is true for all Oracle Spatial operators and their corresponding spatial functions.
So try to use spatial operators in your query if they are available.
Jack

Using regexp_instr in a where clause - invalid relational operator

Whey I try to run this query in TOAD I get an ORA-00920: invalid relational operator error. It's part of a 10g stored procedure. When I highlight it and run it it prompts me for the missing values and then the error pops up. The AND in line 4 is highlighted.
select CRIME_CLASSIFICATION_ID, crime_type, nvl(count(CRIME_CLASSIFICATION_ID),0) as CRIMECNT
From vaps.vw_offenses
    where regexp_instr(valoc,to_char(location_id))
        AND ( fromdate is null or
         offense_date between to_date(fromdate, 'mm/dd/yyyy') AND to_date(todate,'mm/dd/yyyy')
group by crime_classification_id, crime_type

Hi,
Review what REGEXP_INSTR does: it returns a NUMBER.
Your WHERE clause couldn't make any sense if you used any other kind of NUMBER expression in that place, e.g. a NUMBER literal such as 12:
select CRIME_CLASSIFICATION_ID, crime_type, nvl(count(CRIME_CLASSIFICATION_ID),0) as CRIMECNT
From vaps.vw_offenses
    where 12     -- This is obviously wrong
        AND ( fromdate is null or
         offense_date between to_date(fromdate, 'mm/dd/yyyy') AND to_date(todate,'mm/dd/yyyy')
group by crime_classification_id, crime_type
It's not going to work any better with a function (like REGEXP_INSTR) that returns a NUMBER.
How can you fix it? That depends on what you want to do. Why are you calling REGEXP_INSTR? What is that condition checking?
Whenever you have a problem, please post a little sample data (CREATE TABLE and INSERT statements, relevant columns only) from all tables involved, so that the people who want to help you can re-create the problem and test their ideas.
Also post the results you want from that data, and an explanation of how you get those results from that data, with specific examples.
Always say which version of Oracle you're using (for example, 11.2.0.2.0).
See the forum FAQ: https://forums.oracle.com/message/9362002

Error: ORA-00920: invalid relational operator (WWV-16016)

Hi,
When I try to query in the form, I'm getting the following error
An unexpected error occurred: ORA-00920: invalid relational operator (WWV-16016).
The form has a field of type varchar2 with lov attached to it. This error is happening only if I enter characters more than 40 or select a value which has more than 40 characters from the lov.
Anbody had this problem?..Is there a solution for this?..Help would be appreciated.
Thanks
PJ

I figured out the problem and it seems like if the value has any 'IN' or 'BETWEEN' and try to query this error is happening and it's not because of character length. I think Portal assumes that relational operator is entered and tries to query based on those words. Is it a bug in the Portal?..
Thanks
PJ

SDO_GEOM.RELATE in 8.1.7

I got 'UNKNOWN MASK: 110110001' returned when I used SDO_GEOM.RELATE function to check if 2 mutiplelinstrings are equal or not..
Even I tried to test this function with same geometry, I still got same error message.
BTW, for other geometry like simple polygon, this function works well.
Any suggestions?
Many thanks for your comments and help!
Jack
DECLARE
v_GEOM1                     MDSYS.SDO_GEOMETRY;
v_GEOM2                     MDSYS.SDO_GEOMETRY;
v_info                              VARCHAR2(80) ;
BEGIN
v_GEOM1:=MDSYS.SDO_GEOMETRY(2006,NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1,11,2,1),
MDSYS.SDO_ORDINATE_ARRAY(8.07280413276778,53.62639558,8.07354916666667,53.6255908333333,
8.07360805555555,53.6255119444444,8.07365694444444,53.6254511111111,
8.073735,53.6253663888889,8.07253709607513,53.62639558,8.07276694444444,
53.6261461111111,8.07306055555556,53.6258655555556,8.073735,53.6253663888889,
8.07395,53.6251330555556,8.074015,53.6250625,8.07409694444445,53.6249738888889,
8.07414888888889,53.6249175,8.07421555555556,53.6248452777778,8.07446527777778,
53.6245747222222,8.07461333333333,53.6244141666667,8.07469027777778,
53.6243308333333,8.07517888888889,53.6238011111111));
v_GEOM2:=MDSYS.SDO_GEOMETRY(2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),
MDSYS.SDO_ORDINATE_ARRAY(8.07109464, 53.62356679, 8.07674003, 53.62356679, 8.07674003, 53.62639558,
8.07109464, 53.62639558, 8.07109464, 53.62356679));
SELECT MDSYS.SDO_GEOM.RELATE(v_GEOM1,'EQUAL', v_GEOM1,0.000000000001) INTO v_info FROM DUAL;
DBMS_OUTPUT.PUT_LINE(v_info);
END;

Handle: dee
Status Level: Newbie (5)
Registered: Jun 14, 2010
Total Posts: 61
Total Questions: 30 (30 unresolved)
If its working , Please mark thread as answered why you leave your thread in Open Status

BP Selection by Role- Problem with relation operator

Hai Experts,
I am using sandbox system. I am trying to search Business Partner by role, when I give the role as BUP002(Prospect) and enter, the system is throwing a message that "BP Role BUP00 does not exist" and i have checked the relation operator which will be available next to the BP Role(when we input the role as BUP002), the relation has been set it as " Role=BUP00" , because we do not have any role with BUP00,hence the system is throwing that message. Now i need your help where do we set that relation may be in configuration or customization.Kindly provide me the exact path and way to do it.
Thanks and Regards,
Teja

Hi Teja,
Please check the SPRO settings, just follow the path below
SPRO->Click SAP Reference IMG->Customer Relationship Management->Master data->Business Partner-> Basic settings->Assign template for content managment folder to BP roles,
Just check it, here there is a view that u need to maintain.
Just check it I am not so sure about, as I dont have a local system in which I can try it. So check it and let me know if it is working fine.
Have a grat day ahead.
Thanks and Regards,
Antony Thomas

Passing Relational operator along with input

Hi friends
I have a procedure
get_emp_list(p_sal in varchar2
p_out out sys_refcursor)
as
begin
open p_out
for
select * from emp
where sal (=,<,>) p_sal;
end;
Friends pls help me in writing the query,
The input will be like <1000 or >1000 or =1000.
Relational operator will be passed as a input in p_sal
I have to take the output based on the input values.
Pls give me any tips
Rajesh

or more accurately as per your requirements...
procedure get_emp_list(p_sal in varchar2, p_out out sys_refcursor) as
begin
open p_out for
    select * from emp
    where (substr(p_sal,1,1) = '=' and sal = to_number(substr(p_sal,2)))
    or    (substr(p_sal,1,1) = '<' and sal < to_number(substr(p_sal,2)))
    or    (substr(p_sal,1,1) = '>' and sal > to_number(substr(p_sal,2)));
end;However this assumes the operator will only be a single character so you'll have to alter accordingly if you want to deal with <=, >= etc.

Case with where clause - ORA-00920: Invalid relational operator

Hi All, when I try to run the query below, I get the following error...
ORA-00920: invalid relational operator
00920. 00000 - "invalid relational operator"
*Cause:
*Action:
Error at Line: 16 Column: 5
Does anyone know what's wrong with my query? thanks in advance.
SELECT concat (year,period)
FROM DD_ACTUALS_FACT
WHERE CASE Period
WHEN 'JAN' THEN '01'
WHEN 'FEB' THEN '02'
WHEN 'MAR' THEN '03'
WHEN 'APR' THEN '04'
WHEN 'MAY' THEN '05'
WHEN 'JUN' THEN '06'
WHEN 'JUL' THEN '07'
WHEN 'AUG' THEN '08'
WHEN 'SEP' THEN '09'
WHEN 'OCT' THEN '10'
WHEN 'NOV' THEN '11'
WHEN 'DEC' THEN '12'
END as "MonthNo"
ORDER BY CONCAT (year,"MonthNo") DESC

The problem is the as "MonthNo" - you can't give an "AS" alias to an expression in a where clause.
You have not actually given any condition, just a set of translations from period into a number.
You also haven't said what you're trying to do.
Perhaps you want:
SELECT concat (year,period)
FROM DD_ACTUALS_FACT
WHERE something
ORDER BY CONCAT (year, CASE Period
WHEN 'JAN' THEN '01'
WHEN 'FEB' THEN '02'
WHEN 'MAR' THEN '03'
WHEN 'APR' THEN '04'
WHEN 'MAY' THEN '05'
WHEN 'JUN' THEN '06'
WHEN 'JUL' THEN '07'
WHEN 'AUG' THEN '08'
WHEN 'SEP' THEN '09'
WHEN 'OCT' THEN '10'
WHEN 'NOV' THEN '11'
WHEN 'DEC' THEN '12'
END ) DESC

Inconsistent results between SDO_RELATE and SDO_GEOM.RELATE

Maybe its the Friday syndrome, but I'm getting some results that I can't get my head around...
Let say I have a table with a single line geometry...
CREATE TABLE BUFFER_TEST (
     WHAT VARCHAR2(100),
     GEOMETRY SDO_GEOMETRY);
INSERT INTO user_sdo_geom_metadata VALUES ('BUFFER_TEST','GEOMETRY',
MDSYS.SDO_DIM_ARRAY(
     MDSYS.SDO_DIM_ELEMENT('X',400000,750000,0.0005),
     MDSYS.SDO_DIM_ELEMENT('Y',500000,1000000,0.0005)),
262152);
CREATE INDEX BUFFER_TEST_IDX ON BUFFER_TEST (GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
INSERT INTO BUFFER_TEST (what, geometry)
VALUES ('line',
SDO_GEOMETRY(2002, 262152, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1),
SDO_ORDINATE_ARRAY(713353.165, 736165.812, 713353.449, 736165.402, 713353.849,
736164.203, 713353.85, 736162.252, 713353.087, 736149.092)));
COMMIT;Now I want to buffer this line and check if the line is inside the buffer - the actual business need is to see if other lines are in the buffer, but we'll keep it simple for now...
So in the snippet below, I'm buffering the line by 50cm and then using SDO_INSIDE to see if the line is inside the buffer - it isn't.
Then if I use SDO_GEOM.RELATE to determine the relationship, it says INSIDE, which is correct.
Then if I increase the buffer size to 1m, then SDO_INSIDE and SDO_GEOM.RELATE both return the correct result.
SQL> DECLARE
2   l_inside NUMBER;
3   l_small_buffer SDO_GEOMETRY;
4   l_determine VARCHAR2(100);
5   l_buffer_size NUMBER := 0.5;
6 BEGIN
7
8     SELECT SDO_GEOM.SDO_BUFFER(b.geometry, usgm.diminfo, l_buffer_size)
9     INTO      l_small_buffer
10     FROM    user_sdo_geom_metadata usgm, BUFFER_TEST b
11     WHERE usgm.table_name = 'BUFFER_TEST'
12     AND      usgm.column_name = 'GEOMETRY'
13     AND      b.what = 'line';
14
15     SELECT COUNT(*)
16     INTO    l_inside
17     FROM   BUFFER_TEST
18     WHERE SDO_INSIDE(geometry, l_small_buffer) = 'TRUE'
19     AND     what = 'line';
20
21     SELECT SDO_GEOM.RELATE(geometry, 'determine', l_small_buffer, 0.0005) relationship
22     INTO l_determine
23     FROM BUFFER_TEST
24     WHERE what = 'line';
25
26     DBMS_OUTPUT.PUT_LINE('l_inside: ' || l_inside || ' relationship ' || l_determine);
27
28 END;
29 /
l_inside: 0 relationship INSIDEAny help would be much appreciated... I'm starting to pull my hair out on this.
This is on Oracle 10.2.0.3

I can reproduce this on 11.1.0.6 on Windows 32bit.
Would you recommend I open a support case on this? Do you think it would be possible to backport a fix to 10.2.0.4?

Relational operator LIKE is not supported.

Hi friends,
I am trying to write a routine in bw. I am using LIKE pattern.
But it is giving the below error.
"E:Relational operator "LIKE" is not supported."

hi,
can you post your code and mention what do you want to achieve?
thanks
ec

Sdo_geom.relate operator (urgently)

Similar Messages

Maybe you are looking for