SDO_INTERSECTION

Here are 3 Examples with the function
SDO_GEOM.SDO_INTERSECTION and unexpected results
Can anybody explain the unexpected results?
Did anybody find similar problems?
Environment:
Server: Windows 2000 Server, Oracle Enterprise Edition 9.2.0.1
Client: Windows 2000 Professional, Oracle Client 9.2.0.1
There are two polagon tables
- DKM_KG with 52 large polygons
- DKM_N_AREA with more tahn 200000 small polygons
Normally the small polygons are "inside or coveredby" the large polygons.
Due to data capture errors some small polygons cross the boundaries of the large polygons.
About 4000 small polygons are incorrect.
We want to find out how much of the area of a small polygon is "outside".
1.EXAMPLE
SQL> select diminfo from user_sdo_geom_metadata where table_name='DKM_N_AREA' ;
DIMINFO(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOLERANCE)
SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -70000, 20000, .000001), SDO_DIM_ELEMENT('Y',
185000, 275000, .000001), SDO_DIM_ELEMENT('Z', 0, 4000, .000001))
SQL> select diminfo from user_sdo_geom_metadata where table_name='DKM_KG' ;
DIMINFO(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOLERANCE)
SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -70000, 20000, .000001), SDO_DIM_ELEMENT('Y',
185000, 275000, .000001), SDO_DIM_ELEMENT('Z', 0, 4000, .000001))
SQL> select sdo_geom.validate_geometry_with_context(sdo_geometry,diminfo)
2 from dkm_n_area,
3 user_sdo_geom_metadata
4 where id=87324 and table_name='DKM_N_AREA';
SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(SDO_GEOMETRY,DIMINFO)
TRUE
SQL> select sdo_geom.validate_geometry_with_context(sdo_geometry,diminfo)
2 from dkm_kg,
3 user_sdo_geom_metadata
4 where kgnr =91109 and table_name='DKM_KG';
SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(SDO_GEOMETRY,DIMINFO)
TRUE
SQL>
SQL> select sdo_geom.sdo_intersection(a.sdo_geometry,ma.diminfo, b.sdo_geometry,mb.diminfo)
2 from dkm_kg b,dkm_n_area a, user_sdo_geom_metadata mb,
3 user_sdo_geom_metadata ma
4 where
5 mb.table_name='DKM_KG'and ma.table_name='DKM_N_AREA' and
6      b.kgnr =91109 and a.id=87324;
SDO_GEOM.SDO_INTERSECTION(A.SDO_GEOMETRY,MA.DIMINFO,B.SDO_GEOMETRY,MB.DIMINFO)(S
SDO_GEOMETRY(3005, 1028000, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 3), SDO_ORDINATE_ARR
AY(-58141.667, 262670.685, 0, -54724.99, 259343.861, 0, -54712.201, 259324.771,
0))
3 points for the intersection????
SQL> select sdo_geom.sdo_area(sdo_geom.sdo_intersection(a.sdo_geometry,ma.diminfo,
2 b.sdo_geometry,mb.diminfo),0.0001)
3 from dkm_kg b,dkm_n_area a, user_sdo_geom_metadata mb,
4 user_sdo_geom_metadata ma
5 where
6 mb.table_name='DKM_KG'and ma.table_name='DKM_N_AREA' and
7 b.kgnr =91109 and a.id=87324;
SDO_GEOM.SDO_AREA(SDO_GEOM.SDO_INTERSECTION(A.SDO_GEOMETRY,MA.DIMINFO,B.SDO_GEOM
0
NO AREA ????
But with other parameters we get the desired and expected result:
SQL> select sdo_geom.sdo_area(sdo_geom.sdo_intersection(a.sdo_geometry,
2 b.sdo_geometry,0.000000001),0.00001)
3 from dkm_kg b,dkm_n_area a
4 where b.kgnr =91109 and a.id=87324;
SDO_GEOM.SDO_AREA(SDO_GEOM.SDO_INTERSECTION(A.SDO_GEOMETRY,B.SDO_GEOMETRY,0.0000
469693.356
This is the expected result - there are more than 2000 coordinate values
2.EXAMPLE
Another exapmple with unexpected effects:
SELECT sdo_geom.sdo_area(sdo_geom.sdo_intersection(a.sdo_geometry, b.sdo_geometry,
0.000000001),0.000001)
FROM dkm_kg b, dkm_n_area a
WHERE b.kgnr = 90109
AND a.id = 326208;
SDO_GEOM.SDO_AREA(SDO_GEOM.SDO_INTERSECTION(A.SDO_GEOMETRY,B.SDO_GEOMETRY,0.0000
1572512.2
Now the same intersection with another tolerance:
SELECT sdo_geom.sdo_intersection(a.sdo_geometry, b.sdo_geometry, 1)
FROM dkm_kg b, dkm_n_area a
WHERE b.kgnr = 90109
AND a.id = 326208;
There ist no result.
The oracle process needs 100% of the Server CPU and after 10 hours there is no result.
The session is killed:
alter system kill session '9,2064';
The session is marked as killed, but the oracle process still needs 100% CPU.
The instance is shut down, the oracle process still needs 100% CPU, onls a 100KB memory less are needed.
The oracle service has to be stopped (stop process) to release the CPU.
3.EXAMPLE
A third example with strange results
( all geometries are valid!)
select sdo_geom.sdo_intersection(a.sdo_geometry, ad.diminfo,
b.sdo_geometry, bd.diminfo)
from dkm_n_area a, user_sdo_geom_metadata ad,
dkm_kg b, user_sdo_geom_metadata bd
where a.id=261510 and b.kgnr=90013 and
ad.table_name='DKM_N_AREA' and bd.table_name='DKM_KG';
FEHLER in Zeile 2:
ORA-03113: End of Communication!!
A CORE.LOG is produced like
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
Process Id: 0x00000998 Thread Id : 0x00000c54 Time : Fri Sep 12 18:12:38
Excp. Code: 0xc0000005 Excp. Type: ACCESS_VIO Flags: 0x00000000
------------------- Registers ----------------------------
eip = 014bbc29 esp = 05e3a8bc ebp = 05e3ab10 edi = 06a37840 esi = 05e3aad0
eax = 00004020 ebx = 00000000 ecx = 06a37820 edx = 00000000
ecs = 0000001b eds = 00000023 ees = 00000023 ess = 00000023
egs = 00000000 efs = 0000003b
The same query with other tolerances
SQL> select sdo_geom.sdo_intersection(a.sdo_geometry,
2 b.sdo_geometry,0.001)
3 from dkm_n_area a,
4 dkm_kg b
5 where a.id=261510 and b.kgnr=90013;
SDO_GEOM.SDO_INTERSECTION(A.SDO_GEOMETRY,B.SDO_GEOMETRY,0.001)(SDO_GTYPE, SDO_SR
SDO_GEOMETRY(3002, 1028000, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARR
AY(-51608.15, 229893.21, 0, -51606.55, 229890.721, 0))
and
SQL> select sdo_geom.sdo_intersection(a.sdo_geometry,
2 b.sdo_geometry,1)
3 from dkm_n_area a,
4 dkm_kg b
5 where a.id=261510 and b.kgnr=90013;
SDO_GEOM.SDO_INTERSECTION(A.SDO_GEOMETRY,B.SDO_GEOMETRY,1)(SDO_GTYPE, SDO_SRID,
NULL-Result!

After the installation of 9.2.0.4 patch all works well.
A hint for spatial-users with user-defined entries in
MDSYS.CS_SRS table:
Any user-added records are lost during the upgrade.
Save any user defined records in MDSYS tables before applying this patch.

Similar Messages

  • ORA-13050:unable to construct spatial object in using SDO_INTERSECTION

    Hi Specialists,
    I am using Oracle Spatial and getting the ORA-13050 error when using the SDO_Intersection procedure. Below are the details of this.
    Objective: To find the addresses whose boundary lie within a user defined polygon.
    Input: List of coordinates for the user defined poygon.
    Query I am using: SELECT SDO_GEOM.SDO_INTERSECTION (add.boundary, SDO_GEOMETRY(2003,8311,NULL, SDO_ELEM_INFO_ARRAY(1,1003,1),
    SDO_ORDINATE_ARRAY( 149.986507,-36.727242,149.985898,-36.726819,149.986756,-36.726512,149.987288,-36.726803,149.986507,-36.727242)), 0.000001)
    FROM address add
    WHERE add.id = '254378298'
    Error Received:
    ORA-13050: unable to construct spatial object
    ORA-06512: at "MDSYS.SDO_3GL", line 715
    ORA-06512: at "MDSYS.SDO_3GL", line 745
    ORA-06512: at "MDSYS.SDO_GEOM", line 3016
    ORA-06512: at "MDSYS.SDO_GEOM", line 3065
    Please can any one help me in this issue very urgent.
    Thanks,
    Ashish

    Hi All,
    The problem has been resolved by transforming the user defined polygon coordinates into the database specific coordinate system.
    Thanks

  • Clipping algorithm implemented in Oracle Spatial for SDO_INTERSECTION

    Hi!
    Does anybody knows which clipping algorithm is implemented in Spatial for SDO_INTERSECTION function in 10g or 11g? It's probably some of well-known algorithm (Sutherland–Hodgman, Weiler–Atherton, Vatti ...) with some modifications made to it. I'm just not sure which one. I'm doing a short presentation on Oracle Spatial clipping capabilities so that info might come in handy.
    Thanks!
    rawcofe

    Thanks for your post. Yes, Sutherland-Hodgman is good and easy to implement if you have convex clipping polygons. However, i do not need to implement it. I just want to know which algorithm Oracle Spatial uses for clipping so I can describe it in greater detail during my presentation. :-)

  • Performance problem with sdo_intersection. Your opinion?

    Hi,
    How would you accomplish the following task? (it’s 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 don’t 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 don’t do an SDO_RELATE in the where clauses of query 2 and 3 but instead I use the id’s 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

  • Bug in function mdsys.sdo_geom.sdo_intersection() ?

    Hi,
    I got a strange result from the spatial subprogram
    SDO_GEOM.SDO_INTERSECTION(
    geom1 IN SDO_GEOMETRY,
    dim1 IN SDO_DIM_ARRAY,
    geom2 IN SDO_GEOMETRY,
    dim2 IN SDO_DIM_ARRAY
    ) RETURN SDO_GEOMETRY;
    I’m calling the function three times, passing each time the same geom1 and geom2 parameters. What changes it the value of the tolerance. Depending on the tolerance, sdo_intersection returns null or a valid geometry
    tol = 0.02 --> the resulting geometry is correct
    tol = 0.01 --> returns null !
    tol = 0.005 --> the resulting geometry is correct
    Please note that the result is null only for a tolerance in the range between 0.005 and 0.02 but not below or above these values.
    I suppose this is a bug in sdo_intersection.
    The exact query is:
    select mdsys.sdo_geom.sdo_intersection(
    (select A1.geoloc AS G1 from A1 where A1.mi_prinx = 390),
    (select m.diminfo AS diminfo_1 from user_sdo_geom_metadata m where m.table_name = 'A1'),
    (select A2.geoloc AS G2 from A2 where A2.mi_prinx = 245),
    (select m.diminfo AS diminfo_2 from user_sdo_geom_metadata m where m.table_name = 'A2')
    from dual;
    The metadata is changed using this query:
    update mdsys.user_sdo_geom_metadata
    set diminfo =
    SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', 650000, 800000, .01),
    SDO_DIM_ELEMENT('Y', 180000, 300000, .01))
    where table_name IN ( 'A1', 'A2');
    Here are the geometries:
    geom1:
    SDO_GEOMETRY(2003, 262148, SDO_POINT_TYPE(758105.191, 245133.936, NULL), SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY(758052.231, 245053.334, 758069.068, 245067.151, 758086.21, 245078.671, 758103.848, 245088.516, 758129.333, 245101.44, 758233.145, 245178.636, 758224.249, 245202.49, 758201.602, 245194.226, 758194.164, 245214.538, 758096.977, 245178.816, 758091.076, 245194.648, 758026.177, 245181.097, 758008.793, 245172.515, 757977.236, 245143.726, 758052.231, 245053.334))
    geom2:
    SDO_GEOMETRY(2003, 262148, SDO_POINT_TYPE(758042.484, 245106.878, NULL), SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY(758129.32, 245101.47, 758233.14, 245178.66, 758224.242, 245202.514, 758211.122, 245237.717, 758166.209, 245208.415, 758091.065, 245194.675, 758026.168, 245181.127, 758008.785, 245172.546, 757977.231, 245143.76, 757932.238, 245109.93, 757895.471, 245068.865, 757851.827, 245034.324, 757941.369, 244976.447, 757951, 244976.04, 757960.491, 244979.747, 757992.773, 244998.626, 758005.407, 245007.133, 758026.492, 245029.014, 758052.22, 245053.37, 758069.056, 245067.186, 758086.197, 245078.704, 758103.835, 245088.548, 758129.32, 245101.47))

    I have tried to replicate your dataset (see below) and then I have execute the same query on the two tables and on metadata table, but the query still runs OK ... !
    a doubt: are you sure that the sdo_ordinates arrays stored in the tables are exactly those you include in the msg?
    Generally, the result of a "select" is truncated at the default decimal digit of sql client.
    You can try to set the NUMF parameter (SET NUMF 999999.999999) and then re-execute the query to obtain a more precise value of ordinates as data input for our test.
    Carl
    SQL> create table tab1 (idGeom varchar2(1), geom mdsys.sdo_geometry);
    Table created.
    SQL> create table tab2 (idGeom varchar2(1), geom mdsys.sdo_geometry);
    Table created.
    SQL> r
    1 insert into tab1 (idGeom,geom)
    2 values
    3 ('1',
    4 MDSYS.SDO_GEOMETRY(2003, 262148,
    5 MDSYS.SDO_POINT_TYPE(758105.191, 245133.936, NULL),
    6 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),
    7 MDSYS.SDO_ORDINATE_ARRAY(758052.231, 245053.334, 758069.068, 245067.151,
    8 758086.21, 245078.671, 758103.848, 245088.516,
    9 758129.333, 245101.44, 758233.145, 245178.636,
    10 758224.249, 245202.49, 758201.602, 245194.226,
    11 758194.164, 245214.538, 758096.977, 245178.816,
    12 758091.076, 245194.648, 758026.177, 245181.097,
    13 758008.793, 245172.515, 757977.236, 245143.726,
    14* 758052.231, 245053.334)))
    1 row created.
    SQL> r
    1 insert into tab2 (idGeom,geom)
    2 values
    3 ('2',
    4 MDSYS.SDO_GEOMETRY(2003, 262148,
    5 MDSYS.SDO_POINT_TYPE(758042.484, 245106.878, NULL),
    6 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),
    7 MDSYS.SDO_ORDINATE_ARRAY(758129.32, 245101.47, 758233.14, 245178.66,
    8 758224.242, 245202.514, 758211.122, 245237.717,
    9 758166.209, 245208.415, 758091.065, 245194.675,
    10 758026.168, 245181.127, 758008.785, 245172.546,
    11 757977.231, 245143.76, 757932.238, 245109.93,
    12 757895.471, 245068.865, 757851.827, 245034.324,
    13 757941.369, 244976.447, 757951, 244976.04,
    14 757960.491, 244979.747, 757992.773, 244998.626,
    15 758005.407, 245007.133, 758026.492, 245029.014,
    16 758052.22, 245053.37, 758069.056, 245067.186,
    17 758086.197, 245078.704, 758103.835, 245088.548,
    18* 758129.32, 245101.47)))
    1 row created.
    SQL> commit;
    Commit complete.
    SQL> r
    1 insert into user_sdo_geom_metadata
    2 (TABLE_NAME,COLUMN_NAME,DIMINFO,SRID)
    3 values
    4 ('TAB1','GEOM',
    5 MDSYS.SDO_DIM_ARRAY(
    6 MDSYS.SDO_DIM_ELEMENT('X', 650000, 800000, .01),
    7 MDSYS.SDO_DIM_ELEMENT('Y', 180000, 300000, .01)),
    8* 262148)
    1 row created.
    SQL> r
    1 insert into user_sdo_geom_metadata
    2 (TABLE_NAME,COLUMN_NAME,DIMINFO,SRID)
    3 values
    4 ('TAB2','GEOM',
    5 MDSYS.SDO_DIM_ARRAY(
    6 MDSYS.SDO_DIM_ELEMENT('X', 650000, 800000, .01),
    7 MDSYS.SDO_DIM_ELEMENT('Y', 180000, 300000, .01)),
    8* 262148)
    1 row created.
    SQL> commit;
    Commit complete.
    SQL> r
    1 select mdsys.sdo_geom.sdo_intersection(
    2 (select geom AS G1 from tab1 where tab1.idGeom = '1'),
    3 (select m.diminfo AS diminfo_1 from user_sdo_geom_metadata m where m.table_name = 'TAB1'),
    4 (select geom AS G2 from tab2 where tab2.idGeom = '2'),
    5 (select m.diminfo AS diminfo_1 from user_sdo_geom_metadata m where m.table_name = 'TAB2')
    6 )
    7* from dual
    MDSYS.SDO_GEOM.SDO_INTERSECTION((SELECTGEOMASG1FROMTAB1WHERETAB1.IDGEOM='1'),(SE
    SDO_GEOMETRY(2003, 262148, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_A
    RRAY(758008,793, 245172,515, 757977,236, 245143,726, 758052,22, 245053,37, 75806
    9,056, 245067,186, 758086,197, 245078,704, 758103,835, 245088,548, 758129,32, 24
    5101,47, 758233,14, 245178,66, 758224,249, 245202,49, 758201,602, 245194,226, 75
    8194,164, 245214,538, 758096,977, 245178,816, 758091,076, 245194,648, 758026,177
    , 245181,097, 758008,793, 245172,515))
    SQL> r
    1 update user_sdo_geom_metadata
    2 set diminfo =
    3 MDSYS.SDO_DIM_ARRAY(
    4 MDSYS.SDO_DIM_ELEMENT('X', 650000, 800000, .02),
    5 MDSYS.SDO_DIM_ELEMENT('Y', 180000, 300000, .02))
    6* where table_name = 'TAB1'
    1 row updated.
    SQL> r
    1 update user_sdo_geom_metadata
    2 set diminfo =
    3 MDSYS.SDO_DIM_ARRAY(
    4 MDSYS.SDO_DIM_ELEMENT('X', 650000, 800000, .02),
    5 MDSYS.SDO_DIM_ELEMENT('Y', 180000, 300000, .02))
    6* where table_name = 'TAB2'
    1 row updated.
    SQL> commit;
    Commit complete.
    SQL> select mdsys.sdo_geom.sdo_intersection(
    2 (select geom AS G1 from tab1 where tab1.idGeom = '1'),
    3 (select m.diminfo AS diminfo_1 from user_sdo_geom_metadata m where m.table_name = 'TAB1'),
    4 (select geom AS G2 from tab2 where tab2.idGeom = '2'),
    5 (select m.diminfo AS diminfo_1 from user_sdo_geom_metadata m where m.table_name = 'TAB2')
    6 )
    7 from dual;
    MDSYS.SDO_GEOM.SDO_INTERSECTION((SELECTGEOMASG1FROMTAB1WHERETAB1.IDGEOM='1'),(SE
    SDO_GEOMETRY(2003, 262148, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_A
    RRAY(758008,793, 245172,515, 757977,236, 245143,726, 758052,22, 245053,37, 75806
    9,056, 245067,186, 758086,197, 245078,704, 758103,835, 245088,548, 758129,32, 24
    5101,47, 758233,14, 245178,66, 758224,249, 245202,49, 758201,602, 245194,226, 75
    8194,164, 245214,538, 758096,977, 245178,816, 758091,076, 245194,648, 758026,177
    , 245181,097, 758008,793, 245172,515))
    SQL> r
    1 update user_sdo_geom_metadata
    2 set diminfo =
    3 MDSYS.SDO_DIM_ARRAY(
    4 MDSYS.SDO_DIM_ELEMENT('X', 650000, 800000, .005),
    5 MDSYS.SDO_DIM_ELEMENT('Y', 180000, 300000, .005))
    6* where table_name = 'TAB1'
    1 row updated.
    SQL> r
    1 update user_sdo_geom_metadata
    2 set diminfo =
    3 MDSYS.SDO_DIM_ARRAY(
    4 MDSYS.SDO_DIM_ELEMENT('X', 650000, 800000, .005),
    5 MDSYS.SDO_DIM_ELEMENT('Y', 180000, 300000, .005))
    6* where table_name = 'TAB2'
    1 row updated.
    SQL> commit;
    Commit complete.
    SQL> select mdsys.sdo_geom.sdo_intersection(
    2 (select geom AS G1 from tab1 where tab1.idGeom = '1'),
    3 (select m.diminfo AS diminfo_1 from user_sdo_geom_metadata m where m.table_name = 'TAB1'),
    4 (select geom AS G2 from tab2 where tab2.idGeom = '2'),
    5 (select m.diminfo AS diminfo_1 from user_sdo_geom_metadata m where m.table_name = 'TAB2')
    6 )
    7 from dual;
    MDSYS.SDO_GEOM.SDO_INTERSECTION((SELECTGEOMASG1FROMTAB1WHERETAB1.IDGEOM='1'),(SE
    SDO_GEOMETRY(2003, 262148, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_A
    RRAY(758008,793, 245172,515, 757977,236, 245143,726, 758052,209, 245053,36, 7580
    52,22, 245053,37, 758069,056, 245067,186, 758086,197, 245078,704, 758103,835, 24
    5088,548, 758129,32, 245101,47, 758233,14, 245178,66, 758224,249, 245202,49, 758
    201,602, 245194,226, 758194,164, 245214,538, 758096,977, 245178,816, 758091,076,
    245194,648, 758026,177, 245181,097, 758008,793, 245172,515))

  • Speeding up of spatial Queries - SDO_Intersection

    HI, I'm running a basic query - calculating the area of spatial intersection sbetween two polygonal datasets:
    select  s.Designation, SUM (
    sdo_geom.sdo_area(
    sdo_geom.sdo_intersection (s.geoloc, m.geoloc, 0.0005),
    *0.0005, 'unit = HECTARE')) total_overlap_area*
    **from SPA_v s, os_bdyline_mlw m*
    where sdo_relate (s.geoloc, m.geoloc, 'mask=overlapbdyintersect') = 'TRUE'
    The problem is that the query is taking a long, long time to run > 8 hours
    First of all the datasets are quite complex, they've been captured at a scale of 1:2500 and 1:10,000 on the Ordnance Survey British National Grid, (the formerbeing of 1mm accuracy, therefore the tolerances involved).
    Spatial Indexes have been created on the Geoloc - (geometry) - column.
    Is there anything I can do to speed this query up (I'm going to have to create this for further datasets) - I've tried reducing the tolerances to 0.5, but hten have problems where I get this error messages:
    ERROR at line 4:
    ORA-13050: unable to construct spatial object
    ORA-06512: at "MDSYS.SDO_3GL", line 715
    ORA-06512: at "MDSYS.SDO_GEOM", line 3016
    ORA-06512: at "MDSYS.SDO_GEOM", line 3065
    Any help gretfully received :-)
    Thanks,
    Bruce

    Hi Ivan, thanks for the response.
    Yep, I've validated all of the geometries.
    There are 21 SPA's in Wales, and am only using the Boundaryline data for Wales - principally because there are far fewer nodes in this dataset than there would be if I had used the Mean Low Water Mark, derived from OS Mastermap (at 1:2500.
    Obviously this is going cause some small errors creeping in where the two datsets do not precisely meet, but this would probably be within the acceptable range. The other thing I could do would be to thin the SPA dataset so that it would be at 0.05 tolerance (OS 1:10,000 has a node separation of 10 cm)
    Thanks,
    Bruce

  • Running SDO_INTERSECTION with a Polygon with a hole

    Hello,
    I'm running into some issues when using SDO_INTERSECTION between two spatial tables. In my parcel table, I have polygons that will have a hole in them. When using SDO_INTERSECTION between the parcels and our land use layer to get area figures, I run into the Oracle error, "Unable to construct spatial object". I tracked it down to those parcels with holes that are causing the problem.
    Does anyone know how to avoid this problem or make SDO_INTERSECTION work for those polygons with holes? Thanks in advance.
    Juan Butler
    [email protected]

    I've looked at this some more and I don't think it's so much an issue with polygons with holes, but something with the way these two polygons are interacting.
    Here is the query that I'm using to test the validity of the resulting intersection.
    SELECT sdo_geom.validate_geometry_with_context(sdo_geom.sdo_intersection(b.GEOMETRY, a.geometry, .01),.01)
    FROM SP_PARCELBASE a, SP_FUTURE_LANDUSE b
    WHERE sdo_relate(b.geometry,a.geometry,'mask=ANYINTERACT') = 'TRUE'
    AND a.gid = 53887816
    Here are the geometries of the problem polygons...
    - FROM SP_PARCELBASE
    (2003, 82000, , (1, 1003, 1, 75, 2003, 1, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ), (252134.399999992, 1300154.70000085, 252218.899999986, 1299775.00000085, 252223.899999986, 1299769.00000084, 252382.099999989, 1299577.70000084, 252397.499999992, 1299571.20000085, 252473.599999991, 1299538.90000084, 252537.699999992, 1299511.80000084, 252626.999999992, 1299426.10000084, 252749.299999991, 1299308.70000085, 252751.799999986, 1299306.20000085, 252799.599999992, 1299230.90000084, 252885.699999993, 1299212.80000084, 252951.699999992, 1299159.70000084, 253031.69999999, 1299158.20000085, 253033.299999991, 1299317.70000084, 253033.299999991, 1299320.80000085, 253034.399999993, 1299427.20000084, 253036.49999999, 1299606.20000085, 253036.499999987, 1299608.20000084, 253243.49999999, 1299604.80000085, 253350.299999993, 1299602.90000085, 253375.299999991, 1299602.50000085, 253629.799999993, 1299598.00000085, 253630.19999999, 1299730.80000084, 253363.699999992, 1299735.60000084, 253366.299999994, 1300103.30000084, 253366.499999986, 1300127.70000085, 253553.699999991, 1300124.70000085, 253553.699999991, 1300128.60000085, 253553.699999992, 1300131.30000084, 253554.199999993, 1300233.50000084, 252393.899999991, 1300252.50000085, 252393.999999992, 1300267.70000085, 252394.199999993, 1300284.10000084, 252341.099999992, 1300225.90000084, 252288.599999986, 1300168.50000084, 252134.399999992, 1300154.70000085, 252987.099999988, 1299658.60000085, 252987.799999992, 1299766.80000085, 253193.49999999, 1299765.20000085, 253193.099999992, 1299716.30000085, 253195.699999988, 1299716.30000085, 253198.999999991, 1299715.60000085, 253201.699999991, 1299714.10000085, 253204.29999999, 1299712.10000085, 253205.999999992, 1299709.30000084, 253207.199999991, 1299706.30000085, 253207.599999993, 1299703.30000085, 253207.599999986, 1299699.70000084, 253207.499999992, 1299685.90000084))
    - FROM SP_FUTURE_LANDUSE
    (2003, 82000, , (1, 1003, 1, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ), (253631, 1300130, 253631.7, 1300247.4, 253554, 1300248.5, 253554.2, 1300233.5, 252393.9, 1300252.5, 252391.7, 1300150, 252134.4, 1300154.7, 252218.9, 1299775, 252223.9, 1299769, 252228.4, 1299778.4, 252266.6, 1299791.9, 252273.6, 1299778.6, 252290.4, 1299768.6, 252306.4, 1299759, 252328.9, 1299736.1, 252359.8, 1299699.7, 252366.8, 1299706.3, 252367.9, 1299694.5, 252364.9, 1299688.1, 252374.7, 1299665.7, 252393.6, 1299638.8, 252402, 1299626.8, 252453.5, 1299621.3, 252476.1, 1299606.3, 252535.9, 1299596.2, 252558.5, 1299620.8, 252598.5, 1299624.4, 252654.3, 1299626.3, 252701.3, 1299630.2, 252717.7, 1299632.2, 252723.6, 1299641.1, 252733.1, 1299642.3, 252749.6, 1299652.9, 252755, 1299644, 252760.9, 1299631.9, 252775.4, 1299638.8, 252790.4, 1299636.3, 252805.9, 1299613.6, 252813.7, 1299566.8, 252815.9, 1299554, 252817.2, 1299515.8, 252726.2, 1299501, 252707.1, 1299503.5, 252680.4, 1299504.1, 252656.6, 1299510.6, 252612.3, 1299513.9, 252565.3, 1299516.7, 252541.4, 1299521.2, 252509.6, 1299540.1, 252479.8, 1299542.1))

  • SDO_INTERSECTION error: ORA-21779

    Hi.
    I have encountered a problem with sdo_intersection in Oracle 9.2 that somebody may be able to help me with:
    I am trying to intersect two polygons (one is a rectangle that I have created by specifying co-ordinates, the other is a selection from a larger table of polygons). If I specify a tolerance of 0.005 for this function then the relationship between the two is determined to be 'TOUCH', which is incorrect, and the result is a line. If I specify a smaller tolerance (eg 0.0005), then the relationship is determined to be 'OVERLAPBYINTERSECT' but the intersection function results in the error: ORA-21779: duration not active.
    Below is an extract from my work - the last line is the one where the error occurs:
    overlap_region := MDSYS.SDO_GEOMETRY(2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1), MDSYS.SDO_ORDINATE_ARRAY(min_x_wc, min_y_wc, max_x_sw, min_y_wc, max_x_sw, max_y_sw, min_x_wc, max_y_sw, min_x_wc, min_y_wc));
    Select GEOLOC into big_wc from base_list_local where name = 'Southwest';
    temp := mdsys.sdo_geom.relate(big_wc, 'DETERMINE', overlap_region, 0.000005);
    dbms_output.put_line(temp);
    small_wc := MDSYS.SDO_GEOM.SDO_INTERSECTION(overlap_region, big_wc, 0.000005);

    Version 9.2.0.1.0
    If this is a bug then does anybody have an idea for a work-around (ie. another way to acheive an intersection, without using the sdo_intersection function)?

  • Getting point ordinates using sdo_intersection

    I have two crossing lines. I try to get point of crossing using spatial function SDO_INTERSECTION. I got it, but ordinates was null.
    I don't know why.
    geom_edge1 := MDSYS.SDO_GEOMETRY(2002,NULL,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),MDSYS.SDO_ORDINATE_ARRAY(-654713,-1021390,-767748,-1011681));
    geom_edge2 := MDSYS.SDO_GEOMETRY(2002,NULL,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),MDSYS.SDO_ORDINATE_ARRAY(-727527,-983943,-730301,-1083802));
    select MDSYS.SDO_GEOM.SDO_INTERSECTION(geom_edge1, geom_edge2, 0.005) into geom_intersection from dual;
    X := geom_intersection.SDO_POINT.X;
    Y := geom_intersection.SDO_POINT.Y;
    I have oracle version 9.2.0.6.
    Thank you for replay.

    I already found solution - for geometry of intersection I must ask for SDO_ORDINATES, not SDO_POINT.

  • Sdo_intersection across the antimeridian

    Hello All,
    I'm trying to create a function which splits geometries at the antimeridian, producing multipart geometries.  I'm approaching this using a sdo_intersection and a clipping geometry representing each of the hemispheres.  I'm confused about the behavior of sdo_geom.sdo_intersection though.  Why does the following not produce a box like 'POLYGON((-179.9 0, -170 0, -170 10, -179.9 10, -179.9 0))'
    Thanks!
    --john
      1  select sdo_util.to_wktgeometry(sdo_geom.sdo_intersection(
      2 MDSYS.SDO_GEOMETRY('POLYGON((170 0, -170 0, -170 10, 170 10, 170 0))', 8307),
      3 MDSYS.SDO_GEOMETRY(2003,8307,NULL, sdo_elem_info_array (1,1003,1), sdo_ordinate_array (-179.9, 89.9, -179.9, -89.9, -0.1, -89.9, -0.1, 89.9, -179.9, 89.9)),
      4 0.05
      5 )
      6* ) from dual

    Hi John,
    It would be helpful to mention the version of Oracle you are using.  But in any case the answer has less to do with the date line than with the size of your geodetic polygons. 
    Here is the link for 11g with this caveat
    http://docs.oracle.com/cd/B28359_01/appdev.111/b28400/sdo_cs_concepts.htm#SPATL624
    The 12g blurb actually expands on things a bit
    http://docs.oracle.com/cd/E16655_01/appdev.121/e17896/sdo_cs_concepts.htm#SPATL624
    It's always nice to see the documentation getting a little better.
    So you could break your polygons down into smaller pieces but I guess I wonder what you are up to with these globe spanning boxes.  Perhaps if you explained your use case other folks on the list could chime in with some suggestions.
    Cheers,
    Paul

  • SDO_INTERSECTION & tolerance (obviously size does matter)

    In my layers overlay mechanizem I perform a lot of SDO_INTERSECTION. In some cases it returns completly wrong results which is somehow related to tolerance used . I understand that tolerance is used for internal computing in Oracle Spatial, but I think that such difference as in following example is pure Oracle bug.
    In this example, polygons overlay on very, very small area - almost 0 m2. When intresect using tolerance of 0.0000000005 I get intersection of area of 6303,39484405518 m2 (wrong), when using tolerance of 0.00000000005 I get 0 m2 (ok). Between 1.5 milion polygons to be overlayed, there is about 30 such cases, but there is no obvious pattern, regarding number of decimal places of point and tolerance.
    What do you think, is this bug in Oracle or should I use tolerance on differant way? I have also crashes, described in SDO_AGGR_UNION crashes the session but with combination of tolerances I have now, I avoid crashes.
    I have Oracle Database 10g Enterprise Edition Release 10.1.0.4.0.
    select
    SDO_GEOM.SDO_AREA(
    SDO_GEOM.SDO_INTERSECTION(
    MDSYS.SDO_GEOMETRY(2003, NULL, NULL,SDO_ELEM_INFO_ARRAY(1,1003,1),
    SDO_ORDINATE_ARRAY(
    575637.792      ,157828.133
    ,575639.3      ,157824.61
    ,575639.03      ,157823.14
    ,575637.84      ,157816.31
    ,575631.06      ,157798.98
    ,575618.21      ,157779.68
    ,575621.34397071 , 157773.943053618
    ,575621.71      ,157775.59
    ,575630.346      ,157788.42
    ,575634.54      ,157799.77
    ,575637.254      ,157810.873
    ,575641.695      ,157820.002
    ,575637.786906933,157828.14490562
    ,575637.792      ,157828.133
    MDSYS.SDO_GEOMETRY(2003, NULL, NULL,SDO_ELEM_INFO_ARRAY(1,1003,1),
    SDO_ORDINATE_ARRAY(
    575703.4 ,157604.1
    ,575716 ,157639.6
    ,575743.998 ,157709.215
    ,575727.483 ,157718.717
    ,575717.303 ,157722.789
    ,575701.014 ,157727.54
    ,575669.568 ,157739.53
    ,575658.934 ,157747.222
    ,575653.052 ,157754.462
    ,575662.328 ,157773.013
    ,575674.318 ,157796.994
    ,575680.111 ,157797.607
    ,575676.21 ,157810.367
    ,575674 ,157817.6
    ,575660.494 ,157826.142
    ,575655.5 ,157829.3
    ,575652.3 ,157825.6
    ,575636.673 ,157837.372
    ,575635.774 ,157832.339
    ,575641.695 ,157820.002
    ,575637.254 ,157810.873
    ,575634.54 ,157799.77
    ,575630.346 ,157788.42
    ,575621.71 ,157775.59
    ,575618.749 ,157762.267
    ,575620.23 ,157755.852
    ,575626.398 ,157750.424
    ,575642.929 ,157739.321
    ,575657.486 ,157731.672
    ,575666.626 ,157726.182
    ,575679.069 ,157723.015
    ,575691.285 ,157717.133
    ,575696.717 ,157715.635
    ,575707.079 ,157707.492
    ,575703.15 ,157701.103
    ,575714.974 ,157692.935
    ,575711.767 ,157682.819
    ,575705.352 ,157664.561
    ,575693 ,157642.3
    ,575700.5 ,157640.3
    ,575703.7 ,157628.1
    ,575701 ,157607.9
    ,575703.4 ,157604.1
    , 0.0000000005 ) --tolerance for sdo_intersection
    , 0.000000000005) --tolerance for sdo_area
    area
    from dual
    Can you be so kind and check this on other versions/platforms.
    Regards,
    Saso

    It looks like you are hitting a bug (4707623) as described in the Metalink Note 4707623.8. Your best bet would be to login to Metalink and look up this bug/note in order to ascertain the best way to mitigate this problem.
    I hope this helps.
    -Justin

  • Sdo_intersection problem

    Hi to all,
    I have an other problem with sdo_intersection. I have to intersect a polygon and a multilinestring, which is inside the polygon. The multilinestring is an aggregation of five connected linestring.
    The intersection is NULL instead of the multilinestring itself.
    But if I try to intersect the same two aggregates I obtain the multilinestring, that is correct!
    Any idea?
    Thanks for your help!
    Anna

    Hi to all,
    I have an other problem with sdo_intersection. I have to intersect a polygon and a multilinestring, which is inside the polygon. The multilinestring is an aggregation of five connected linestring.
    The intersection is NULL instead of the multilinestring itself.
    But if I try to intersect the same two aggregates I obtain the multilinestring, that is correct!
    Any idea?
    Thanks for your help!
    Anna

  • Sdo_intersection is slow

    I am struggling with the performance of sdo_intersection. Should I expect sdo_intersection operating on 2 polygons, one with 2 vertices (rectangle) and one with 40,000 vertices, to take 11 seconds to 2 hours? That seems awfully long on a Core 2 Duo 2.4 GHz, but I have no knowlege of the algorithm it is using. I have to perform over 100,000 of these operations so I am a bit concerned. Are there any tricks to speed it up?
    I have reimplemented my app to use Java2D to perform the intersections outside the database and then insert the result back into the database. What used to take 12+ hours, now takes 90 min. Why is sdo_intersection so slow?

    You poor soul, who is inflicting these point clusters on you anyway?  They should buy you lunch.
    So yeah, switch getnumelem to getnumvertices in the loop counter, and then you'll need to manually extract each x,y into a temporary normal, simple point geometry within the loop.
    Here's a revised bit of sample PL/SQL.
    declare
      multip sdo_geometry := sdo_geometry (2005, null, null, sdo_elem_info_array (1,1,3),
                                          sdo_ordinate_array (50,5, 55,7, 60,5));
      singlep sdo_geometry;
      poly sdo_geometry := SDO_GEOMETRY (2003,
                      NULL,
                      NULL,
                      SDO_ELEM_INFO_ARRAY (1, 1003, 1),
                      SDO_ORDINATE_ARRAY (-100,-100,100,-100,100,100,-100,100,-100,-100));
      kount pls_integer := 0;
    begin
      for i in 1 .. sdo_util.getnumvertices(multip)
      loop
          singlep := SDO_GEOMETRY
                      (  2001,  multip.sdo_srid,    SDO_POINT_TYPE
                            multip.sdo_ordinates(i * 2 - 1),
                            multip.sdo_ordinates(i * 2),
                            NULL
                        ),  NULL,  NULL);
          --debuggin tip - use determine mask                
          --dbms_output.put_line(sdo_geom.relate(singlep, 'mask=DETERMINE', poly, .05));
          if sdo_geom.relate(singlep, 'mask=INSIDE', poly, .05) <> 'FALSE'
          then
            kount := kount + 1;
          end if;
      end loop;
      dbms_output.put_line(kount);
    end;

  • Error with SDO_INTERSECTION

    While executing this in a PL/SQL procedure:
    SELECT SUBSTR(A.MTR || A.SECTION_,1,12) MTRS, ROUND(SDO_GEOM.SDO_AREA(SDO_GEOM.SDO_INTERSECTION (A.GEOM, :B1, 0.00000005),0.00000005, 'unit=ACRE'),3) ACRE FROM GIS.PLS_SECTION A WHERE SDO_RELATE(A.GEOM, :B1, 'mask=ANYINTERACT querytype=WINDOW') = 'TRUE' AND SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(:B1, 0.00000005) = 'TRUE'
    I get this error:
    A database error has occurred
    ORA-06553 PLS-306
    wrong number or types of arguments in call to 'SDO_INTERSECTION'
    Not all of the records generate this error, but I don't know which records cause the error. We are using Oracle 9.2.0.5 on a Sun Solaris box.

    Hi Richard,
    This looks strange. The error doesn't look to be spatial related, but perhaps we can check on that.
    I checked just to be sure and spatial will return a null if the first, the second, or both the first and second arguments to sdo_intersection are null (no error is returned) - sql doesn't mind if null arguments are passed. I'm not sure if this is different in the context of a pl/sql procedure.
    Since this is executing in the context of a pl/sql procedure is it possible to break this up into two statements, fetching based on the where clause, and then doing the operations in the select? In between, insert the two geometries/values we are about to intersect into a table so we can look at them to try to understand what is happening.
    That said, nothing jumps out as problematic in the statement.
    Thanks,
    Dan

  • Something wrong with sdo_geom.sdo_intersection function

    I have two geometries. Both of them are valid in all tolerances, I tested.
    The relation between geometries is OVERLAPBDYINTERSECT.
    I run the sdo_geom.sdo_intersection with parameters - both of geometries and as result there is geometry which relation with second geom is again OVERLAPBDYINTERSECT.
    IMHO, the relation MUST be COVEREDBY.
    The error occurs rarely, but this is a real problem.
    The OS is Windows 2003 Enterprise Edition x64, sp1.
    Oracle version - Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64
    The result is same on OS is Windows 2003 Enterprise Edition x32, sp1.
    Oracle version - Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
    There are the test cases:
    declare
    -- Local variables here
    v_intersected_geom1 sdo_geometry;
    v_first_geom1 sdo_geometry :=sdo_geometry('POLYGON ((456705.802734375 4706456.71875, 456815.033203125 4706511.4609375, 456784.951171875 4706569.671875, 456766.470703125 4706605.4296875, 456652.1015625 4706543.96875, 456664.111328125 4706523.5390625, 456679.171875 4706497.9140625, 456694.052734375 4706474.890625, 456705.802734375 4706456.71875))');
    v_second_geom1 sdo_geometry := sdo_geometry('POLYGON ((456245.65625 4706998.046875, 456273.796875 4706951.828125, 456298.703125 4706912.40625, 456341.09375 4706834.34375, 456362.28125 4706798.6875, 456447.515625 4706735.1953125, 456499.71875 4706698.34375, 456536.25 4706675.9375, 456603.0625 4706627.390625, 456679.171875 4706497.9140625, 456720.734375 4706433.609375, 456802.703125 4706363.203125, 456872.8125 4706316.46875, 456872.812411145 4706316.46870013, 456874.3125 4706315.46875, 456938.609375 4706269.6796875, 456979.03125 4706252.6328125, 457040.90625 4706235.09375, 457094.96875 4706224.3828125, 457175.828125 4706210.25, 457187.515625 4706210.328125, 457084.203125 4706414.15625, 457020.484375 4706546.875, 456914.671875 4706736.953125, 456815.09375 4706934.890625, 456773.9375 4707020.15625, 456665.5625 4707219.046875, 456550.65625 4707437.0625, 456544.78125 4707434.0078125, 456517.625 4707412.953125, 456501.4375 4707406.296875, 456484.046875 4707396.734375, 456471.0625 4707386.125, 456443.921875 4707368.21875, 456449.84375 4707359.015625, 456461.6875 4707337.078125, 456467.15625 4707323.265625, 456466.28125 4707310.328125, 456462.125 4707284.234375, 456456.203125 4707259.234375, 456454.4375 4707242.796875, 456461.6875 4707231.609375, 456457.875 4707224.953125, 456450.9375 4707221.5234375, 456444.734375 4707222.5625, 456397.875 4707194.328125, 456380.109375 4707179.640625, 456363.875 4707170.4296875, 456349.84375 4707184.90625, 456334.0625 4707202.4453125, 456309.109375 4707228.8125, 456294.265625 4707214.484375, 456295.96875 4707210.046875, 456372.375 4707063.109375, 456245.65625 4706998.046875))');
    v_res1 varchar2(100);
    v_intersected_geom2 sdo_geometry;
    v_first_geom2 sdo_geometry :=sdo_geometry('POLYGON ((437834.87109375 4685964.8984375, 437757.328125 4686011.734375, 437395.171875 4686241.375, 437293.296875 4686183.328125, 437276.984375 4686175.171875, 437228.65625 4686153.8359375, 437209.84375 4686150.6953125, 437185.984375 4686143.1640625, 437160.890625 4686117.4375, 437109.484375 4686029.53125, 437109.70703125 4686027.5234375, 437698.0 4685671.2109375, 437757.140625 4685785.015625, 437776.4375 4685842.4609375, 437786.1875 4685872.2109375, 437834.5 4685964.46875, 437834.87109375 4685964.8984375))');
    v_second_geom2 sdo_geometry := sdo_geometry('POLYGON ((437089.34375 4685943.6328125, 437090.40625 4685924.5390625, 437114.5625 4685850.9453125, 437144.734375 4685794.375, 437163.5 4685769.078125, 437191.796875 4685695.484375, 437246.953125 4685609.578125, 437325.4375 4685520.484375, 437391.1875 4685468.5234375, 437446.34375 4685437.765625, 437482.390625 4685414.4296875, 437516.34375 4685400.640625, 437539.671875 4685425.0390625, 437583.15625 4685510.9453125, 437601.96875 4685549.609375, 437623.0625 4685579.1328125, 437658.828125 4685614.28125, 437698.984375 4685672.640625, 437757.140625 4685785.015625, 437776.4375 4685842.4609375, 437786.1875 4685872.2109375, 437830.093807139 4685956.05466017, 437830.09375 4685956.0546875, 437834.5 4685964.46875, 437856.499141809 4685990.32412997, 437860.41015625 4685994.921875, 437861.64453125 4685996.375, 437878.890625 4686016.640625, 437951.319879907 4686091.80320543, 438008.546875 4686163.515625, 438035.4375 4686207.25, 438079.984375 4686266.640625, 438118.171875 4686320.734375, 438112.94140625 4686396.953125, 438112.859375 4686398.15625, 438177.5625 4686386.4921875, 438199.0625 4686563.15625, 438229.359375 4686675.2421875, 438283.875 4686799.4375, 438329.328125 4686914.5546875, 438425.640625 4687159.15625, 438568.5 4687514.921875, 438362.046875 4687576.421875, 438350.75 4687573.9140625, 438335.6875 4687563.875, 438314.34375 4687545.046875, 438280.46875 4687507.3984375, 438254.109375 4687465.9765625, 438198.3125 4687361.84375, 438106.046875 4687199.5859375, 437995.75 4686991.71875, 437942.015625 4686865.4921875, 437899.265625 4686742.78125, 437860.671875 4686658.6875, 437798.625 4686552.5234375, 437781.375 4686534.390625, 437758.203125 4686509.765625, 437727.796875 4686490.9375, 437680.96875 4686473.078125, 437628.84375 4686441.21875, 437572.84375 4686401.15625, 437528.09375 4686360.328125, 437487.84375 4686309.46875, 437469.015625 4686287.5, 437434.5 4686259.265625, 437401.234375 4686244.828125, 437293.296875 4686183.328125, 437276.984375 4686175.171875, 437228.65625 4686153.8359375, 437209.84375 4686150.6953125, 437185.984375 4686143.1640625, 437160.890625 4686117.4375, 437109.484375 4686029.53125, 437111.609375 4686010.4453125, 437112.671875 4685977.5703125, 437089.34375 4685943.6328125))');
    v_res2 varchar2(100);
    v_intersected_geom3 sdo_geometry;
    v_first_geom3 sdo_geometry :=sdo_geometry('POLYGON ((380746.4921875 4812010.8125, 380745.453125 4812010.15625, 380731.046875 4812004.390625, 380704.3125 4811969.015625, 380689.5 4811938.984375, 380627.7890625 4811828.3125, 380619.5625 4811772.765625, 380601.453125 4811679.375, 380519.171875 4811598.328125, 380481.734375 4811553.078125, 380473.5078125 4811521.40625, 380461.1640625 4811493.015625, 380435.25 4811459.28125, 380426.1953125 4811409.90625, 380419.203125 4811386.453125, 380422.4921875 4811337.90625, 380423.3125 4811268.796875, 380406.859375 4811214.90625, 380366.5390625 4811191.859375, 380341.859375 4811169.640625, 380333.6328125 4811146.203125, 380334.0390625 4811119.046875, 380339.7890625 4811100.3125, 380343.40625 4811074.109375, 380022.5390625 4811146.40625, 380007.171875 4811158.15625, 379984.578125 4811168.109375, 379971.015625 4811162.6875, 379931.25 4811037.046875, 379930.34375 4811010.828125, 380144.5625 4810962.03125, 380344.3125 4810909.609375, 380361.9609375 4810934.65625, 380403.734375 4810919.796875, 380518.9296875 4810889.40625, 380606.59375 4810862.1875, 380659.4375 4811048.90625, 380775.8984375 4811011.5625, 380790.453125 4811012.203125, 380800.5859375 4811016.0, 380834.7578125 4811122.328125, 380929.703125 4811091.3125, 380942.359375 4811098.90625, 380988.875 4811137.203125, 381023.6875 4811181.1875, 381069.890625 4811264.421875, 381079.0703125 4811292.265625, 381113.25 4811357.140625, 381139.828125 4811404.296875, 381146.796875 4811437.203125, 381153.4375 4811521.703125, 381158.1875 4811581.828125, 381153.125 4811632.15625, 381144.890625 4811661.265625, 381144.265625 4811717.59375, 381157.31640625 4811765.1875, 380746.4921875 4812010.8125))');
    v_second_geom3 sdo_geometry := sdo_geometry('POLYGON ((379931.25 4811037.046875, 379930.34375 4811010.828125, 380144.5625 4810962.03125, 380344.3125 4810909.609375, 380361.9609375 4810934.65625, 380403.734375 4810919.796875, 380518.9296875 4810889.40625, 380606.59375 4810862.1875, 380659.4375 4811048.90625, 380775.8984375 4811011.5625, 380790.453125 4811012.203125, 380800.5859375 4811016.0, 380834.7578125 4811122.328125, 380929.703125 4811091.3125, 380942.359375 4811098.90625, 380988.875 4811137.203125, 381023.6875 4811181.1875, 381069.890625 4811264.421875, 381079.0703125 4811292.265625, 381113.25 4811357.140625, 381139.828125 4811404.296875, 381146.796875 4811437.203125, 381153.4375 4811521.703125, 381158.1875 4811581.828125, 381153.125 4811632.15625, 381144.890625 4811661.265625, 381144.265625 4811717.59375, 381160.40625 4811776.453125, 381167.046875 4811810.3125, 381195.84375 4811893.859375, 381206.921875 4811928.046875, 381213.5703125 4811962.21875, 381221.4765625 4811988.484375, 381230.65625 4812014.75, 381260.40625 4812093.234375, 381268.8828125 4812145.390625, 381257.1328125 4812260.546875, 381194.859375 4812326.34375, 381033.953125 4812243.65625, 381033.950224401 4812243.65968153, 380986.234375 4812219.140625, 380816.3046875 4812090.78125, 380762.9765625 4812021.1875, 380745.453125 4812010.15625, 380731.046875 4812004.390625, 380704.3125 4811969.015625, 380689.5 4811938.984375, 380627.7890625 4811828.3125, 380619.5625 4811772.765625, 380601.453125 4811679.375, 380519.171875 4811598.328125, 380481.734375 4811553.078125, 380473.5078125 4811521.40625, 380461.1640625 4811493.015625, 380451.585874521 4811480.54694375, 380451.5859375 4811480.546875, 380435.25 4811459.28125, 380426.1953125 4811409.90625, 380419.203125 4811386.453125, 380422.4921875 4811337.90625, 380423.3125 4811268.796875, 380406.859375 4811214.90625, 380366.5390625 4811191.859375, 380341.859375 4811169.640625, 380333.6328125 4811146.203125, 380334.0390625 4811119.046875, 380339.7890625 4811100.3125, 380343.40625 4811074.109375, 380183.125 4811110.21875, 380183.118081404 4811110.22504572, 380022.5390625 4811146.40625, 380007.171875 4811158.15625, 379984.578125 4811168.109375, 379971.015625 4811162.6875, 379931.25 4811037.046875))');
    v_res3 varchar2(100);
    begin
    -- Test statements here
    dbms_output.put_line(' Test case 1');
    dbms_output.put_line(' -----------');
    dbms_output.put_line( 'validate v_first_geom1 - ' || sdo_geom.validate_geometry_with_context(v_first_geom1,0.00005));
    dbms_output.put_line( 'validate v_second_geom1 - ' ||sdo_geom.validate_geometry_with_context(v_second_geom1,0.00005));
    v_res1 := sdo_geom.relate(v_first_geom1,'DETERMINE', v_second_geom1, 0.00005);
    dbms_output.put_line('determine between v_first_geom1 and v_second_geom1 is ' ||v_res1);
    v_intersected_geom1 := sdo_geom.sdo_intersection(v_first_geom1, v_second_geom1, 0.00005);
    -- dbms_output.put_line('intersection geometry - '||sdo_util.to_wktgeometry(v_intersected_geom1));
    dbms_output.put_line( 'validate v_intersected_geom1 -' || sdo_geom.validate_geometry_with_context(v_intersected_geom1,0.00005));
    v_res1 := sdo_geom.relate(v_intersected_geom1,'DETERMINE', v_second_geom1, 0.00005);
    dbms_output.put_line('determine between v_intersected_geom1 and v_second_geom1 is ' ||v_res1);
    dbms_output.put_line(' ');
    dbms_output.put_line(' Test case 2');
    dbms_output.put_line(' -----------');
    dbms_output.put_line( 'validate v_first_geom2 - ' || sdo_geom.validate_geometry_with_context(v_first_geom2,0.00005));
    dbms_output.put_line( 'validate v_second_geom2 - ' ||sdo_geom.validate_geometry_with_context(v_second_geom2,0.00005));
    v_res2 := sdo_geom.relate(v_first_geom2,'DETERMINE', v_second_geom2, 0.00005);
    dbms_output.put_line('determine between v_first_geom2 and v_second_geom2 is ' ||v_res2);
    v_intersected_geom2 := sdo_geom.sdo_intersection(v_first_geom2, v_second_geom2, 0.00005);
    -- dbms_output.put_line('intersection geometry - '||sdo_util.to_wktgeometry(v_intersected_geom2));
    dbms_output.put_line( 'validate v_intersected_geom2 -' || sdo_geom.validate_geometry_with_context(v_intersected_geom2,0.00005));
    v_res2 := sdo_geom.relate(v_intersected_geom2,'DETERMINE', v_second_geom2, 0.00005);
    dbms_output.put_line('determine between v_intersected_geom2 and v_second_geom2 is ' ||v_res2);
    dbms_output.put_line(' ');
    dbms_output.put_line(' Test case 3');
    dbms_output.put_line(' -----------');
    dbms_output.put_line( 'v_first_geom3 - ' || sdo_geom.validate_geometry_with_context(v_first_geom3,0.00005));
    dbms_output.put_line( 'v_second_geom3 - ' ||sdo_geom.validate_geometry_with_context(v_second_geom3,0.00005));
    v_res3 := sdo_geom.relate(v_first_geom3,'DETERMINE', v_second_geom3, 0.00005);
    dbms_output.put_line('determine between v_first_geom3 and v_second_geom3 is ' ||v_res3);
    v_intersected_geom3 := sdo_geom.sdo_intersection(v_first_geom3, v_second_geom3, 0.00005);
    -- dbms_output.put_line('intersection geometry - '||sdo_util.to_wktgeometry(v_intersected_geom3));
    dbms_output.put_line( 'v_intersected_geom3 -' || sdo_geom.validate_geometry_with_context(v_intersected_geom3,0.00005));
    v_res3 := sdo_geom.relate(v_intersected_geom3,'DETERMINE', v_second_geom3, 0.00005);
    dbms_output.put_line('determine between v_intersected_geom3 and v_second_geom3 is ' ||v_res3);
    dbms_output.put_line(' ');
    end;
    The result is:
    Test case 1
    validate v_first_geom1 - TRUE
    validate v_second_geom1 - TRUE
    determine between v_first_geom1 and v_second_geom1 is OVERLAPBDYINTERSECT
    validate v_intersected_geom1 -TRUE
    determine between v_intersected_geom1 and v_second_geom1 is OVERLAPBDYINTERSECT
    Test case 2
    validate v_first_geom2 - TRUE
    validate v_second_geom2 - TRUE
    determine between v_first_geom2 and v_second_geom2 is OVERLAPBDYINTERSECT
    validate v_intersected_geom2 -TRUE
    determine between v_intersected_geom2 and v_second_geom2 is OVERLAPBDYINTERSECT
    Test case 3
    v_first_geom3 - TRUE
    v_second_geom3 - TRUE
    determine between v_first_geom3 and v_second_geom3 is OVERLAPBDYINTERSECT
    v_intersected_geom3 -TRUE
    determine between v_intersected_geom3 and v_second_geom3 is OVERLAPBDYINTERSECT
    Any ideas?
    Message was edited by:
    petiozaf

    Hi,
    This is definitely a precision issue and due to the numerical stability problem
    very slight differences in coordinates is resulting in OVERLAPBDYINTERSECT
    instead of COVERS.
    Since you have many digits after the decimal in the input data, the tolerance you are
    specifying may not work for all pairs of geometries.
    For example, lets say you have vertices from geometry A as a1, ... aN and vertices
    from B as b1 ... bN.
    When each geometry is validated at a given tolerance there is no problem.
    But when you put two geometries together, the tolerance you specify many be
    valid for the combination of those two.
    For example, when these two geometries share an edge, the vertices might not
    align exactly.
    So you will have line segments which are made up of vertices from both geometries
    like: a1 b3 a2 b4 ...
    In such cases, the distance between a1 and b3 might be less than the tolerance you
    specified so we have to internally adjust the tolerance.
    As a result, the intersection might have been computed at a lesser tolerance than the
    one you specified (i.e. 0.00005 could be changed to 0.000005).
    So when you try to do RELATE again with 0.00005, the result is slightly off due
    to the tolerance difference.
    The best option in this case is to look for some slightly relaxed constraint than to check
    for the exact COVEREDBY/COVERS relationship with the intersection geometry.
    There are other factors such as lost precision (very minor) due to conversion from floating point double to oracle NUMBER and vice versa which may change a COVERS
    to OVERLAPBDYINTERSECT since you have many digits after decimal
    in the input data.
    siva

Maybe you are looking for