Error on SDO_GEOM.RELATE

I get this error on this statement:
if SDO_GEOM.RELATE(Pic1,'anyinteract',Pic2,0.0000005)='TRUE'
then
The error i get is the following:
ORA-13050: unable to construct spatial object
ORA-06512: at MDSYS.SDO_3GL
ORA-06512: at MDSYS.MD2
Where can i do?

The most likely cause is that an instance of Pic1 or Pic2 is invalid. Run sdo_geom.validate_geometry_with_context() and if any geometries are invalid, fix or delte them.
Jayant

Similar Messages

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

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 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

ORA-13000: dimension number is out of range when using SDO_GEOM.RELATE

Dear everyone
I am attempting to workout which polygons cover the same area in order to determine distinct polygons. This is so I can then have just one copy of a polygon to a new table and delete all the duplicate polygons in the current table.
I ran the following first to check something:
SELECT SDO_GEOM.RELATE
   (A.geographical_coordinates,
    'DETERMINE',
    B.geographical_coordinates,
    0.05) relationship
FROM MAP_INDEX A,
      MAP_INDEX B
where A.geographical_coordinates is not NULL
and B.geographical_coordinates is not NULL;but got the error message:
Error starting at line 1 in command:
SELECT DISTINCT A.mi_prinx,
SDO_GEOM.RELATE
   (A.geographical_coordinates,
    'EQUAL',
    B.geographical_coordinates,
    0.05)
FROM MAP_INDEX A,
      MAP_INDEX B
where A.geographical_coordinates is not NULL
and B.geographical_coordinates is not NULL
Error report:
SQL Error: ORA-13000: dimension number is out of range
ORA-06512: at "MDSYS.SDO_GEOM", line 70
ORA-06512: at "MDSYS.SDO_GEOM", line 2647
13000. 00000 - "dimension number is out of range"
*Cause:    The specified dimension is either smaller than 1 or greater than
           the number of dimensions encoded in the HHCODE.
*Action:   Make sure that the dimension number is between 1 and the maximum
           number of dimensions encoded in the HHCODE.I then tried the following:
SELECT DISTINCT A.mi_prinx,
SDO_GEOM.RELATE
   (A.geographical_coordinates,
    'EQUAL',
    B.geographical_coordinates,
    0.05)
FROM MAP_INDEX A,
      MAP_INDEX B
where A.geographical_coordinates is not NULL
and B.geographical_coordinates is not NULLwhich produced the following error message:
Error starting at line 1 in command:
SELECT
SDO_GEOM.RELATE
(A.geographical_coordinates,
'EQUAL',
B.geographical_coordinates,
0.05) relationship
FROM MAP_INDEX A,
       MAP_INDEX B
Error report:
SQL Error: ORA-13050: unable to construct spatial object
ORA-06512: at "MDSYS.SDO_3GL", line 4
ORA-06512: at "MDSYS.MD2", line 771
ORA-06512: at "MDSYS.SDO_GEOM", line 2622
ORA-06512: at "MDSYS.SDO_GEOM", line 2649
13050. 00000 - "unable to construct spatial object"
*Cause:    This is an internal error.
*Action:   Contact Oracle Support Services.Does anyone have any idea as to what I might doing wrong? The original polygons were created in MapInfo Professional 8 and I am working in 10.2g
I believe Imust be doing something wrong. I looked into SDO_GEOM_VALIDATE but again that produce the same error message as the first one. I have previously created a spatial index and inserted the values into the USER_SDO_GEOM_METADATA view.
I have been able to get the following to work, I was testing out examples online just to see if I could produce a result on an sdo function:
SELECT NAME_OF_FEATURE, SDO_GEOM.SDO_AREA(GEOGRAPHICAL_COORDINATES,M.DIMINFO)
FROM MAP_INDEX, user_sdo_geom_metadata M
WHERE M.TABLE_NAME='MAP_INDEX' AND M.COLUMN_NAME='GEOGRAPHICAL_COORDINATES'
AND geographical_coordinates is not null;When I drew my polygons in MapInfo, they are likely to have gone partly outside of the boundary dimension values inserted in USER_SDO_GEOM_METADATA. Is that likely to be the cause of my problems or something else?
If it is the cause, is there away of setting up Oracle or MapInfo so that anything drawn outside of the dimension area is clipped.
Kind regards
Tim

Hi Tim,
Since Oracle 8.1.6 Oracle has suggested the use of 4 digit SDO_GTYPE values, which encode the number of dimensions in the geometry. Examples of 4 digit SDO_GTYPES include 2001 for a 2D point, 3001 for a 3D point, 2002 for a 2D linestring, 3002 for a 3D linestring, 2003 for a 2D polygon and 3003 for a 3D polygon.. Contrast these with single digit values of 1 for a point, 2 for a linestring, and 3 for a polygon.
My guess is that at least some of your data is loaded using single digit SDO_GTYPE values, and in the function Oracle does not know the dimensionality of the data (is a vertex identified by 2, 3, or four numbers?). You can check this by doing a:
select distinct a.geographical_coordinates.sdo_gtype from MAP_INDEX A;
If any of the values returned are single digit values then you will know this is the problem.
You have a few options.
You can have Oracle automatically fix the data by migrating the data:
execute sdo_migrate.to_current('MAP_INDEX','GEOGRAPHICAL_COORDINATES');
This will not only set the SDO_GTYPE correctly but will also fix any ring rotation problems (ensures exterior rings are stored counter-clockwise, and interior rings are stored clockwise), it will fix ring ordering problems (ensuring an exterior ring is followed by its interior rings), and it will appropiately set values in the SDO_ELEM_INFO_ARRAY.
After you do this you should be good to go. However, if you are using a tool to update the data and it resets the information back, then the problem will continue to plague you. You should check with your vendor if that is the case.
Another option is to change the query to a different signature which uses the SDO_GEOM_METADATA to get the dimensionality of the data. Instead of writing the query as you have, you would change it to:
SELECT SDO_GEOM.RELATE
(A.geographical_coordinates,
C.DIMINFO,
'DETERMINE',
B.geographical_coordinates,
C.DIMINFO) relationship
FROM MAP_INDEX A,
MAP_INDEX B,
USER_SDO_GEOM_METADATA C
WHERE A.geographical_coordinates is not NULL
and B.geographical_coordinates is not NULL
and C.TABLE_NAME='MAP_INDEX'
and C.COLUMN_NAME='GEOGRAPHICAL_COORDINATES';
So either of those should fix the problem you are seeing, but neither of those are the best way to accomplish what you want to do.
If I were you I would follow first set of directions (migrate your data), make sure I have a spatial index on my table:
select index_name
from user_sdo_index_info
where table_name='MAP_INDEX';
If no rows are returned, create the index:
create index MAP_INDEX_SIDX on MAP_INDEX(GEOGRAPHICAL_COORDINATES)
indextype is mdsys.spatial_index;
You could use SDO_JOIN to perform a self-join:
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_operat.htm#BGEDJIBF
using the EQUAL mask. Note the section on optimizing self-joins.
If you don't have too much data, this might be a start to doing what you want:
create table dups_rowids as
select /*+ ordered */ a.rowid rowid1,b.rowid rowid2
from MAP_INDEX A,
MAP_INDEX B
where SDO_EQUALS (a.geographical_coordinates,b.geographical_coordinates)='TRUE'
and a.rowid <> b.rowid;
create table nodup_rowid (noduprid VARCHAR2(24));
create table dup_rowid (duprid VARCHAR2(24));
set serveroutput on;
declare
rowida varchar2(24);
rowidb varchar2(24);
rowidt varchar2(24);
type myCursor is ref cursor;
acursor myCursor;
cursor c1 is select rowid1,rowid2 from dups_rowids;
begin
for r in c1 loop
rowida := r.rowid1;
rowidb := r.rowid2;
rowidt := NULL;
open acursor for 'select duprid from dup_rowid where duprid = :rowida' using rowida;
fetch acursor into rowidt;
if rowidt is null
then
execute immediate 'insert into nodup_rowid values (:rowida)' using rowida;
execute immediate 'insert into dup_rowid values (:rowida)' using rowida;
execute immediate 'commit';
end if;
close acursor;
rowidt := NULL;
open acursor for 'select duprid from dup_rowid where duprid = :rowidb' using rowidb;
fetch acursor into rowidt;
if rowidt is null
then
execute immediate 'insert into dup_rowid values (:rowidb)' using rowidb;
execute immediate 'commit';
end if;
close acursor;
end loop;
end;
Then your final table would have the geometries from the original table that had no match:
create table MAP_INDEX_NODUPS
as select * from MAP_INDEX where rownum < 1;
insert into MAP_INDEX_NODUPS
(select *
from MAP_INDEX
where ROWID not in
(select ROWID1 from DUPS_ROWIDS));
plus only one of the geometries that were equal:
insert into MAP_INDEX_NODUPS
(select *
from MAP_INDEX
where ROWID in
(select ROWID1 from NODUP_ROWID);
Hope this helps.

Form Error Message: Invalid relation attribute on pageSet xfa

Hi,
I've developed a form that many folks are using without any issues. However, I do have a small number of users that get the following error message when opening the form.
Error Message: Invalid relation attribute on pageSet xfa[0].template[0].form1[0].#pageSet[0]
This error only appears to come up if they are using Adobe Acrobat Pro Version 8. No issues on versions 9 or 10 (X). The form is suppose to be compatible back to version 7.
My main form is called (form1). Then there are 4 major sub forms under (form1), The top drop down (on the masterpage) hides or displays one of the major sub forms based on user selection.
I have a hunch that something with the generated code not jiving well with Acrobat 8.
Here's a snippet of the code if you'd like to look through it.
form1.#pageSet[0].MasterPage1.FormActionDropDown::change - (JavaScript, client)
//+ GENERATED - DO NOT EDIT (ID:D2FF16C4-6D1F-45D4-ACB7-0DB7CE14229F CRC:3650232787)
//+ Type: Action
//+ Result4: SetPresence("$Node5","hidden")
//+ Result3: SetPresence("$Node4","visible")
//+ Result2: SetPresence("$Node3","hidden")
//+ Result1: SetPresence("$Node2","hidden")
//+ Node5: form1[0].ChangePAForm[0]
//+ Node4: form1[0].Non-PAForm[0]
//+ Node3: form1[0].DeletePAForm[0]
//+ Node2: form1[0].PAForm[0]
//+ Node1: form1[0].#pageSet[0].MasterPage1[0].FormActionDropDown[0]
//+ Condition1: ListField("$Node1","textselected","ADD NON-PA User")
//+ ActionName: DropDown.change.NonPA
if ($.boundItem(xfa.event.newText) == "ADD NON-PA User") {
this.resolveNode("PAForm").presence = "hidden";
this.resolveNode("DeletePAForm").presence = "hidden";
this.resolveNode("Non-PAForm").presence = "visible";
this.resolveNode("ChangePAForm").presence = "hidden";
//+ GENERATED - DO NOT EDIT (ID:662A28BD-A30A-4E6D-92CD-6FF22B0EFB5D CRC:2945493746)
//+ Type: Action
//+ Result4: SetPresence("$Node5","hidden")
//+ Result3: SetPresence("$Node4","hidden")
//+ Result2: SetPresence("$Node3","visible")
//+ Result1: SetPresence("$Node2","hidden")
//+ Node5: form1[0].ChangePAForm[0]
//+ Node4: form1[0].Non-PAForm[0]
//+ Node3: form1[0].DeletePAForm[0]
//+ Node2: form1[0].PAForm[0]
//+ Node1: form1[0].#pageSet[0].MasterPage1[0].FormActionDropDown[0]
//+ Condition1: ListField("$Node1","textselected","DELETE EXISTING PA")
//+ ActionName: DropDown.change.DeletePA
if ($.boundItem(xfa.event.newText) == "DELETE EXISTING PA") {
this.resolveNode("PAForm").presence = "hidden";
this.resolveNode("DeletePAForm").presence = "visible";
this.resolveNode("Non-PAForm").presence = "hidden";
this.resolveNode("ChangePAForm").presence = "hidden";
//+ GENERATED - DO NOT EDIT (ID:66B7091F-75C5-4A73-8ACA-885AE42D0308 CRC:2169512649)
//+ Type: Action
//+ Result4: SetPresence("$Node5","visible")
//+ Result3: SetPresence("$Node4","hidden")
//+ Result2: SetPresence("$Node3","hidden")
//+ Result1: SetPresence("$Node2","hidden")
//+ Node5: form1[0].ChangePAForm[0]
//+ Node4: form1[0].Non-PAForm[0]
//+ Node3: form1[0].DeletePAForm[0]
//+ Node2: form1[0].PAForm[0]
//+ Node1: form1[0].#pageSet[0].MasterPage1[0].FormActionDropDown[0]
//+ Condition1: ListField("$Node1","textselected","CHANGE / MODIFY EXISTING PA")
//+ ActionName: DropDown.change.ChangePa
if ($.boundItem(xfa.event.newText) == "CHANGE / MODIFY EXISTING PA") {
this.resolveNode("PAForm").presence = "hidden";
this.resolveNode("DeletePAForm").presence = "hidden";
this.resolveNode("Non-PAForm").presence = "hidden";
this.resolveNode("ChangePAForm").presence = "visible";
//+ GENERATED - DO NOT EDIT (ID:C87B58DB-765D-426C-81BB-5A7ECFF42B63 CRC:2949030955)
//+ Type: Action
//+ Result4: SetPresence("$Node5","hidden")
//+ Result3: SetPresence("$Node4","hidden")
//+ Result2: SetPresence("$Node3","hidden")
//+ Result1: SetPresence("$Node2","visible")
//+ Node5: form1[0].ChangePAForm[0]
//+ Node4: form1[0].Non-PAForm[0]
//+ Node3: form1[0].DeletePAForm[0]
//+ Node2: form1[0].PAForm[0]
//+ Node1: form1[0].#pageSet[0].MasterPage1[0].FormActionDropDown[0]
//+ Condition1: ListField("$Node1","textselected","CREATE NEW PA")
//+ ActionName: DropDown.change.NewPA
if ($.boundItem(xfa.event.newText) == "CREATE NEW PA") {
this.resolveNode("PAForm").presence = "visible";
this.resolveNode("DeletePAForm").presence = "hidden";
this.resolveNode("Non-PAForm").presence = "hidden";
this.resolveNode("ChangePAForm").presence = "hidden";

You should post this question in the LiveCycle Designer forum here. This forum is for forms created in Acrobat (Acroforms).

Error Message: Invalid relation attribute on pageSet xfa

Hi,
Searching through the forums and on the net, I cannot seem to locate an answer to this problem so I'm trying here...
I've developed a form that many folks are using without any issues. However, I do have a small number of users that get the following error message when opening the form.
Error Message: Invalid relation attribute on pageSet xfa[0].template[0].form1[0].#pageSet[0]
This error only appears to come up if they are using Adobe Acrobat Pro Version 8. No issues on versions 9 or 10 (X). The form is suppose to be compatible back to version 7.
My main form is called (form1). Then there are 4 major sub forms under (form1), The top drop down (on the MasterPage1) hides or displays one of the major sub forms based on user selection.
I have a hunch that something with the generated code not jiving well with Acrobat 8.
Here's a snippet of the code if you'd like to look through it.
form1.#pageSet[0].MasterPage1.FormActionDropDown::change - (JavaScript, client)
//+ GENERATED - DO NOT EDIT (ID:D2FF16C4-6D1F-45D4-ACB7-0DB7CE14229F CRC:3650232787)
//+ Type: Action
//+ Result4: SetPresence("$Node5","hidden")
//+ Result3: SetPresence("$Node4","visible")
//+ Result2: SetPresence("$Node3","hidden")
//+ Result1: SetPresence("$Node2","hidden")
//+ Node5: form1[0].ChangePAForm[0]
//+ Node4: form1[0].Non-PAForm[0]
//+ Node3: form1[0].DeletePAForm[0]
//+ Node2: form1[0].PAForm[0]
//+ Node1: form1[0].#pageSet[0].MasterPage1[0].FormActionDropDown[0]
//+ Condition1: ListField("$Node1","textselected","ADD NON-PA User")
//+ ActionName: DropDown.change.NonPA
if ($.boundItem(xfa.event.newText) == "ADD NON-PA User") {
this.resolveNode("PAForm").presence = "hidden";
this.resolveNode("DeletePAForm").presence = "hidden";
this.resolveNode("Non-PAForm").presence = "visible";
this.resolveNode("ChangePAForm").presence = "hidden";
//+ GENERATED - DO NOT EDIT (ID:662A28BD-A30A-4E6D-92CD-6FF22B0EFB5D CRC:2945493746)
//+ Type: Action
//+ Result4: SetPresence("$Node5","hidden")
//+ Result3: SetPresence("$Node4","hidden")
//+ Result2: SetPresence("$Node3","visible")
//+ Result1: SetPresence("$Node2","hidden")
//+ Node5: form1[0].ChangePAForm[0]
//+ Node4: form1[0].Non-PAForm[0]
//+ Node3: form1[0].DeletePAForm[0]
//+ Node2: form1[0].PAForm[0]
//+ Node1: form1[0].#pageSet[0].MasterPage1[0].FormActionDropDown[0]
//+ Condition1: ListField("$Node1","textselected","DELETE EXISTING PA")
//+ ActionName: DropDown.change.DeletePA
if ($.boundItem(xfa.event.newText) == "DELETE EXISTING PA") {
this.resolveNode("PAForm").presence = "hidden";
this.resolveNode("DeletePAForm").presence = "visible";
this.resolveNode("Non-PAForm").presence = "hidden";
this.resolveNode("ChangePAForm").presence = "hidden";
//+ GENERATED - DO NOT EDIT (ID:66B7091F-75C5-4A73-8ACA-885AE42D0308 CRC:2169512649)
//+ Type: Action
//+ Result4: SetPresence("$Node5","visible")
//+ Result3: SetPresence("$Node4","hidden")
//+ Result2: SetPresence("$Node3","hidden")
//+ Result1: SetPresence("$Node2","hidden")
//+ Node5: form1[0].ChangePAForm[0]
//+ Node4: form1[0].Non-PAForm[0]
//+ Node3: form1[0].DeletePAForm[0]
//+ Node2: form1[0].PAForm[0]
//+ Node1: form1[0].#pageSet[0].MasterPage1[0].FormActionDropDown[0]
//+ Condition1: ListField("$Node1","textselected","CHANGE / MODIFY EXISTING PA")
//+ ActionName: DropDown.change.ChangePa
if ($.boundItem(xfa.event.newText) == "CHANGE / MODIFY EXISTING PA") {
this.resolveNode("PAForm").presence = "hidden";
this.resolveNode("DeletePAForm").presence = "hidden";
this.resolveNode("Non-PAForm").presence = "hidden";
this.resolveNode("ChangePAForm").presence = "visible";
//+ GENERATED - DO NOT EDIT (ID:C87B58DB-765D-426C-81BB-5A7ECFF42B63 CRC:2949030955)
//+ Type: Action
//+ Result4: SetPresence("$Node5","hidden")
//+ Result3: SetPresence("$Node4","hidden")
//+ Result2: SetPresence("$Node3","hidden")
//+ Result1: SetPresence("$Node2","visible")
//+ Node5: form1[0].ChangePAForm[0]
//+ Node4: form1[0].Non-PAForm[0]
//+ Node3: form1[0].DeletePAForm[0]
//+ Node2: form1[0].PAForm[0]
//+ Node1: form1[0].#pageSet[0].MasterPage1[0].FormActionDropDown[0]
//+ Condition1: ListField("$Node1","textselected","CREATE NEW PA")
//+ ActionName: DropDown.change.NewPA
if ($.boundItem(xfa.event.newText) == "CREATE NEW PA") {
this.resolveNode("PAForm").presence = "visible";
this.resolveNode("DeletePAForm").presence = "hidden";
this.resolveNode("Non-PAForm").presence = "hidden";
this.resolveNode("ChangePAForm").presence = "hidden";

You should post this question in the LiveCycle Designer forum here. This forum is for forms created in Acrobat (Acroforms).

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

Syntax error in profile relation while retreiving configuration parameters

Trying to get our Directory Services properly functioning after an IP change. Running
# kadmin.local -q listprincs
yesterday revealed that all service principals weren't set up properly. Dig dig dig... found that I might (since this server was originally 10.3--now it's 10.4.4) try
# slapconfig -kerberize diradmin
That pointed me in the direction of using Workgroup Manager to fix a couple things with the KerberosClient record for the server. Did that. Reran the command. It complained about an improperly formatted configuration file because it wiped the contents of edu.mit.Kerberos (took out the DNS bits). Then ran
# kerberosautoconfig -u
which resulted in
MergeLoggingInfo: creating default logging info
At this point, edu.mit.Kerberos looked good. Then I tried
# /usr/sbin/kdcsetup -f /LDAPv3/127.0.0.1 -w -a diradmin -p ** -v 1 REALM
which resulted in
Contacting the Directory Server
Authenticating to the Directory Server
Creating Kerberos directory
Creating KDC Config File
Creating Admin ACL File
Creating Kerberos Master Key
Creating Kerberos Database
Syntax error in profile relation while retreiving configuration parameters
SendInteractiveCommand: failed to get pattern
Creating Kerberos Admin user
kadmin.local: Syntax error in profile relation while initializing kadmin.local interface
Adding kerberos auth authority to admin user
Creating keytab for the admin tools
kadmin.local: Syntax error in profile relation while initializing kadmin.local interface
Adding KDC & kadmind to launchd
Adding the new KDC into the KerberosClient config record
edu.mit.kadmind: Already loaded
com.apple.kdcmond: Already loaded
Finished
Now when I try
# kadmin.local -q listprincs
I get
Authenticating as principal root/admin@REALM with password.
kadmin.local: Syntax error in profile relation while initializing kadmin.local interface
And now I'm getting this in kdc.log
Feb 07 09:41:26 od.master.fqdn krb5kdc[21234](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) xx.xx.xx.xx: LOOKINGUPCLIENT: diradmin@REALM for krbtgt/REALM@REALM, Database is locked or in use--try again later
Feb 07 09:41:26 od.master.fqdn krb5kdc[21234](info): DISPATCH: repeated (retransmitted?) request from xx.xx.xx.xx, resending previous response
Help!
Thanks,
Rich
ps. The typo in the error message is MIT's, not mine. I guess their engineering departments are better than their English department.
Xserve G5 Mac OS X (10.4.4)

Look at the two config files:
/Library/Preferences/edu.mit.Kerberos
/var/db/krb5kdc/kdc.log
the Database is locked or in use message is due to a missing lock file.
Look in /var/db/krb5kdc/ for principal.kadm5.lock
Hope this gets you started
- Leland

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?

Error # 3021 - Invalid Relation. --- MS Access to Oracle APEX

Hello everybody.
I have 3 years working with Oracle APEX and now I have the need to migrate an Access database to Oracle and APEX.
I have:
- MS Access 2003 database
- Oracle SQL Developer 3.0.04.34
- Oracle 10g Database
I will try to provide all the relevant information.
I used the Access Exporter for Access 2003 tool from Oracle SQL Developer to creat both .xml (for SQL Dev) file and .sql file (for APEX) but the process show me an error mesassge that said: "Error # 3021 - Invalid Relation. No current record".
I read in OTN forum that it was because the migration tool can not access the system tables and that I need to modify permisions to allow "Read Data". I did this process and I was able to create .xml file, however if I chose Application Express to create .sql file or the option to create both files the same error shows.
I have been reading in this forum but didn't find a way to solve it.
Does any body knows how to solve this issue?
Any help is appreciated.
Thanks in advance for your help.

Hello,
I can't reproduce your issue.
Have you double-checked that the tables MSysAccessObjects, MSysACEs, MSysObjects, MSysQueries and MSysRelationships are visible and that the Admin user has at least Read Design and Read Data permission on those tables?
If that is the case, and the problem still happens, and you are able to give a copy of your .mdb file to Oracle, then I suggest to open a Service Request with Oracle Support so that the issue can be investigated.
Regards
Wolfgang

SDO_RELATE OR SDO_GEOM.RELATE

hii. i want to get an information that for example districts in a specified city.i try to use sdo_relate and sdo_geom.relate but i could not get true result.
SELECT * FROM DISTRICTS WHERE SDO_RELATE(DISTRICTS .OGC_GEOMETRY,(SELECT OGC_GEOMETRY FROM CITY WHERE CITY_ID=2),'MASK=ANYINTERACT')='TRUE'
or
select * from DISTRICTS where sdo_geom.relate((select ogc_geometry from CİTY where CİTY_ID=2),'ANYINTERACT',DISTRICTS .ogc_geometry,0000000001)='TRUE'
WHEN i use these statement i get some results but it contains also neighbours. therefore i try to use
select * from DISTRICTS where sdo_geom.relate((select ogc_geometry from city where city_ID=2),'CONTAINS',DISTRICTS .ogc_geometry,0000000001)='TRUE'
or
SELECT * FROM DISTRICTS WHERE SDO_RELATE(DISTRICTS.OGC_GEOMETRY,(SELECT OGC_GEOMETRY FROM city WHERE city_ID=2),'MASK=ANYINTERACT')='TRUE'
but when i use these i could not get any information. result set is empty. why? where is the problem. thanks to everyone for help.

The point here is to figure out what is going on.
1. If you would union your 9 items you expect to be returned, would that be exactly the same geometry as the city (id=2)?
No? In that case you need to clarify how the districts and the city are related to each other. In this case it make sense you have the result using
('mask=covers+covererby')
Yes? In that case I see 2 options.
A. The geometry is not correctly continously formed.
B. The tolerance set in the user_sdo_geom_metadata for the districts does not suit its geometries.
I assusme also you validated your data.

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_Relate different to SDO_GEOM.Relate

Hi,
I have posted a question in relation to differences in these 2 before, which was resolved, but this one is proving harder to get to the bottom of.
I have 2 queries:
--Query 1
select policy_number
FROM policies p, zones z
where POLICY_NUMBER in ('648050011','230201900','270706149')
and z.mi_prinx = 417 and z.id = 5084
and sdo_relate(p.geoloc,z.geom,'mask=ANYINTERACT') = 'TRUE';
--Query 2
select policy_number
FROM policies p, zones z
where POLICY_NUMBER in ('648050011','230201900','270706149')
and z.mi_prinx = 417 and z.id = 5084
and sdo_geom.relate(p.geoloc,'ANYINTERACT',z.geom,.001) = 'TRUE';
The tolerance for policies is set in USER_SDO_GEOM_METADATA as:
((X, -8048349.95154, 8448349.95154, 0.001), (Y, -15680948.9714, 4321303.19013, 0.001), , )
Query 1 returns one policy.
Query 2 returns all 3 policies.
If I change the order in the sdo_relate command in Query 1 to sdo_relate(z.geom,p.geoloc,'mask=ANYINTERACT') = 'TRUE';
I get all 3 policies returned.
The policies are points and they are valid.
The zone is a multipolygon and it is valid.
Any help on this would greatly appriciated.
Thanks,
David

Hi Yhu,
Thanks for your reply.
Apologies for the delay in getting back to you, but when I was looking at the shape to extract out for you I exported it to MapInfo and then re-imported it to Oracle. This newly re-imported multi-polygon, which looks to be identical, works as expected, returning the 3 items.
The only difference that I can see in the 2 shapes is a rounding difference to 9 decimal places, which I cant see as being an issue.
The 2 zones tables both have the same diminfo on user_sdo_geom_metadata.
((X, -8048349.95154, 8448349.95154, 8.24835E-5), (Y, -15680948.9714, 4321303.19013, 0.0001000113), , )
Below are the points and the 2 shapes (original and re-imported).
Again, I would be very pleased if you can provide any possible reason for the difference in sdo_relate results.
Thanks,
David
Points:
230201900 (2001, 82086, (170982, 71356, ), , )
648050011 (2001, 82086, (169266, 70340, ), , )
270706149 (2001, 82086, (171151, 70430, ), , )
Edited by: user11181430 on Sep 1, 2011 4:45 PM

Error on SDO_GEOM.RELATE

Similar Messages

Maybe you are looking for