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
Similar Messages
-
Performance problem with sdo_intersection. Your opinion?
Hi,
How would you accomplish the following task? (its not as complicated at it looks, please read on and feel challenged)
I got two tables A and B both having a geom column and other attributes.
Consider a row a1 in Table A having an attribute Name and a polygon in its geom-column, In table B I have a row b1, having an attribute Zone and also a polygon in its geom column. The two polygons a1.geom and b1.geom partially intersect.
What I need is a table with the following columns:
IDLayer1, IDLayer2, Name, Zone, geom
The rows must look something like this:
Row 1 (the part of a1.geom also covered by b1.geom)
a1, b1, myName, myZone, SDO_GEOMETRY .
Row 2 (the part of a1.geom not covered by b1.geom):
a1, null, myName, null, SDO_GEOMETRY
Row 3 ( the part of b1.geom not covered by a1)
Null, b1, null, myZone, SDO_GEOMETRY)
How I solved this problem:
By calling a series of three SELECT statements I create Row1, 2 and 3 and fill in the result table.
Row 1 is created as:
INSERT INTO
SELECT /* ORDERED +/ A.id, B.id, A.Name, B.Zone, SDO_GEOM.SDO_INTERSECTION(A.geom, B.geom, 0.001)
FROM A, B
WHERE SDO_RELATE (a.geom, b.geom, 'mask=anyinteract') = 'TRUE'
Row 2 is created as:
SELECT /* ORDERED +/ A.id, null, A.Name, null, SDO_GEOM.SDO_DIFFERENCE(A.geom, B.geom, 0.001)
FROM A, B
WHERE SDO_RELATE (a.geom, b.geom, 'mask=anyinteract') = 'TRUE'
Row 3 is created as:
SELECT /* ORDERED +/ null, B.id, null, B.Zone, SDO_GEOM.SDO_DIFFERENCE(B.geom, A.geom, 0.001)
FROM A, B
WHERE SDO_RELATE (a.geom, b.geom, 'mask=anyinteract') = 'TRUE'
Note: The queries above are simplified and dont expose all details. The important point is, I do first an intersection, followed by two differences. I improved the performance, by reusing the result from the intersection query in the difference-queries. That is: I actually dont do an SDO_RELATE in the where clauses of query 2 and 3 but instead I use the ids from the Intersection query (If there is an intersection, there must also be a difference).
A second simplification in the queries given above concerns the Difference operation when a geometry a1 from Layer A intersects with several geometries from Layer B (say b1 and b2). In this case I first call an Aggregate function:
SDO_AGGR_UNION ( mdsys.sdoaggrtype(B.geom, 0.01))
WHERE B.id someConditionResulting in b1 and b2
The difference operation then looks something like this:
SDO_GEOM.SDO_DIFFERENCE(A.geom, aggregatedGeometry, 0.001)
Now the Problem:
My Tables are quiet large containing thousands of geometries. Using the approach described above, it takes hours to compute the result. When doing the same task in a Desktop GIS (like Mapinfo), a single intersect operation is needed and the result is obtained within a few seconds.
Question:
How would you tackle the problem? May I improve the performance just by tuning the queries or is my approach wrong? What are your suggestions?
Thank you!
MarcoYou 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 -
A problem about SDO_AGGR_UNION
I have a problem with the SDO_AGGR_UNION function.
In the first step, I calculate the areas of the intersection between each polygon in dataset aus_veg_test A and the polygon 8 in dataset LAND_USE_DSE_TEST B. As the result shown below, some of the polygons in dataset A do intersect with polygon 8 in dataset B, such as 12, 13, 14, etc.
In step 2, all the polygons in dataset A are aggregated into a single polygon 100 by SDO_AGGR_UNION function.
In step 3, the area of the intersection between 100 (in table TEST_100) and 8 (dataset B) is calculated. But the result is 0.
It seems to be a contradiction. Do you have some ideas about this? Thank you!
-- STEP 1;
SQL> SELECT a.gid, b.gid, SDO_GEOM.SDO_AREA(SDO_GEOM.SDO_INTERSECTION(a.geometry, b.geometry, 0.000000005), 0.000000005) AREA
2 FROM aus_veg_test a, LAND_USE_DSE_TEST b
3 WHERE B.GID = 8;
GID GID AREA
1 8
2 8
3 8
4 8
5 8
6 8
7 8
8 8
9 8
10 8
11 8
GID GID AREA
12 8 2.1580E-07
13 8 8.2592E-07
14 8 .00012801
15 8
16 8
17 8
18 8
19 8
20 8 .000042058
21 8
22 8
GID GID AREA
23 8
24 8
25 8
26 8
27 8
28 8
29 8
30 8
31 8
32 8
33 8 .000027234
GID GID AREA
34 8 0
34 rows selected.
-- STEP 2;
SQL> CREATE TABLE TEST_100 AS
2 SELECT 100 GRIDCODE, SDO_AGGR_UNION(MDSYS.SDOAGGRTYPE(GEOMETRY,0.0000005)) GEOMETRY
3 FROM (SELECT 100 GRIDCODE, GEOMETRY FROM aus_veg_test) GROUP BY GRIDCODE;
Table created.
-- STEP 3;
SQL> SELECT A.GRIDCODE, B.GID, SDO_GEOM.SDO_AREA(SDO_GEOM.SDO_INTERSECTION(A.geometry, B.geometry, 0.000000005), 0.000000005) AREA
2 FROM TEST_100 A, LAND_USE_DSE_TEST B
3 WHERE B.GID = 8;
GRIDCODE GID AREA
100 8 0I have the same problem with sdo_aggr_concat_line function
create table uma_1(id number, geom mdsys.sdo_geometry);
alter table uma_1 parallel;
insert into uma_1
values (1,SDO_GEOMETRY(2002,null,null,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(50,0,60,0)));
insert into uma_1
values
(2,SDO_GEOMETRY(2002,null,null,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(20,0,30,0)));
commit;
SELECT SDO_AGGR_CONCAT_LINES(a.geom) FROM uma_1 a;
:Returns no value or Oracle Error
ORA-29400: data cartridge error
ORA-00600: internal error code, arguments: [kohfrm771], [], [], [], [], [], [],[]
alter table uma_1 noparallel;
:Returns valid Line
I wondering if you answer or replay on your problem? -
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,
AshishHi All,
The problem has been resolved by transforming the user defined polygon coordinates into the database specific coordinate system.
Thanks -
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,
BruceHi 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 -
Hi all,
I use this simple query:
CREATE TABLE INTER2 AS
SELECT SDO_GEOM.SDO_INTERSECTION(G1.SHAPE, G2.SHAPE, 0.005) SHAPE
FROM RAIL G1, ROADS G2;
to find the intersections between these two layers. The first layer (rail) contains 47 lines and the second one (roads) 78 lines.
The new table that is constructed by running this query has 3666 rows (I think that this is because 78x47=3666) but when I visualize the layer in the spatial in the spatial index advisor I can see that only 40 points (intersections) exists.
So, I suppose that this query checks every possible pair from the two layers and creates a row which either has a point (intersection) in the shape column or has null value in this column.
My problem is that this layer cannot be inserted into ARCINFO (throught ARCSDE) because of its structure (every row must have a shape - geometry).
Can anyone tell me how can I perform this query and have as a result ONLY the rows with the points (intersections of the two layers)so I can visualize it in ARCINFO?
Thanks in advanceHello John:
Seems like you are missing something from your query. I think it would help eliminate those records that do not return a SHAPE by using SDO_RELATE in your where clause. The query would look something like this:
CREATE TABLE INTER2 AS
SELECT SDO_GEOM.SDO_INTERSECTION(G1.SHAPE, G2.SHAPE, 0.005) SHAPE
FROM RAIL G1, ROADS G2
WHERE
MDSYS.SDO_RELATE(G1.SHAPE, G2.SHAPE, 'mask=ANYINTERACT querytype=WINDOW') = 'TRUE';
BUT - you may have to "trick" ArcSDE into recognizing the table (or should I say "feature class"). You may have to use an ArcSDE command to create the feature class, then go into SQL and drop the table. This has the effect of putting the correct metadata into the SDE schema tables, such as LAYERS and SPATIAL_REFERENCES. When you drop the table using SQL, the metadata will remain.
Then, use the CREATE TABLE... to create and populate the "feature class". Be sure to create a spatial index - we have found that you do not have to use the same name for the index as the one created by ArcSDE when you did the ArcSDE command to create the "feature class".
This trickery is necesarry because ArcSDE really prefers that EVERYTHING is created and populated via ArcSDE commands or ArcCatalog, but there are ways to "fool" the ESRI software.
Let me know if this helps.
R Clement
Alaska DNR -
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. -
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)? -
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,
SasoIt 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 -
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:
petiozafHi,
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 -
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 -
Internal error for SDO_INTERSECTION
Hi guys,
I wrote a procedure to create intsection line between a polyline table and a polygon table. The SQL statement is like this:
<code>
CREATE TABLE intersect_line_polygon AS
(SELECT B.polygon_id, A.line_id, SDO_GEOM.SDO_INTERSECTION(A.GEOM, B.GEOM, 0.005) AS INTERSECT_LINE
FROM LINE_INVENTORY A, POLYGON_INVENTORY B
WHERE SDO_RELATE(A.GEOM, B.GEOM, 'MASK=ANYINTERACT QUERYTYPE=WINDOW') = 'TRUE' AND A.TYPE IN ('1', '2'));
</code>
The oracle server turned to be very slow and returned the following error.
ORA-13050: unable to construct spatial object
Then I increased the tolerance to 0.5 to make the performance better. The server was still very slow, but returned a different error.
ORA-00600: internal error code, arguments: [kohdtf048], [], [], [], [], [], [],[]
ORA-06512: at "MDSYS.SDO_3GL", line 439
ORA-06512: at "MDSYS.SDO_GEOM", line 3145
ORA-06512: at "MDSYS.SDO_GEOM", line 3194
I don't know what the problem is. I guess there should be some other factors other than tolerance that caused these two errors. I can't increase the tolerance higher further. Can anyone give me a clue how to solve this problem? Thank you!
ChenI've seen the same error in an intersection operation. One of the geometries was invalid. In my case, it was compounded by the fact that the geometry validation routine did NOT detect the fact that the geometry was invalid. There were duplicate vertices that were not detected when the tolerance was 1 meter, but were detected when the tolerance was 100 meters. Strange thing was that the duplicate vertices WERE within 1 meter of each other. Oracle has opened a bug on the issue.
- David -
I am trying to implement some kind of a server listening for requests. The listener part of the app, is a daemon thread that listens for connections and instantiates a handling daemon thread once it gets some. However, my problem is that i must be able to kill the listening thread at the user's will (say via a sto button). I have done this via the Sun's proposed way, by testing a boolean flag in the loop, which is set to false when i wish to kill the thread. The problem with this thing is the following...
Once the thread starts excecuting, it will test the flag, find it true and enter the loop. At some point it will LOCK on the server socket waiting for connection. Unless some client actually connects, it will keep on listening indefinatelly whithought ever bothering to check for the flag again (no matter how many times you set the damn thing to false).
My question is this: Is there any real, non-theoretical, applied way to stop thread in java safely?
Thank you in advance,
LeftyThis was one solution from the socket programming forum, have you tried this??
public Thread MyThread extends Thread{
boolean active = true;
public void run(){
ss.setSoTimeout(90);
while (active){
try{
serverSocket = ss.accept();
catch (SocketTimeoutException ste){
// do nothing
// interrupt thread
public void deactivate(){
active = false;
// you gotta sleep for a time longer than the
// accept() timeout to make sure that timeout is finished.
try{
sleep(91);
}catch (InterruptedException ie){
interrupt();
} -
A problem with Threads and MMapi
I am tring to execute a class based on Game canvas.
The problem begin when I try to Play both a MIDI tone and to run an infinit Thread loop.
The MIDI tone "Stammers".
How to over come the problem?
Thanks in advance
Kobi
See Code example below:
import java.io.IOException;
import java.io.InputStream;
import javax.microedition.lcdui.Graphics;
import javax.microedition.lcdui.Image;
import javax.microedition.lcdui.game.GameCanvas;
import javax.microedition.media.Manager;
import javax.microedition.media.MediaException;
import javax.microedition.media.Player;
public class MainScreenCanvas extends GameCanvas implements Runnable {
private MainMIDlet parent;
private boolean mTrucking = false;
Image imgBackgound = null;
int imgBackgoundX = 0, imgBackgoundY = 0;
Player player;
public MainScreenCanvas(MainMIDlet parent)
super(true);
this.parent = parent;
try
imgBackgound = Image.createImage("/images/area03_bkg0.png");
imgBackgoundX = this.getWidth() - imgBackgound.getWidth();
imgBackgoundY = this.getHeight() - imgBackgound.getHeight();
catch(Exception e)
System.out.println(e.getMessage());
* starts thread
public void start()
mTrucking = true;
Thread t = new Thread(this);
t.start();
* stops thread
public void stop()
mTrucking = false;
public void play()
try
InputStream is = getClass().getResourceAsStream("/sounds/scale.mid");
player = Manager.createPlayer(is, "audio/midi");
player.setLoopCount(-1);
player.prefetch();
player.start();
catch(Exception e)
System.out.println(e.getMessage());
public void run()
Graphics g = getGraphics();
play();
while (true)
tick();
input();
render(g);
* responsible for object movements
private void tick()
* response to key input
private void input()
int keyStates = getKeyStates();
if ((keyStates & LEFT_PRESSED) != 0)
imgBackgoundX++;
if (imgBackgoundX > 0)
imgBackgoundX = 0;
if ((keyStates & RIGHT_PRESSED) != 0)
imgBackgoundX--;
if (imgBackgoundX < this.getWidth() - imgBackgound.getWidth())
imgBackgoundX = this.getWidth() - imgBackgound.getWidth();
* Responsible for the drawing
* @param g
private void render(Graphics g)
g.drawImage(imgBackgound, imgBackgoundX, imgBackgoundY, Graphics.TOP | Graphics.LEFT);
this.flushGraphics();
}You can also try to provide a greater Priority to your player thread so that it gains the CPU time when ever it needs it and don't harm the playback.
However a loop in a Thread and that to an infinite loop is one kind of very bad programming, 'cuz the loop eats up most of your CPU time which in turn adds up more delays of the execution of other tasks (just as in your case it is the playback). By witting codes bit efficiently and planning out the architectural execution flow of the app before start writing the code helps solve these kind of issues.
You can go through [this simple tutorial|http://oreilly.com/catalog/expjava/excerpt/index.html] about Basics of Java and Threads to know more about threads.
Regds,
SD
N.B. And yes there are more articles and tutorials available but much of them targets the Java SE / EE, but if you want to read them here is [another great one straight from SUN|http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html] .
Edited by: find_suvro@SDN on 7 Nov, 2008 12:00 PM
Maybe you are looking for
-
Cannot load 3.6 - disk image failed to mount - reason: corrupt image
Tried to load 3.6 and get the msg: disk image failed to mount. Reason: corrupt image. == This happened == Every time Firefox opened
-
I have clicked on hide inside bookmarks button then bookmarks button in the toolbar disappeared , How can I get it back ?
-
Can't sync after ios 6.1 upgrade
Since I upgraded to iOS 6.1, everytime I connect my iPhone 4S to my PC I cannot sync with itunes. Itunes recognises the phone, but in the iPhone's screen in itunes the whole capacity bar at the bottom changed to "other" (yellow, see Printscreen. same
-
Prelude Metadata panel of the Ingest dialog not available
Hi, the File Metadata panel of the Ingest dialog is not available (Prelude CS6 Mac) as mentioned in all Prelude tutorials or Help files. I can ingest, transfer or transcode with no problem, but cannot add metadata on Ingest (or add a preset) Any help
-
Albums not available for browsing in iphoto 6
I have just noticed that I cannot browse for pictures in iphoto 6 like I used to be able to in iphoto 4. What I mean is, if I was writing an email, say, and then wanted to attach a photo, I could navigate to my iphoto library and choose the Albums fo