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

Similar Messages

  • 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

  • Haversine formula vs. MDSYS.SDO_GEOM.SDO_DISTANCE

    We need to calculate the distance between 2 lat/longs (from GPS unit).
    What is more accurate, the use of MDSYS.SDO_GEOM.SDO_DISTANCE or a hand coded Haversine Formula?
    Thanks,
    JB

    Well, easiest thing to do is to conduct a test.
    I looked at this website: http://www.movable-type.co.uk/scripts/latlong-vincenty.html
    The answer to the default functional demo is 969954.114 meters.
    Testing with SDO_DISTANCE we get (I converted the DMS values to DD):
    select sdo_geom.sdo_distance(
              sdo_geometry(2001,8307,sdo_point_type(-5.71475,      50.0663222222,null),null,null),
              sdo_geometry(2001,8307,sdo_point_type(-3.07009444444,58.6440222222,null),null,null),
              0.05) as dist
      from dual;
    -- Result
    969954.113110585Which is pretty similar!!
    So, don't bother coding your own Haversine (you would have to add extra parameters to pass in the ellisodal params for non-WGS84 SRIDs...), use what comes out of the box.
    Does that answer you question? If so, please award points.
    regards
    Simon

  • ISSUS IN MDSYS.SDO_GEOM.SDO_DISTANCE()

    Hi experts,
    SQL> SELECT * FROM LOC_ZIP;
    COMP ZIPCD
    LOC(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    c1 z1
    SDO_GEOMETRY(2001, NULL, SDO_POINT_TYPE(100, 1, NULL), NULL, NULL)
    c1 z2
    SDO_GEOMETRY(2001, NULL, SDO_POINT_TYPE(200, 2, NULL), NULL, NULL)
    SQL> SELECT * FROM SUPP_ZIP;
    COMP SUPPI
    LOC(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    c1 s1
    SDO_GEOMETRY(2001, NULL, SDO_POINT_TYPE(5, 1, NULL), NULL, NULL)
    c1 s2
    SDO_GEOMETRY(2001, NULL, SDO_POINT_TYPE(77, 7, NULL), NULL, NULL)
    SQL> SELECT MDSYS.SDO_GEOM.SDO_DISTANCE(L.LOC,S.LOC,NULL)
    FROM Loc_zip L,Supp_zip S
    WHERE L.compcd = S.compcd;
    SELECT MDSYS.SDO_GEOM.SDO_DISTANCE(L.LOC,S.LOC,NULL)
    ERROR at line 1:
    ORA-22060: argument [2] is an invalid or uninitialized number
    ORA-06512: at "MDSYS.SDO_3GL", line 817
    ORA-06512: at "MDSYS.SDO_GEOM", line 3224
    ORA-06512: at "MDSYS.SDO_GEOM", line 3238
    Many Thanks,
    Kalinga

    You might try specifying a positive tolerance value (as the third argument to SDO_GEOM.SDO_DISTANCE), as in something like:
    SELECT
        MDSYS.SDO_GEOM.SDO_DISTANCE(L.LOC, S.LOC, 0.5)
    FROM
        Loc_zip L,
        Supp_zip S
    WHERE
        L.compcd = S.compcd;Hope this helps.

  • I'd use Safari's bug report function instead of posting here, but...

    ...it crashes Safari. lol.
    So here are my reports:
    - If Google is set as the default search engine, setting the home page to www.google.com crashes the program.
    - Bookmarks... seems like this topic has been covered well enough. I actually had no problems importing them from Firefox, but adding new ones crashes the program.
    - And as mentioned, the bug report function crashes the program.
    Bugs aside, I love it. Looking forward to future releases.
    Homegrown PC, P4 1.8GHz.   Windows XP Pro  

    ...it crashes Safari. lol.
    Haha! It's so Windows-alike!

  • OWB bugs, missing functionality and the future of OWB

    I'm working with OWB for some time now and there are a lot of rough edges to discover. Functionality and stability leave a lot to be desired. Here's a small and incomplete list of things that annoy me:
    Some annoying OWB bugs (OWB 10g 10.1.0.2.0):
    - The debugger doesn't display the output parameters of procedures called in pre-mapping processes (displays nothing, treats values as NULL). The mapping itself works fine though.
    - When calling selfmade functions within an expression OWB precedes the function call with a constant "Functions." which prevents the function from being executed and results in an error message
    - Occasionally OWB cannot open mappings and displays an error message (null pointer exception). In this case the mapping cannot be opened anymore.
    - Occasionally when executing mappings OWB doesn't remember changes in mappings even when the changes were committed and deployed
    - When using aggregators in mappings OWB scrambles the order of the output attributes
    - The deployment of mappings sometimes doesn't work. After n retries it works without having changed anything in the mapping
    - When recreating an external table directly after dropping the table OWB recreates the external table but always displays both an error message and a success message.
    - In Key Lookups the screen always gets garbled when selecting an attribute as a join condition
    - Usage of constants results in aborts in the debugger
    - When you reconcile a table used in a key lookup the lookup condition sometimes changes. OWB seems to remember only the position of the lookup condition attribute but not the name.
    - In the process of validating a mapping often changes in the mapping get lost and errors occur like 'Internal Errors' or 'Null Pointer Exceptions'.
    - When you save the definition of external tables OWB always adds 2 whitespace columns to the beginning of all the lines following 'ORGANISATION EXTERNAL'. If you save a lot of external table definitions you get files with hundreds of leading whitespaces.
    Poor or missing functionality:
    - No logging on the level of single records possible. I'd like the possibility to see the status of each single record in each operator like using 'verbose data' in PowerCenter
    - The order of the attributes cannot be changed. This really pisses me off expecially if operators like the aggregator scramble the order of attributes.
    - No variables in expressions possible
    - Almost unusable lookup functionality (no cascading lookups, no lookup overrides, no unconnected lookups, only equal condition in key lookups)
    - No SQL overrides in soruces possible
    - No mapplets, shared containers or any kind a reusable transformations
    - No overview functionality for mappings. Often it's very hard to find a leftover operator in a big mapping.
    - No copy function for attributes
    - Printing functionality is completely useless
    - No documentation functionality for mappings (reports)
    - Debugger itself needs debugging
    - It's very difficult to mark connections between attributes of different operations. It's almost impossible to mark a group of connections without marking connections you don't want to mark.
    I really wonder which of the above bugs and mssing functionality 'Paris' will address. From what I read about 'Paris' not many if at all. If Oracle really wants to be a competitor (with regard to functionality) to Informatica, IBM/Ascential etc. they have a whole lot of work to do or purchase Informatica or another of the leading etl tool
    vendors.
    What do you think about OWB? Will it be a competitor for the leading etl tools or just a cheap database add on and become widely used like SAB BW not for reasons of technology or functionality but because it's cheap?
    Looking forward to your opinions.
    Jörg Menker

    Thanks to you two for entertaining my thoughts so far. Let me respond to you latest comments.
    Okay, lets not argue which one is better.. when a tool is there .. then there are some reasons to be there...But the points raised by Jorg and me are really very annoying. Overall I agree with both yours and Jorg's points (and I did not think it was an argument...merely sharing our observations with each other (;^)
    The OWB tool is not as mature as Informatica. However, Informatica has no foothold in the database engine itself and as I mentioned earlier, is still "on the outside looking in..." The efficiency and power of set-based activity versus row-based activity is substantial.
    Looking at it from another way lets take a look at Microstrategy as a way of observing a technical strategy for product development. Microstrategy focused on the internals (the engine) and developed it into the "heavy-lifting" tool in the industry. It did this primarily by leveraging the power of the backend...the database and the hosting server. For sheer brute force, it was champion of the day. It was less concerned with the pretty presentation and more concerned with getting the data out of the back-end so the user didn't have to sit there for a day and wait. Now they have begun to focus on the presentation part.
    Likewise this seems to be the strategy that Oracle has used for OWB. It is designed around the database engine and leverages the power of the database to do its work. Informatica (probably because it needs to be all things to all people) has tended to view the technical offerings of the database engine as a secondary consideration in its architectural approach and has probably been forced to do so more now that Oracle has put themselves in direct competition with Informatica. To do otherwise would make their product too complex to maintain and more vendor-specific.
    I am into the third data warehousing/data migration project and my previous two have been on Informatica (3 years on it).I respect your experience and your opinions...you are not a first timer. The tasks we have both had to solve and how we solved them with these tools are not necessarily the same. Could be similar in instances; could be quite different.
    So the general tendency is to evaluate the tool and try to see how things that were needed to be done in my previous projects can be done with this tool. I am afraid to say .. I am still not sure how these can be implemented in OWB. The points raised by us are probably the fall out of this deficiency.One observation that I would make is that in my experience, calls to the procedural language in the database engine have tended to perform very poorly with Informatica. Informatica's scripting language is week. Therefore, if you do not have direct usability of a good, strong procedural language to tackle some complicated tasks, then you will be in a pickle when the solution is not well suited to a relational-based approach. Informatica wants you to do most things outside of the database (in the map primarily). It is how you implement the transformation logic. OWB is built entirely around the relational, procedural, and ETL components in the Oracle database engine. That is what the tool is all about.
    If cost is the major factor for deciding a tool then OWB stands far ahead...Depends entirely on the client and the situation. I have implemented solutions for large companies and small companies. I don't use a table saw to cut cake and I don't use a pin knife to fall trees. Right tool for the right job.
    ...thats what most managers do .. without even looking how in turn by selecting such a tool they make the life tough for the developers.Been there many times. Few non-technical managers understand the process of tool evaluation and selection and the value a good process adds to the project. Nor do they understand the implications of making a bad choice (cost, productivity, maintainability).
    The functionality of OWB stands way below Informatica.If you are primarily a GUI-based implementer that is true. However, I have often found that when I have been brought in to fix performance problems with Informatica implementations that the primary problem is usually with the way that the developer implemented it. Too often I have found that the developer understands how to implement logic in the GUI component (the Designer/Maps and Sessions) with a complete lack of understanding of how all this activity will impact load performance (they don't understand how the database engine works.) For example, a strong feature in Informatica is the ability to override the default SQL statement generated by Informatica. This was a smart design decision on Informatica's part. I have frequently had to go into the "code" and fix bad joins, split up complex operations, and rip out convoluted logic to get the maps to perform within a reasonable load window. Too often these developers are only viewing the problem through the "window" of the tool. They are not stepping back and look at the problem in the context of the overall architecture. In part Informatica forces them to do this. Another possible factor is they probably don't know better.
    "One tool...one solution"
    Microstrategy until recently had been suffering from that same condition of not allowing the developer to create the actual query). OWB engineers need to rethink their strategy on overriding the SQL.
    The functionality of OWB stands way below Informatica.In some ways yes. If you do a head-to-head comparison of the GUI then yes. In other ways OWB is better (Informatica does not measure up when you compare it with all of the architectural features that the Oracle database engine offers). They need to fix the bugs and annoyances though.
    .. but even the GUI of Informatica is better than OWB and gives the developer some satisfaction of working in it.Believe me I feel your pain. On the other hand, I have suffered from Informatica bugs. Ever do a port from one database eingine to another just to have it convert everything into multi-byte? Ever have it re-define your maps to parallel processing threads when you didn't ask it to?
    Looking at the technical side of things I can give you one fine example ... there is no function in Oracle doing to_integer (to_number is there) but Informatica does that ... Hmm-m-m...sorry, I don't get the point.
    The style of ETL approach of Informatica is far more appealing.I find it unnecessarily over-engineered.
    OWB has two advantages : It is basically free of cost and it has a big brother in Oracle.
    It is basically free of cost...When you are another "Microsoft", you can throw your weight around. The message for Informatica is "don't bite the hand that feeds you." Bad decisions at the top.
    Regards,
    Dan Phillips

  • How to realize the function like SDO_GEOM.SDO_BUFFER in Spatial Operators?

    Dear all,
    I wanted to use SDO_GEOM.SDO_BUFFER function to generate a
    buffer polygon around a geometry object while it is pretty slow
    to perform for a large spatial database. I think it better
    to use Spatial Operators for it takes advantage of spatial index.
    But within operators, there are no availble function. Can anyone
    tell me how to do it with Spatial Operators?
    Thanks a lot,
    Fan

    Fabio,
    Error 13349 indicates that the polygons intersect with themselves.
    You need to fix these errors. There are tools in MapInfo Professional 7.5 to check and automatically fix them. There are other tools commercially available which also fix geometry errors.
    If you know MapInfo I would fix these errors there.
    Ivan

  • New version (2014.1) bug : stop() function won't work

    Hi everyone,
    I would like to know if someone else had this issue.
    I've set a symbol that has an animation into another symbol that is put in the Stage. ( Stage -> symbol_father -> Symbol_with_animation) .
    I want to make this animation start only when i press a button into the Symbol_father.
    The issue is, as soon as I run the Stage,  my animation will start regardeless i've insert every type of "stop()" function ( for example : sym.stopAll() into the stage, or sym.stop(0) into the start function of the symbol_with_animation, and so on...)
    Thanks for your time,
    greetings.

    There is no such bug AFAIK.
    I have created a composition @ Dropbox - NestedSymbols.rar as you described, and everything seems to be working fine.
         Preview in the browser and click the green box.
    Let me know if it helps, else share your composition  so that we can test.
    hth,
    Vivekuma

  • Lightroom 5 Final, Big bug with Function "Light Dim"

    Hello,
    Found this bug in many Pcs (With Win 7) in x64 Bits AND x32
    When i use the option "Lights Dim" (in Menu "Lights Out") when i quit Lightroom 5, lr 5 Crashes after the ending.
    Receive windows message "Lightroom 5 Has Chrashing ...etc..."
    I search to understand, and i think have know.
    Before the V5, no crash (V4.4. for exemple), and with this versions,  "Lights Dim" function is intergrate into "lightroom.exe"
    With the Lr5 Version ONLY  "Lights Dim" is extrenal ans is used by "Slideshow.Dll"
    For verify this, very easy, just move  "Slideshow.Dll" in you desktop, and you see the  "Lights Dim" not run.
    After always testing, you see also the Option "Light Off" runs always good, and "Light On" same.
    This in one little piece of this 3 function is external, it's very dirty, and crashes.
    Pse (developpers) note this bug and in 5.1, integrate this 3 functions into Lightroom5.Exe
    Best regards, and sorry for my very bad English

    I am having the same issue and wondered what was the issue. Thank you for posting; now I remember Lightroom didn't start doing this until I updated to Mac OS Maverick. The only time I don't have that problem is when I physically disconnect my secondary display from my computer.

  • [BUG] max() function in Flash

    Hi,
    I found a little problem with the built in min() and max() functions with pixel bender in flash.
    pixel4 sample = sampleNearest(src,outCoord());
    float causeBug = max(sample.r, sample.b);
    dst = sample;
    Basically, with the above code I would expect the output image to be the same as the input image as sample is never modified. The pixel bender toolkit does exactly this. However, in Flash (10.1) the value of the first parameter in the function is modified and the image changes (in this example blues turn purple).
    The workaround is to assign off the first parameter to it's own variable before calling the function.
    pixel4 sample = sampleNearest(src,outCoord());
    float workaround = sample.r;
    float causeBug = max(workaround, sample.b );
    dst = sample;
    The above code produces the same result in both flash and toolkit.
    src files: http://deja-visite.com/pixelbender_bug.zip
    Cheers,
    Jareth

    This is fixed in version 2.0 of the Pixel Bender toolkit which will be up soon at the Pixel Bender Developer Network (http://www.adobe.com/devnet/pixelbender/).
    The Pixel Bender 2.0 toolkit is also installed with CS5 AE or Flash Pro or any suite that includes either of those applications.
    Bob

  • Bug with function "resume 0x****"  of jdb

    One problem with the function of jdb occured when I tried to use it to
    pilot the processor with differents threads. In fact, I use a simple example with 2 threads.
    I stop the two threads with two breakpoint, and I want to resume one or the other (with the function "resume 0x****"), the one wich I resumed stop again on the breackpoint and I decide again to resume one or the other. All of that to obtain a tree of execution.
    I give you the code of the class and the code of jdb.
    CLASS: (it's just a object Room with a variable degre that I increment and decrement with two threads increase and decrease)
    public class Test{
          public static void main(String[] args){
               Room r = new Room();
               decrease de = new decrease(r);
               increase in = new increase(r);
               de.start();
               in.start();
    class Room {
         private volatile int degre=20;
         public void more(){
            degre += 4;
         public void less(){      
           degre -= 3;     
    class decrease extends Thread{
       private Room room;
       public decrease(Room r){
                 room =r;
       public void run(){
        try{ 
         while (!interrupted()){ 
                    room.less();  
          catch(InterruptedException e) {}
    class increase extends Thread{
       private Room room;
       public increase(Room r){
            room =r;
       public void run(){ 
            try{ 
                 while (!interrupted()){
                      room.more();
           catch(InterruptedException e) {}
    JDB:
    Initializing jdb ...
    stop at Test:7Deferring breakpoint Test:7.
    It will be set after the class is loaded.
    runrun Test
    Set uncaught java.lang.Throwable
    Set deferred uncaught java.lang.Throwable
    >
    VM Started: Set deferred breakpoint Test:7
    Breakpoint hit: "thread=main", Test.main(), line=7 bci=30
    7 in.start();
    main[1] stop at room:16
    Set breakpoint room:16
    main[1] stop at room:20
    Set breakpoint room:20
    main[1] resume
    All threads resumed.
    >
    Breakpoint hit: "thread=Thread-0", room.less(), line=20 bci=0
    20 degre -= 3;
    Thread-0[1] threads
    Group system:
    (java.lang.ref.Reference$ReferenceHandler)0x10d Reference Handler cond. waiting
    (java.lang.ref.Finalizer$FinalizerThread)0x10c Finalizer cond. waiting
    (java.lang.Thread)0x10b Signal Dispatcher running
    Group main:
    (decrease)0x146 Thread-0 running (at breakpoint)
    (increase)0x147 Thread-1 running (at breakpoint)
    (java.lang.Thread)0x148 DestroyJavaVM running
    Thread-0[1] resume 0x147
    Thread-0[1]
    Breakpoint hit: "thread=Thread-1", room.more(), line=16 bci=0
    16 degre += 4;
    Thread-1[1] resume 0x147
    Thread-1[1]
    Breakpoint hit: "thread=Thread-1", room.more(), line=16 bci=0
    16 degre += 4;
    Thread-1[1] print degre
    degre = 24
    Thread-1[1] resume 0x146 //It's here the problem, thread 0x146 have to stop on the //next breakpoint of decrease but nothing happen
    Thread-1[1] resume 0x147
    Thread-1[1]
    Breakpoint hit: "thread=Thread-1", room.more(), line=16 bci=0
    16 degre += 4;
    Thread-1[1] clear
    Breakpoints set:
    breakpoint Test:7
    breakpoint room:16
    breakpoint room:20
    PS: I tried many other examples with other class and other kind of breakpoints, but, in any cases, on thread doesn't manage to resume. When I try with general resume (no specification of the thread), It works but it isn't interresting for me because I want to decide wich thread continue his execution.

    Looks like a memory clearing problem in the function. Best to post this problem in an OSS message, or look through the OSS notes to see if the problem has been identified before.
    Michael.

  • SQL Developer Bug: NVL() function error when debug/run stored procedure

    Version:
    SQL Developer: 1.5.3 (build main-5783)
    Oracle DB connected: Oracle9i Enterprise Edition Release 9.2.0.6.0
    Stored procedure code like this:
    procedure search(V_STATUS_IN IN CHAR(1)) is
    begin
    declare
    V_STATUS CHAR(1) := NULL;
    begin
    V_STATUS := NVL(V_STATUS_IN, '%'); -- error line
    end;
    end;
    The stored procedure runs well (I mean no oracle exception) when called through Java code (and in TOAD). But when debug/run in SQL Developer, following error at the error line:
    $Oracle.EXCEPTION_ORA_6502:
    ORA-06502: PL/SQL: numeric or value error: character string buffer too small
    --------------------------------------------------*/

    What parameter are you passing in? It is possible you are trying to cram a multibyte character into a singlebyte container. What are the nls settings for the database and for sqldeveloper?

  • 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 area and error message

    Hi
    I wonder if anybody can offer any help/advice
    I have been running a routine which loops through a spatial Layer A and for each polyon in the loop I pick up those polygons from a more detailed Layer B (over 5 million records) that interact then create a non spatial table output showing the area of intersection between the 2 layers.
    This is used in the query to return the area of intersection:
    ROUND(mdsys.sdo_geom.sdo_area(                              mdsys.sdo_geom.sdo_intersection(a.geom, b.'||l_spCol||', 0.0005),1,''unit=HECTARE'' ), 3)
    The SDO_DIMINFO for both layers (UK, national grid) is:
    ((X, 0, 700000, 5E-10), (Y, 0, 1300000, 5E-10), , )
    I have been running this successfully for a while now. However the 3rd party that supply layer B have done some major updates and I now have some errors when running the routine i.e. some of the polygons now cause errors.
    The error I get is:
    ORA-13347: the coordinates defining an arc are not distinct
    It is a bit of a needle in a hay stack trying to find the ‘error’ polys and have found 3 so far. The way I have found the Layer B errors is by changing the tolerance in the above area calculation to 0.1 (in the polgon where Layer A fails), the query will run with the lower tolerance and a NULL record is returned for the error polys. I have taken these out of Spatial and loaded into ESRI, after geometry checks ESRI describes the error as “self intersections”. Once cleaned and reloaded the routine works ok. I did find some examples of these self intersections that are not causing a problem.
    One thing that confused me was I got no error reported using this:
    SELECT c.LAYERA_ID, SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(c.geom, 0.005)
    FROM LAYER B c
    I noticed the MDSYS.SDO_ELEM_INFO_ARRAY(1,1005…, was 1005 for the error polys rather than 1003, not sure about the significance of this!
    I wondered whether there was a ‘better’ way of identifying the polygons upsetting the area calculation (and why VALIDATE_GEOMETRY_WITH_CONTEXT wasn’t picking these up).
    And
    How much accuracy would I lose in downgrading the tolerance of the area calculation to 0.1. Comparing results for 0.1 and 0.0005 they seem to be only different at 3 decimal places.
    Thanks for any help/comments (I am fairly inexperienced on Oracle Spatial)….

    Thanks again for the posts.
    I have run my 5+million polygons through the has_arc procedure (thanks for that!) and this returned x4 polygons (3 of which I had identified as breaking my procedure). The additional one didn’t seem to be causing any problems – and ESRI didn’t find any geometry errors.
    So I am inclined to think this issue has come about by the (recent) addition of these polygons with the ‘Circular Arcs’ to layer b (by a third party).
    Moving forward when ever I get a cut of the latest version of the data (Layer b). I will run the has_arc function to see if any new polygons have gone into the layer – as it is likely these could be a problem. I have managed to now run the procedure with the addition of the x3 cleaned polygons. So hopefully when I start to re run the procedure on different Layer A's I will be ok i.e. Layer B wont break it (fingers crossed).
    In summary to the problem I encountered:
    I get Layer B from a third party (imported from their database), all in UK nat grid (metres) (81989). The SDO_DIMINFO setting coming from the source. It is based on detailed large scale mapping.
    The procedure breaks on the x3 polygons when returning the area (SQL in original post) of intersection using 0.0005, I can by-pass the error using 0.1 and get a null intersection area returned.
    I can get a spatial layer intersection output using the problem data.
    I am still a bit confused as to what a circular arc actual means in terms of geometry (I haven’t done any digitising type work for a bout 15 years and my old topology type knowledge seems to have left me…) Once I understand it – I would like to raise it with the 3rd to ascertain why they are there. The polygons ‘look’ very simple!
    And does anybody have any recommended reading re tolerances. The only GIS I have used in the last few years has been desktop GIS – where I haven’t really had to worry about setting appropriate tolerances. The stuff I have read on Oracle’s site has left me a bit puzzled.
    Cheers

Maybe you are looking for