SDO_Relate problem

is there anything that i can do to speed up the results of a
query such as this one. the civic table contains point data and
the parcels2 is polygons. Presently this query takes 23 secs
but the amount of pids can be much larger.
SELECT /*+ RULE */
CIVIC_ID,
PA.GEOMID
FROM MGIS.CIVIC C,
MGIS.PARCELS2 PA
WHERE PA.PID IN
('15710940','15706633','15706658','15706732','15706666','15706823
','15102726','15084833','15102734','15084783','15102742','1508446
0','15084411','15084841','15675713','15084429','15706781','150848
58','15102692','15084924','15084437','15084866','15084445','15102
684','15084916','15084874','15084452','15706740','15084908','1510
2676','15084882','15084890','15102668','15084932','15084940','157
10940','15710270','15710296','15102627','15101702','15706633','15
706807','15706815','15084726','15706658','15084734','15084601','1
5084593','15706773','15084585','15084742','15084544','15706799','
15084759','15084825','15084551','15084767','15084569','15084775',
'15084494','15696446','15706732','15706666','15084577','15084817'
,'15084486','15706823','15102700','15084809','15102726','15084791
','15084833','15084478','15102734','15084783','15102742','1508446
0','15084411','15084841','15675713','15084429','15706781')
AND SDO_RELATE(C.GEOM, PA.GEOM,'mask=ANYINTERACT
querytype=WINDOW') = 'TRUE'

An excellent point about indexing PA.PID.
You might want to try the top part as:
select /*+ ordered */
CIVIC_ID,
PA.GEOMID
FROM MGIS.PARCELS2 PA,
MGIS.CIVIC C
Note the ordered hint, and reversing the table names in the from
clause.

Similar Messages

Mdsys.sdo_relate Problem

Hi!
I'va got two Tables, one of them ("kante") has a Geometry - Column in it and a Quad - Tree Index is
Created, the other one ("kabelabschnitt") is linked to "kante" via a foreign key.
This Query is very fast:
SELECT k.* FROM kante k
where sdo_relate(geom, mdsys.sdo_geometry(2003,NULL,NULL, mdsys.sdo_elem_info_array(1,1003,3), mdsys.sdo_ordinate_array(34520, 253535, 34621, 253606)), 'mask=ANYINTERACT querytype=window') = 'TRUE';
But this takes about 20 s:
SELECT k.*, ka.* FROM kante k, kabelabschnitt ka
where ka.id_ka = k.id_kante
and sdo_relate(geom, mdsys.sdo_geometry(2003,NULL,NULL, mdsys.sdo_elem_info_array(1,1003,3), mdsys.sdo_ordinate_array(34520, 253535, 34621, 253606)), 'mask=ANYINTERACT querytype=window') = 'TRUE';
Can anynone tell me why??
Thanx in advance,
J

Hi,
It could be slower because the optimizer is choosing to use an index associated
with the join key between the tables instead of the spatial index.
Try adding the /*+ no_index (, index_name) */ hint, i.e.
SELECT /*+ no_index (K name_of_id_kante_index) k.*, ka.*
FROM kante k, kabelabschnitt ka
where ka.id_ka = k.id_kante
and sdo_relate(geom, mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(34520, 253535, 34621, 253606)),
'mask=ANYINTERACT querytype=window') = 'TRUE';
Hope this helps,
Dan

Problem with SDO_relate when using polygons with holes.

I'm having a problem with sdo_relate. I'm trying to extract all elements from a point table (bdtq_batim_p) that are inside a specific polygon from another table (SDA_MUNIC_SS). The spatial index for both table have been rebuilt and the data from both table is valid.
When I do a count on the query, I know the answer should be 1422 elements (Counted in ArcGIS). However, sdo_relate gives a smaller number of elements in the result set.
The query :
SELECT count(distinct t.identifiant) FROM bdtq_batim_p t, SDA_MUNIC_SS s WHERE s.mus_co_geo = '48015' and sdo_relate( t.SHAPE,s.SHAPE,'mask=anyinteract querytype=window') = 'TRUE'
returns 282 elements. The query with mask=inside, SDO_Anyinteract() and SDO_inside() all give the same result.
I did a test with the following query and the result is 1422 (which is the good result).
SELECT count(distinct t.identifiant) FROM bdtq_batim_p t, SDA_MUNIC_SS s WHERE s.mus_co_geo = '48015' and SDO_WITHIN_DISTANCE( t.SHAPE,s.SHAPE,'distance=0') = 'TRUE';
It's important to note that the polygone (from SDA_MUNIC_SS) that is used for this query have holes in it. I have the same problem with all the polygons from the SDA_MUNIC_SS table that have holes in it. For the polygon without holes, the results are the same for the 2 queries.
My question are :
Why are the result from the two queries different? A query with a buffer of 0 should always return the same result as a query with Anyinteract.
Is there a known problem with SDO_RELATE when using a polygon with holes in it?
Do you have any idea how to solve my problem.

Since i don't have much control on the version of Oracle and Patches that we use in the system, we used a workaround that detects the polygons with holes and uses the SDO_WITHIN_DISTANCE( t.SHAPE,s.SHAPE,'distance=0') = 'TRUE' operator in those case. We saw a slight decline in performance but it now returns the right results. When the system will be patched, we'll come back to the original version and see if the problem is solved.

Problem with sdo_relate returning unexpected results

I am having a problem with an oracle spatial query not returning what I feel is an appropriate result.
I have a bounding box that has 6 points from a table that should be inside it. There are several hundred points total in this table. I perform the following query and oracle returns only 4 points, well 5 but we will get to that later, within the area of the search.
SQL> Select feature_id
From city_points A
where (MDSYS.SDO_RELATE(A.GEOM, mdsys.sdo_geometry(2003, 8307, NULL, mdsys.sdo_elem_info_array(1,1003,1), mdsys.sdo_ordinate_array(-101.8417,-52.8083,-23.8417,-52.8083,-23.8417,-13.8083,-101.8417,-13.8083,101.8417,-52.8083)), 'mask=ANYINTERACT querytype=join') = 'TRUE');
I used a different application to perform the same type of query. The difference is that the application does the spatial query, not oracle. Further the application gets all of the points and performs this query on the client. What the application returns is correct both visually and spatially.
Two of the points not returned in the oracle spatial query are 300km inside the bounding box. This far exceeds the .5 m tolerance used in our decimal degrees data set (SRID 8307).
I have experienced this problem on 9.2.0.1. I then patched that instance to 9.2.0.7 and duplicated the problem. I then exported the data and imported into a 10g release 1 database and again duplicated the problem. I have tried to re-index the data to no avail.
I have also tried different querytypes also yielding less than expected results.
The data looks like this:
243
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-58.45, -34.6, NULL),NULL, NULL)
254
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-56.18333, -34.883334, NULL), NULL, NULL)
377
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-70.666671, -33.449999, NULL), NULL, NULL)
385
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-68.149999, -16.5, NULL), NULL, NULL)
388
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-47.916667, -15.783333, NULL), NULL, NULL)
427
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-57.640066, -25.270295, NULL), NULL, NULL)
The number is the id field, the rest is the geometry.
The oracle spatial query above only returns id #s 359, 377,243,254,427
There are five returned records. The extra value is outside the bounding area. So it should not have been returned at all. It is all too strange.
I have seen this with different geometry types (points lines and area) as well.
If anyone has suggestions, I would appreciate your comments.
Thanks,
John

John,,
What you are seeing is the behavior you should expect in the geodetic space.
When you have a very long line connecting from longitude -101 to -23, that line
does not follow the same latitude value.
Since these points are in southern hemisphere, the line connecting them
will curve downward (this is the great circle line).
If you really want a line connecting with constant latitude, you should
use the MBR type for the window geometry which densifies the
lines along constant latitude before passing it into relate.
SDO_GEOMETRY(2003, 8307, NULL,
sdo_elem_info_array(1,1003,3),
sdo_ordinate_array(-101.8417,-52.8083, 23.8417,-13.8083))
siva

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

Index problem in a spatial query

I try to run following query in SQL Plus:
SELECT A.objectid FROM TABBDG A, TABREG B
WHERE A.objectid = 68 AND B.regionname = 'Hong2'
AND SDO_RELATE(A.geoloc, B.geoloc, 'mask=INSIDE querytype = WINDOW') = 'TRUE';
To find out weather or not objectid = 68 is inside of region (='Hong2"). I got following error messages:
ERROR at line 1:
ORA-13226: interface not supported without a spatial index
ORA-06512: at "MDSYS.MD", line 1723
ORA-06512: at "MDSYS.MDERR", line 8
ORA-06512: at "MDSYS.SDO_3GL", line 57
ORA-06512: at line 1
But when I try to add an index to table TABREG, I got following error:
ERROR at line 1:
ORA-29879: cannot create multiple domain indexes on a column list using same indextype
Seem to me that the index was already there. Can any one help me? Thanks.

I found out the reason of problem. I used an old version of EasyLoader (4.5?). When I get the latest EasyLoader V6.5, there is no problem any more to run spatial query. You can get lates EasyLoader V6.5 from MapInfo or from me at: [email protected]
Thanks for all help.

Spatial query performance problem after upgrade to 10G

I am in the process of converting my database from a 9i box to a new 10G 64-bit box. But I have found a problem which is causing some reports to be slower on the new box. I have simplified the queries down to having the user_sdo_geom_metadata table joined to use the diminfo in the queries (I know that I am not using them in these queries, but I simplified for testing purposes...)
If I run the following I get and look at the explain plan I get full table scans for both spatial tables and index lookups for the user_sdo_geom_metadata table queries and runs for about 14 seconds.
SELECT ROWNUM
from COUNTIES s,
NOMINATIONS O,
(select diminfo from user_sdo_geom_metadata where table_name='COUNTIES') S_DIM,
(select diminfo from user_sdo_geom_metadata where table_name='NOMINATIONS') O_DIM
where sdo_filter(S.GEOM,o.geom, 'querytype=WINDOW')='TRUE'
and sdo_geom.within_distance(o.geom,0,S.GEOM,.5)='TRUE';
If I just remove the two user_sdo_geom_metadata joins, I get spatial index usage on COUNTIES and the whole thing runs in less that a second.
SELECT ROWNUM
from COUNTIES s,
NOMINATIONS O
where sdo_filter(S.GEOM,o.geom, 'querytype=WINDOW')='TRUE'
and sdo_geom.within_distance(o.geom,0,S.GEOM,.5)='TRUE';
I have rebuilt the indexes, gathered stats, and tried hints to force the first query to use the spatial index. None of which made any change.
Has anyone else seen this?
Gerard Vidrine

Hi Gerard,
When the query window comes from a table Oracle always recommends:
1) Use the /*+ ordered */ hint
2) Put the table the quiery window comes from (geometry-2 in the query) first in the from clause
However, your query is also written very strange. Do you know about SDO_WITHIN_DISTANCE? Or are you trying to do SDO_ANYINTERACT (since the distance is 0)?
So I would write the query you have as:
SELECT s.ROWNUM
from NOMINATIONS O, COUNTIES s
where sdo_relate(S.GEOM,o.geom, 'querytype=WINDOW mask=anyinteract')='TRUE';
or in Oracle10g:
SELECT s.ROWNUM
from NOMINATIONS O, COUNTIES s
where sdo_anyinteract(S.GEOM,o.geom)='TRUE';

Select data with SDO_RELATE in lat long coordinate system(8307) in 10gR2

Hi all,
I have problem with selecting data from table.
Data are in lat lon coordinate system 8307.
These requests don't return any data:
SELECT ISSUE_ID FROM MAP_ISSUES WHERE SDO_FILTER(GEOMETRY, sdo_geometry (2003, 8307, null, sdo_elem_info_array (1,1003,1),sdo_ordinate_array(-180,-90, 180,-90, 180,90, -180,90, -180,-90)) ) = 'TRUE';
SELECT ISSUE_ID FROM MAP_ISSUES WHERE SDO_RELATE(GEOMETRY, sdo_geometry (2003, 8307, null, sdo_elem_info_array (1,1003,1),sdo_ordinate_array(-180,-90, 180,-90, 180,90, -180,90, -180,-90)), 'MASK=ANYINTERACT' ) = 'TRUE'
Optimized polygon does return all data correctly:
SELECT ISSUE_ID FROM MAP_ISSUES WHERE SDO_FILTER(GEOMETRY, sdo_geometry (2003, 8307, null, sdo_elem_info_array (1,1003,3),sdo_ordinate_array (-180,-90,180,90)) ) = 'TRUE'
Smaller polygon select data correctly too.
SELECT ISSUE_ID FROM MAP_ISSUES WHERE SDO_FILTER(GEOMETRY, sdo_geometry (2003, 8307, null, sdo_elem_info_array (1,1003,1),sdo_ordinate_array (52,-7, 54,-7 , 54,-5 , 52,-5, 52,-7)) ) = 'TRUE'
I have tried changed polygon to be clockwise, counter clockwise, make the area a bit smaller( 160 instead of 180, 89 instead of 90) nothing has helped.
My explanation than was, that Earth is sphere and each defined polygon defines TWO polygons in the sphere and there is convention that the smaller is chosen to select data. It would make sense along the previous results, but than I found one post which says that this is bug http://www.frontoracle.com/oracle-database/703/180703-size-of-are-of-interest-smaller-equals.html
I have found in other thread that max only 1/2 of Earth could be selected Different results using SDO_RELATE with polygon and rectangle type but it seems not true, because optimized bounding box works fine!
What is right? Is there anything in official documentation?
Is it bug.
Max 1/2 of Earth could be selected in one request.
Each polygon defines two areas in the Earth and the smaller one is used to do spatial SDO_RELATE operation?
Thanks!
Regards,
Zdenek

Zdenek,
A bug, or limititation, whichever you choose. IMHO if you ask for something, and don't get what you expect, it is a bug that could be fixed.
But for 10g anywho, the following applies, which is why I choose 120 degree breaks for my code as it is less than 180...
The following size limits apply with geodetic data:
■ No polygon element can have an area larger than one-half the surface of the Earth.
■ In a line, the distance between two adjacent coordinates cannot be greater than or
equal to one-half the perimeter (a great circle) of the Earth.
If you need to work with larger elements, first break these elements into multiple
smaller elements and work with them. For example, you cannot create a geometry
representing the entire ocean surface of the Earth; however, you can create multiple
geometries, each representing part of the overall ocean surface. To work with a line
string that is greater than or equal to one-half the perimeter of the Earth, you can add
one or more intermediate points on the line so that all adjacent coordinates are less
than one-half the perimeter of the Earth.
Bryan

Problem with SDO_FILTER combined with Timestamp and Order By using JDBC

I'm having a problem with using SDO_FILTER. I've included a test driver below. It seems that I'm having a problem with combining the SDO_FILTER, Timestamp, ORDER BY and a nested table using the Oracle 11.1.0.7.0 driver against Oracle 11g. The below query queryNoWork results in the following error:
Caused by: java.sql.SQLException: ORA-01422: exact fetch returns more than requested number of rows
ORA-06512: at "MDSYS.SDO_3GL", line 1320
at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70)
at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:133)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:206)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:455)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:413)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:1034)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:194)
at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:791)
at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:866)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1186)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3387)
at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3488)
at oracle.jdbc.driver.OraclePreparedStatementWrapper.execute(OraclePreparedStatementWrapper.java:1374)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.execute(WrappedPreparedStatement.java:299)
All of the other query variations seem to work. The GEOM column referenced is a Linestring that has only 2 points, start and end. Any help on this would be greatly appreciated. Thanks!
import java.math.BigDecimal;
import java.sql.Connection;
import java.sql.Date;
import java.sql.Driver;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.Timestamp;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Enumeration;
public class QueryTester
 public static void main(String[] args)
 try
 SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
 ArrayList<Object> queryParameters = new ArrayList<Object>();
 queryParameters.add(new BigDecimal(0));
 queryParameters.add(new Double(0));
 queryParameters.add(new BigDecimal(180));
 queryParameters.add(new Double(90));
 queryParameters.add(new java.sql.Date(sdf.parse("2005-12-25").getTime()));
 queryParameters.add(new java.sql.Date(sdf.parse("2005-12-26").getTime()));
 BigDecimal one = new BigDecimal(1);
 DriverManager.registerDriver((Driver) Class.forName("oracle.jdbc.driver.OracleDriver").newInstance());
 Enumeration<Driver> drivers = DriverManager.getDrivers();
 while(drivers.hasMoreElements())
 System.out.println(drivers.nextElement().getClass().getName());
 Connection conn = DriverManager.getConnection("jdbc:oracle:thin:@xxxx:1521:xxxx", "xxxx", "xxxx");
 String queryNoWork = "select * from (select ROWNUM rowcount, a.* from (select * from TRACK_SEGMENTS where ( ( sdo_filter(GEOM, sdo_geometry(2003, 8307, null, sdo_elem_info_array(1, 1003, 3), sdo_ordinate_array(?, ?, ?, ?) ), 'MASK=ANYINTERACT') = 'TRUE' and END_DATE >= ?and START_DATE < ?) and 1 = 1 and 1 = 1) and ((START_DATATYPE = 'maritime_dense')) ORDER BY ID ) a) where rowcount between 1 and 30000";
 String queryWorks0 = "select * from (select ROWNUM rowcount, a.* from (select * from TRACK_SEGMENTS where ( ( sdo_relate(GEOM, sdo_geometry(2003, 8307, null, sdo_elem_info_array(1, 1003, 3), sdo_ordinate_array(?, ?, ?, ?) ), 'MASK=ANYINTERACT') = 'TRUE' and END_DATE >= ?and START_DATE < ?) and 1 = 1 and 1 = 1) and ((START_DATATYPE = 'maritime_dense')) ORDER BY ID ) a) where rowcount between 1 and 30000";
 String queryWorks1 = "select * from (select ROWNUM rowcount, a.* from (select * from TRACK_SEGMENTS where ( ( sdo_filter(GEOM, sdo_geometry(2003, 8307, null, sdo_elem_info_array(1, 1003, 3), sdo_ordinate_array(?, ?, ?, ?) ), 'MASK=ANYINTERACT') = 'TRUE' and END_DATE >= TO_TIMESTAMP('2005-12-25','YYYY-MM-DD') and START_DATE < TO_TIMESTAMP('2005-12-26','YYYY-MM-DD')) and 1 = 1 and 1 = 1) and ((START_DATATYPE = 'maritime_dense')) ORDER BY ID ) a) where rowcount between 1 and 30000";
 String queryWorks2 = "select * from (select ROWNUM rowcount, a.* from (select * from TRACK_SEGMENTS where ( ( sdo_filter(GEOM, sdo_geometry(2003, 8307, null, sdo_elem_info_array(1, 1003, 3), sdo_ordinate_array(?, ?, ?, ?) ), 'MASK=ANYINTERACT') = 'TRUE' and END_DATE >= ?and START_DATE < ?) and 1 = 1 and 1 = 1) and ((START_DATATYPE = 'maritime_dense')) ) a) where rowcount between 1 and 30000";
 String queryWorks3 = "select * from TRACK_SEGMENTS where ( ( sdo_filter(GEOM, sdo_geometry(2003, 8307, null, sdo_elem_info_array(1, 1003, 3), sdo_ordinate_array(?, ?, ?, ?) ), 'MASK=ANYINTERACT') = 'TRUE' and END_DATE >= ?and START_DATE < ?) and 1 = 1 and 1 = 1) and ((START_DATATYPE = 'maritime_dense')) ORDER BY ID";
 String query = queryWorks0;
 PreparedStatement s = conn.prepareStatement(query);
 int parameterIndex = 0;
 for (Object object : queryParameters) {
 if (object instanceof Timestamp)
 s.setDate(++parameterIndex, (Date) object);
 else
 s.setObject(++parameterIndex, object);
 s.execute();
 ResultSet results = s.getResultSet();
 results.next();
 System.out.println("executed query - " + results.getLong(1));
 catch (Exception e)
 e.printStackTrace();
}

Is the TRACK_SEGMENTS table partitioned ?
It looks like in the case where the SQL does not work, it is not using the Spatial index. So can you add some index hints
in the query to force it to use the spatial index TRACK_SEGMENTS table ?
siva

Problems with sdo_nn query

Hi there. I am developing a mapping application whereby the user has the option of executing specific spatial queries in order to highlight aspects of certain map features present in the map, e.g. highlight all the parks (polygon geometries) falling within 10 km of a selected point on the map. When running spatial queries I do not encounter any problems whatsoever with sdo_filter, sdo_within_distance, and sdo_relate queries. However, when I try to execute an sdo_nn query, the query returns an incorrect result set. An example sdo_nn query appears as follows:
select /*+ ORDERED*/ a1.land from GEOMETRY_MAP.GEOM_POINT$_TABLE a1, attribute_map.landmark_table a2 where SDO_NN
(location, (MDSYS.SDO_GEOMETRY(2001, 8265, MDSYS.SDO_POINT_TYPE(-105.02074, 39.867985,NULL),NULL, NULL)), 'SDO_NUM_RES = 6')='TRUE'
and a1.land = a2.land and a2.cfcc = 'D43'
This particular example only returns 3 results as oppose to the 6 specified in the query. Just so that you can compare an sdo_nn example query to an sdo_within_distance query to check for inconsistency in the query set up, hte following is an example of an sdo_within_distance spatial query:
select /*+ ORDERED*/ a1.land from GEOMETRY_MAP.GEOM_POINT$_TABLE a1, attribute_map.landmark_table a2 where SDO_WITHIN_DISTANCE
(location, (MDSYS.SDO_GEOMETRY(2001, 8265, MDSYS.SDO_POINT_TYPE(-104.97126, 39.878693,NULL),NULL, NULL)), 'DISTANCE = 10000')='TRUE'
and a1.land = a2.land and a2.cfcc = 'D43'
The above sdo_within_distance query executes perfectly. Can anybody see anything wrong with the way I have set up the sdo_nn query. Everytime I execute a query it simply returns incorrect results. Thanks a lot, Joe

Hi Dan. I tried all your suggestions and seem to be closing in on the problem. The issue appears to be related to the "where" clause when I am querying >1 table in my database. The reason I am making this assumption is that when I perform sdo_nn queries related to points (queries 2 tables) and polygons (queries 3 tables) the sdo_nn query keeps returning the same results for each feature irrespective of what input coordinates are specified. However, when I perform polyline sdo_nn queries, the correct results are returned each time. The sdo_nn query for polyline features, e.g. rivers, looks as follows:
select /*+ ORDERED no_index (a1 tlid_index_name)*/ a1.TLID from
GEOMETRY_MAP.GEOM_POLYLINE_TABLE a1 where
SDO_NN(polyline, sdo_cs.viewport_transform(MDSYS.SDO_GEOMETRY(2003, 0, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3), MDSYS.SDO_ORDINATE_ARRAY(-104.85824,39.93833,-104.8487,39.94436)), 8265), 'SDO_BATCH_SIZE = 5')='TRUE' and a1.cfcc = 'B11' and rownum < 8
This returns accurate results irrespective of the input coordinates. As is evident from the above query I am querying solely one table even though there are 2 arguments in the "where" clause. Every time I perform an sdo_nn query on point features, e.g. schools, the query accesses 2 tables located in different schemas. This, as far as I can see, is the only difference between the point and polyline queries. The corresponding schools query is as follows:
select /*+ ORDERED no_index (a1 land_index_name)*/ a1.land from
GEOMETRY_MAP.GEOM_POINT$_TABLE a1, attribute_map.landmark_table a2 where SDO_NN(location, sdo_cs.viewport_transform(MDSYS.SDO_GEOMETRY(2003, 0, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3), MDSYS.SDO_ORDINATE_ARRAY (-105.0014,39.87302,-104.97824,39.883293)), 8265), 'SDO_BATCH_SIZE = 1')='TRUE' and a1.land = a2.land and a2.cfcc = 'D43' and rownum < 8
This returns incorrect results. Have you any ideas on what to do next? Thanks a lot, Joe

Performance problem with sdo_intersection. Your opinion?

Hi,
How would you accomplish the following task? (its not as complicated at it looks, please read on and feel challenged)
I got two tables A and B both having a geom column and other attributes.
Consider a row a1 in Table A having an attribute Name and a polygon in its geom-column, In table B I have a row b1, having an attribute Zone and also a polygon in its geom column. The two polygons a1.geom and b1.geom partially intersect.
What I need is a table with the following columns:
IDLayer1, IDLayer2, Name, Zone, geom
The rows must look something like this:
Row 1 (the part of a1.geom also covered by b1.geom)
a1, b1, myName, myZone, SDO_GEOMETRY.
Row 2 (the part of a1.geom not covered by b1.geom):
a1, null, myName, null, SDO_GEOMETRY
Row 3 ( the part of b1.geom not covered by a1)
Null, b1, null, myZone, SDO_GEOMETRY)
How I solved this problem:
By calling a series of three SELECT statements I create Row1, 2 and 3 and fill in the result table.
Row 1 is created as:
INSERT INTO
SELECT /* ORDERED +/ A.id, B.id, A.Name, B.Zone, SDO_GEOM.SDO_INTERSECTION(A.geom, B.geom, 0.001)
FROM A, B
WHERE SDO_RELATE (a.geom, b.geom, 'mask=anyinteract') = 'TRUE'
Row 2 is created as:
SELECT /* ORDERED +/ A.id, null, A.Name, null, SDO_GEOM.SDO_DIFFERENCE(A.geom, B.geom, 0.001)
FROM A, B
WHERE SDO_RELATE (a.geom, b.geom, 'mask=anyinteract') = 'TRUE'
Row 3 is created as:
SELECT /* ORDERED +/ null, B.id, null, B.Zone, SDO_GEOM.SDO_DIFFERENCE(B.geom, A.geom, 0.001)
FROM A, B
WHERE SDO_RELATE (a.geom, b.geom, 'mask=anyinteract') = 'TRUE'
Note: The queries above are simplified and dont expose all details. The important point is, I do first an intersection, followed by two differences. I improved the performance, by reusing the result from the intersection query in the difference-queries. That is: I actually dont do an SDO_RELATE in the where clauses of query 2 and 3 but instead I use the ids from the Intersection query (If there is an intersection, there must also be a difference).
A second simplification in the queries given above concerns the Difference operation when a geometry a1 from Layer A intersects with several geometries from Layer B (say b1 and b2). In this case I first call an Aggregate function:
SDO_AGGR_UNION ( mdsys.sdoaggrtype(B.geom, 0.01))
WHERE B.id someConditionResulting in b1 and b2
The difference operation then looks something like this:
SDO_GEOM.SDO_DIFFERENCE(A.geom, aggregatedGeometry, 0.001)
Now the Problem:
My Tables are quiet large containing thousands of geometries. Using the approach described above, it takes hours to compute the result. When doing the same task in a Desktop GIS (like Mapinfo), a single intersect operation is needed and the result is obtained within a few seconds.
Question:
How would you tackle the problem? May I improve the performance just by tuning the queries or is my approach wrong? What are your suggestions?
Thank you!
Marco

You will get better performance if you make the three resulting geometries three
columns in your new table.
I am not sure why you need them as three rows.
You can do:
select sdo_geom.sdo_intersection(a.geom, b.geom, tolerance),
sdo_geom.sdo_difference(a.geom, b.geom, tolerance),
sdo_geom.sdo_difference(b.geom, a.geom, tolerance)
where SDO_JOIN ...
This way, you can do the whole thing with one select.
siva

Inconsistent SDO_RELATE results when querying 2.5D data

Oracle 11.1.0.7 with Patch 8343061 on Windows Server 2003 32bit.
I'm getting inconsistent results from SDO_RELATE results when querying 2.5D data. Some geometries I expect to be OVERLAPBDYDISJOINT, are not always being returned by SDO_RELATE when using the OVERLAPBDYDISJOINT mask. It seems that the order of the tables makes a difference to the result.
Here's a table with one 2.5D geometry and a 2D index:
CREATE TABLE TEST1 (
ID                NUMBER PRIMARY KEY,
GEOMETRY     SDO_GEOMETRY);
INSERT INTO TEST1 (id, geometry) VALUES (
1,
SDO_GEOMETRY(3002, 2157, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(561695.935, 834005.726, 25.865,
561696.229, 834005.955, 25.867, 561686.278, 834015.727, 26.088, 561685.179, 834019.771, 26.226, 561680.716, 834022.389, 26.226,
561674.434, 834025.125, 26.171, 561671.963, 834032.137, 25.667, 561670.832, 834037.185, 25.619, 561667.946, 834042.976, 25.84,
561666.717, 834047.218, 26.171, 561664.229, 834051.781, 26.778, 561660.041, 834055.935, 26.64, 561657.514, 834061.742, 26.53,
561658.59, 834067.116, 27.882, 561657.67, 834070.739, 28.821, 561653.028, 834073.777, 29.042, 561653.234, 834078.769, 28.379,
561658.336, 834080.105, 29.511, 561664.582, 834079.468, 31.94, 561669.257, 834075.821, 33.707, 561672.716, 834074.456, 33.707,
561676.875, 834077.262, 33.735, 561675.868, 834081.55, 33.707, 561673.131, 834087.641, 33.679, 561672.208, 834093.502, 33.238,
561668.578, 834100.894, 33.735, 561666.013, 834106.399, 33.679, 561661.408, 834111.23, 33.514, 561654.854, 834117.181, 33.486,
561651.695, 834122.292, 33.569, 561649.112, 834128.847, 33.431, 561645.982, 834134.786, 33.293, 561642.485, 834141.235, 33.072,
561642.138, 834150.085, 33.293, 561646.072, 834159.721, 36.578, 561647.274, 834165.532, 37.02, 561646.359, 834170.867, 37.02,
561645.42, 834175.485, 36.799, 561642.44, 834180.977, 36.826, 561638.677, 834185.419, 36.771, 561636.693, 834194.824, 37.158,
561635.462, 834202.105, 37.241, 561631.998, 834208.745, 37.268, 561628.871, 834213.994, 37.241, 561627.554, 834220.393, 37.82,
561625.79, 834226.697, 39.532, 561620.561, 834236.494, 39.891, 561619.265, 834249.687, 39.697, 561619.883, 834260.02, 41.326,
561620.977, 834264.399, 43.093, 561622.557, 834270.723, 43.452, 561622.172, 834276.978, 43.452, 561621.347, 834285.541, 43.479,
561622.214, 834292.055, 43.645, 561619.718, 834302.583, 43.755, 561616.762, 834316.47, 43.755, 561608.842, 834328.241, 43.7,
561606.346, 834334.93, 43.7, 561605.27, 834341.929, 43.7, 561603.925, 834350.648, 43.728, 561602.462, 834358.405, 43.838,
561599.552, 834366.629, 44.031, 561594.551, 834374.291, 43.396, 561590.644, 834383.986, 43.065, 561588.48, 834392.21, 44.942,
561586.923, 834397.32, 46.737, 561584.608, 834402.898, 49.299, 561581.389, 834410.194, 50.077, 561580.437, 834419.49, 51.907,
561580.438, 834427.63, 53.127, 561582.245, 834433.389, 55.791, 561586.664, 834433.397, 57.503, 561593.88, 834433.608, 57.475,
561596.305,834439.653, 57.42, 561591.804, 834445.862, 57.309, 561589.097, 834447.689, 57.014)));
SELECT sdo_geom.validate_geometry_with_context(geometry, 0.0005) FROM TEST1;
DELETE FROM user_sdo_geom_metadata WHERE table_name = 'TEST1' AND column_name = 'GEOMETRY';
INSERT INTO user_sdo_geom_metadata VALUES ('TEST1','GEOMETRY',
     MDSYS.SDO_DIM_ARRAY(
     MDSYS.SDO_DIM_ELEMENT('X',400000,750000,0.0005),
     MDSYS.SDO_DIM_ELEMENT('Y',500000,1000000,0.0005),
     MDSYS.SDO_DIM_ELEMENT('Z',-10000,10000,0.0005)
), 2157);
DROP INDEX TEST1_SPIND;
CREATE INDEX TEST1_SPIND ON TEST1(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('layer_gtype=line sdo_indx_dims=2');And here's another table with a 2D geometry and a 2D index:
CREATE TABLE TEST2 (
ID                NUMBER PRIMARY KEY,
GEOMETRY     SDO_GEOMETRY);
INSERT INTO TEST2 (id, geometry) VALUES (
1,
SDO_GEOMETRY(2002, 2157, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(561816.516, 834055.581, 561819.504, 834057.173,
561817.942, 834060.818, 561810.044, 834078.997, 561805.576, 834087.634, 561801.572, 834094.299, 561798.558, 834100.467,
561796.254, 834107.637, 561793.754, 834115.605, 561794.049, 834123.694, 561793.698, 834130.518, 561792.905, 834138.883,
561787.867, 834145.772, 561782.544, 834150.548, 561777.707, 834156.53, 561773.945, 834161.32, 561771.061, 834166.957,
561768.155, 834173.131, 561764.735, 834178.744, 561759.603, 834187.782, 561756.146, 834195.493, 561753.416, 834198.821,
561754.141, 834205.691, 561756.768, 834209.681, 561757.217, 834216.701, 561753.086, 834232.46, 561744.371, 834254.589,
561740.936, 834263.001, 561737.198, 834272.208, 561732.231, 834284.915, 561730.52, 834297.01, 561728.339, 834310.053,
561727.825, 834328.069, 561730.461, 834342.992, 561729.808, 834367.948, 561730.216, 834396.988, 561732.273, 834419.047,
561732.783, 834424.668, 561731.647, 834432.212, 561731.872, 834439.436, 561731.39, 834449.269, 561732.041, 834462.813,
561733.583, 834471.926, 561733.229, 834485.049, 561730.868, 834498.462, 561726.379, 834512.59, 561725.776, 834528.932,
561727.488, 834555.23, 561729.357, 834577.873, 561731.05, 834595.931, 561731.163, 834611.928, 561734.057, 834637.031,
561732.67, 834636.4, 561725.401, 834633.796, 561721.039, 834632.493, 561718.777, 834632.167, 561710.437, 834632.888,
561647.929, 834636.658, 561644.963, 834630.085, 561632.796, 834629.813, 561625.553, 834627.647, 561620.473, 834626.711,
561608.718, 834624.94, 561599.935, 834619.684, 561596.67, 834613.843, 561594.27, 834607.774, 561592.513, 834601.752,
561591.349, 834593.899, 561597.265, 834584.888, 561595.956, 834571.479, 561595.075, 834556.196, 561593.997, 834539.68,
561594.316, 834528.071, 561595.261, 834516.44, 561595.538, 834504.804, 561597.227, 834497.417, 561599.3, 834490.416,
561601.265, 834482.61, 561605.126, 834475.502, 561599.232, 834473.683, 561593.076, 834471.379, 561599.154, 834451.112,
561589.097, 834447.689, 561591.804, 834445.862, 561596.305, 834439.653, 561593.88, 834433.608, 561582.245, 834433.389,
561580.438, 834427.63, 561580.437, 834419.49, 561581.389, 834410.194, 561584.608, 834402.898, 561586.923, 834397.32,
561588.48, 834392.21, 561590.644, 834383.986, 561594.551, 834374.291, 561599.552, 834366.629, 561602.462, 834358.405,
561603.925, 834350.648, 561605.27, 834341.929, 561606.346, 834334.93, 561608.842, 834328.241, 561616.762, 834316.47,
561619.718, 834302.583, 561622.214, 834292.055, 561621.347, 834285.541, 561622.172, 834276.978, 561622.557, 834270.723,
561620.977, 834264.399, 561619.883, 834260.02, 561619.265, 834249.687, 561620.561, 834236.494, 561625.79, 834226.697,
561627.554, 834220.393, 561628.871, 834213.994, 561631.998, 834208.745, 561635.462, 834202.105, 561636.693, 834194.824,
561638.677, 834185.419, 561642.44, 834180.977, 561645.42, 834175.485, 561646.359, 834170.867, 561647.274, 834165.532,
561646.072, 834159.721, 561642.138, 834150.085, 561642.485, 834141.235, 561645.982, 834134.786, 561649.112, 834128.847,
561651.695, 834122.292, 561654.854, 834117.181, 561661.408, 834111.23, 561666.013, 834106.399, 561668.578, 834100.894,
561672.208, 834093.502,561673.131, 834087.641, 561675.868, 834081.55, 561676.875, 834077.262, 561672.716, 834074.456,
561669.257, 834075.821, 561664.582, 834079.468, 561658.336, 834080.105, 561653.234, 834078.769, 561653.028, 834073.777,
561657.67, 834070.739, 561658.59, 834067.116, 561657.514, 834061.742, 561660.041, 834055.935, 561664.229, 834051.781,
561666.717, 834047.218, 561667.946, 834042.976, 561670.832, 834037.185, 561671.963, 834032.137, 561674.434, 834025.125,
561680.716, 834022.389, 561685.179, 834019.771, 561686.278, 834015.727, 561696.229, 834005.955, 561695.935, 834005.726,
561677.805, 833994.91, 561683.163, 833985.817, 561703.01, 833949.434, 561725.891, 833961.856, 561744.35, 833971.197,
561768.396, 833983.86, 561777.842, 833988.883, 561798.333, 833999.743, 561797.243, 834005.725, 561783.574, 834040.515,
561798.127, 834046.391, 561807.001, 834050.509, 561816.516, 834055.581)));
SELECT sdo_geom.validate_geometry_with_context(geometry, 0.0005) FROM TEST2;
DELETE FROM user_sdo_geom_metadata WHERE table_name = 'TEST2' AND column_name = 'GEOMETRY';
INSERT INTO user_sdo_geom_metadata VALUES ('TEST2','GEOMETRY',
     MDSYS.SDO_DIM_ARRAY(
     MDSYS.SDO_DIM_ELEMENT('X',400000,750000,0.0005),
     MDSYS.SDO_DIM_ELEMENT('Y',500000,1000000,0.0005)
), 2157);
DROP INDEX TEST2_SPIND;
CREATE INDEX TEST2_SPIND ON TEST2(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('layer_gtype=line sdo_indx_dims=2');Now if I check how these two geometries relate to each other, the answer is OVERLAPBDYDISJOINT, which makes sense when inspecting the geometries.
SQL> SELECT
2 sdo_geom.relate(t1.geometry, 'determine', t2.geometry, 0.0005) relate_1_to_2,
3 sdo_geom.relate(t2.geometry, 'determine', t1.geometry, 0.0005) relate_2_to_1
4 FROM test2 t2, test1 t1
5 WHERE t1.id = t2.id;
RELATE_1_TO_2        RELATE_2_TO_1
OVERLAPBDYDISJOINT   OVERLAPBDYDISJOINT
1 row selected.So, I'd expect this query to return something...
SELECT /*+ ORDERED */ t1.id, t2.id, sdo_geom.relate(t1.geometry, 'determine', t2.geometry, 0.0005) relate
FROM test2 t2, test1 t1
WHERE sdo_relate(t1.geometry, t2.geometry, 'mask=overlapbdydisjoint') = 'TRUE'
AND t1.id = 1
AND t2.id = 1;Nada. And this...
SELECT /*+ ORDERED */ t1.id, t2.id, sdo_geom.relate(t1.geometry, 'determine', t2.geometry, 0.0005) relate
FROM test1 t1, test2 t2
WHERE sdo_relate(t2.geometry, t1.geometry, 'mask=overlapbdydisjoint') = 'TRUE'
AND t1.id = 1
AND t2.id = 1;Nada.
And this...
SQL> SELECT /*+ ORDERED */ t1.id, t2.id, sdo_geom.relate(t1.geometry, 'determine', t2.geometry, 0.0005) relate
2 FROM test2 t2, test1 t1
3 WHERE sdo_relate(t2.geometry, t1.geometry, 'mask=overlapbdydisjoint') = 'TRUE'
4 AND t1.id = 1
5 AND t2.id = 1;
        ID         ID RELATE
         1          1 OVERLAPBDYDISJOINT
1 row selected.This version gives the right answer.
Can anyone explain this?

Hi,-
I think you are running into these bugs 7158518 and 7710726.
Could you please request the patch for the bugs so that they are published on Metalink
if they dont exist there?
Please let us know if these fix your problem.
Best regards
baris

Sdo_relate in alternate user with views.

Hello,
I am using Oracle 8.1.7.2 and creating a view as follows.
CREATE OR REPLACE VIEW REPORT_STREETINFO AS
SELECT DT.ID, MKT.CODE MKT_CODE, PRIM_NAME,
NVL(MIN(DECODE(ST.FROMNRLE, 0, NULL, ST.FROMNRLE)),0)
MIN_FROMNRLE,
MAX(ST.TONRLE) MAX_TONRLE,
NVL(MIN(DECODE(ST.FROMNRRI, 0, NULL, ST.FROMNRRI)),0)
MIN_FROMNRRI,
MAX(ST.TONRRI) MAX_TONRRI,
MKT.NAME MKT_NAME, MKT.NAME2 MKT_NAME2, MKT.STREET MKT_STREET,
MKT.CITY MKT_CITY,
MKT.ZIP MKT_ZIP,
MKT.PO_BOX MKT_POBOX
FROM STREETINFO ST, DISTAREA DT, MARKET MKT, DISTAREA_WA
DTWA,WALKERAREA WA
WHERE PRIM_NAME IS NOT NULL AND
(ST.FROMNRLE != 0 AND ST.TONRLE != 0 OR
ST.FROMNRRI != 0 AND ST.TONRRI != 0) AND
DTWA.DISTAREA_ID = DT.ID AND
WA.WASID = DTWA.WASID AND
MKT.SRNO = DT.MARKET_ID AND
MDSYS.SDO_RELATE(ST.GEOLOC, WA.GEOLOC, 'mask=
(inside+coveredby+on)
querytype=window') = 'TRUE'
GROUP BY PRIM_NAME, MKT.CODE, DT.ID,
MKT.NAME, MKT.NAME2, MKT.STREET, MKT.CITY, MKT.ZIP, MKT.PO_BOX
ORDER BY PRIM_NAME
I grant the rights to this above view to an alternate user. When
I fire a query like
SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 22;
from the owner of the view I have no problems but when I fire
this query from alternate user I get error
ORA-03113 end-of-file on communication channel.
I checked out the documentation which states from physical
failure but this is definately not the case.
Any help on this problem will be appretiated.
Amol.

Hello Ravi,
I am posting a spool file which shows the steps I have followed
and error that I get. I have taken care with the grants from
mdsys for the SDO_RELATE and all the other operators.
DEV>SHO USER
USER ist "GEODIS"
DEV>CREATE OR REPLACE VIEW REPORT_STREETINFO AS
2 SELECT DT.ID, MKT.CODE MKT_CODE, PRIM_NAME,
3 NVL(MIN(DECODE(ST.FROMNRLE, 0, NULL, ST.FROMNRLE)),0)
MIN_FROMNRLE,
4 MAX(ST.TONRLE) MAX_TONRLE,
5 NVL(MIN(DECODE(ST.FROMNRRI, 0, NULL, ST.FROMNRRI)),0)
MIN_FROMNRRI,
6 MAX(ST.TONRRI) MAX_TONRRI,
7 MKT.NAME MKT_NAME, MKT.NAME2 MKT_NAME2, MKT.STREET
MKT_STREET, MKT.CITY MKT_CITY,
8 MKT.ZIP MKT_ZIP,
9 MKT.PO_BOX MKT_POBOX
10 FROM STREETINFO ST, DISTAREA DT, MARKET MKT, DISTAREA_WA
DTWA,WALKERAREA WA
11 WHERE PRIM_NAME IS NOT NULL AND
12 (ST.FROMNRLE != 0 AND ST.TONRLE != 0 OR
13 ST.FROMNRRI != 0 AND ST.TONRRI != 0) AND
14 DTWA.DISTAREA_ID = DT.ID AND
15 WA.WASID = DTWA.WASID AND
16 MKT.SRNO = DT.MARKET_ID AND
17 MDSYS.SDO_RELATE(ST.GEOLOC, WA.GEOLOC, 'mask=
(inside+coveredby+on)
18 querytype=window') = 'TRUE'
19 GROUP BY PRIM_NAME, MKT.CODE, DT.ID,
20 MKT.NAME, MKT.NAME2, MKT.STREET, MKT.CITY, MKT.ZIP,
MKT.PO_BOX
21 ORDER BY PRIM_NAME
22 /
View wurde angelegt.
DEV>SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108;
PRIM_NAME
Altenhagener
Weg
Alter
Zollweg
Am
Knill
Am
Kroog
Am
Lehmberg
Babenstieg
Bargteheider
Strasse
Bekassinenau
Blomeweg
Boltenhagener
Strasse
Bublitzer
Strasse
Carlssonweg
Farmsener
Zoll
Finkenfurth
Grvmitzer
Weg
Grundherrenstrasse
Herwardistrasse
Hohenkamp
Hoher
Berg
Im
Wiesengrund
Jacobshagener
Weg
Kohvvedstrasse
Kvsliner
Strasse
Krohnsheide
K|hlungsborner
Strasse
Nienhagener
Strasse
Pfefferstrasse
Rahlstedter
Stieg
Rahlstedter
Weg
Raschweg
R|genwalder
Strasse
Rummelsburger
Strasse
Sandkule
Scharbeutzer
Strasse
Sierksdorfer
Strasse
Stargarder
Strasse
Thiessenweg
Timmendorfer
Stieg
Timmendorfer
Strasse
Treptower
Strasse
Wolliner
Strasse
41 Zeilen ausgewdhlt.
DEV>GRANT SELECT ON REPORT_STREETINFO TO PWEIH;
Benutzerzugriff (Grant) wurde erteilt.
DEV>CREATE SYNONYM PWEIH.REPORT_STREETINFO FOR
GEODIS.REPORT_STREETINFO;
Synonym wurde angelegt.
DEV>CONN PWEIH/PWEIH@DEVELOP
Connect durchgef|hrt.
DEV>DESC REPORT_STREETINFO;
Name Null? Typ
ID NOT NULL NUMBER(10)
MKT_CODE VARCHAR2(10)
PRIM_NAME VARCHAR2(40)
MIN_FROMNRLE VARCHAR2(40)
MAX_TONRLE NUMBER
MIN_FROMNRRI VARCHAR2(40)
MAX_TONRRI NUMBER
MKT_NAME VARCHAR2(40)
MKT_NAME2 VARCHAR2(40)
MKT_STREET VARCHAR2(40)
MKT_CITY VARCHAR2(40)
MKT_ZIP VARCHAR2(9)
MKT_POBOX VARCHAR2(40)
DEV>SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108;
SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108
FEHLER in Zeile 1:
ORA-03113: Unerwartetes \bertragungsende in Kommunikation
DEV>SPOOL OFF;
Regards,
Amol.

SDO_RELATE and ORA-03113 error

Hello,
I am trying to use the SDO_RELATE function and I receive the following error:
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Using the following SQL
SELECT ufi FROM ROADLINE A
WHERE MDSYS.SDO_RELATE(
A.GEOMETRY, mdsys.sdo_geometry( 2003,null,null,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(132,-12,133,-11)),
'mask=ANYINTERACT querytype=WINDOW') = 'TRUE'
A similar search using the SDO_FILTER instead of SDO_RELATE and removing the mask=ANYINTERACT works ok.
Can anyone suggest anything?
Thanks in advance.
Gunter

Hi Gunter,
It looks like there may be other issues. Can you post the version of Oracle you are using, and try debugging just a little bit more to try to narrow the problem down?
This might help to determine which geometry the failure is occuring at:
create table tt as select ufi,geometry
from roadline where rownum < 1;
declare
ufi number ;
window_geom mdsys.sdo_geometry := mdsys.sdo_geometry( 2003,null,null, mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(132,-12,133,-11));
theGeom mdsys.sdo_geometry ;
TYPE geomcursor is REF CURSOR ;
aCursor geomcursor;
relationship varchar2(30);
begin
open aCursor FOR 'SELECT ufi, geometry from roadline A WHERE SDO_filter( A.GEOMETRY,:WINDOW_GEOM, ''querytype=WINDOW'') = ''TRUE''' using window_geom;
loop
FETCH aCursor INTO ufi, theGeom ;
EXIT WHEN aCursor%NOTFOUND ;
execute immediate 'insert into tt values (:ufi,:theGeom)'
using ufi,theGeom;
execute immediate 'commit';
relationship := sdo_geom.relate(theGeom,'anyinteract',window_geom,0.05);
end loop;
end;
If you see the same error, hopefully it will be determining the relationship between the last geometry in the table tt and the query window. If you can check this, and if this is the case post the geometry that is failing as well as the contents of user_sdo_geom_metadata for roadline that would be great.
Dan

Wrong results in SDO_RELATE function using optimized rectangle

Hi there,
I'm using a query like this to catch points thet are inside a users bounding box:
select * from data where sdo_relate(GPS_POSITION,
mdsys.sdo_geometry(2003,8307,null, mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(-100 ,-80, 100, 80 )),'mask=INSIDE querytype=window layer_gtype=point') = 'TRUE'
This works fine for small rectangles, but if I choose a large rectangle (like above), I get completely wrong data.
Are there any restrictions on the size of the rectangle?
And if, how to overcome this?
Thanks in advance and best regards,
Florian
Edited by: user649907 on 29.10.2008 09:00

Guys, thanks so far!
So I could split up my query to some smaller rectangles to solve the problem.
Right now I realized my problem seems to be a bit larger.
Queries even don't work on smaller rectangles.
When I roughly cover Australia, I get some data in Australia, but also lots of data between Australia and South America.
Query looks like this:
select * from data where
sdo_relate(GPS_POSITION,
mdsys.sdo_geometry(2003,8307,null, mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(115,-39, 155, -13)),
'mask=ANYINTERACT querytype=window layer_gtype=point') = 'TRUE'
I get points like this back:
-164, -54
-160, -64
and lots more.
We use Oracle 10g2.
Any idea?
Florian

SDO_Relate problem

Similar Messages

Maybe you are looking for