ORA-13349: polygon boundary crosses itself

Hi,
I have the following scenario in a polygon ("o" is polygon boundary):
oooooooooooooooooooooooooooooooooooo
oo#########################oo
oo#########################oo
oo##################ooooooooooo
oo##################oo
oo#########oooooooooooooo
oo#########oo########oo
oo#########oo########oo
oo##########oo########oo
oo############oooooooooooo
oo#####################ooooooooooo
oo###########################oo
oo###########################oo
oo###########################oo
oooooooooooooooooooooooooooooooooooooooo
This is getting invalidated and throwing me the following error:
ORA-13349: polygon boundary crossesitself
How do i fix the error? Is there a way i can found out such cases using a query?
Edited by: GreenHorn on Feb 21, 2012 12:04 PM

GreenHorn,
You should use SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT you can find details in the Spatial documentation. This will identify all the errors. Solving them depends on what they are.
A couple of questions:
Where did the data come from?
What version of Oracle are you using?
Do you have access to any GIS tools?
Regards.
Ivan

Similar Messages

A bizarre ORA-13349 case in 9i

Hi all,
We have just migrated from 8.17 to 9.2 and encountered a rather strange validation error on a particular polygon geometry.
Subject Geometry:
Parcel polygon composed of 4 polylines and 3 arcs.
Validation SQL:
SELECT SDO_GEOM.VALIDATE_GEOMETRY(SPATIALAREA, mtolerance) FROM PARCEL835105;
Error:
ORA-13349 (polygon boundary crosses itself) ONLY occurs when mtolerance is between 0.05 and 0.009. The geometry is considered fine when mtolerance is above 0.06 or below 0.008
Observation:
We examined the polygon using GeoMedia tool by traversing its vertices and could not find any apparent error.
If you want to try the geometry you may create the following files by cutting-&-pasting the content underneath each file heading. Then run at the system prompt (DOS) IMPORT.BAT usr/pass@connectionstring.
Bo Guo
Maricopa County Assessor's Office
Phoenix, AZ
602-506-0930
**************** PARCEL835105.DAT ********
1525|2003| |pt||||1|1005|7|1|2|1|5|2|2|9|2|2|13|2|1|15|2|2|19|2|1|21|2|1|;658946.23100000003|870467.35999999999|658884.96200000006|870464.85400000005|658829.65517262102|870462.59209484397|658778.28773826023|870459.781195155|658727.01800000004|870455.54700000002|658692.40116387932|870451.87949395797|658657.85900000005|870447.56499999994|658657.79700328002|870442.51112167106|658743.64884854865|870452.05702360102|658829.85199999996|870457.59600000002|658941.16799999995|870462.14899999998|658946.23100000003|870467.35999999999|:||||
**************** PARCEL835105.PRE ********
CREATE TABLE PARCEL835105 (
ID NUMBER(10,0),
SPATIALAREA MDSYS.SDO_GEOMETRY,
APN VARCHAR2(12),
FLOOR NUMBER(10,0),
DGN VARCHAR2(12),
SOURCE_CD VARCHAR2(2), primary key (ID) );
Exit;
**************** PARCEL835105.POS ********
insert into USER_SDO_GEOM_METADATA values('PARCEL835105', 'SPATIALAREA' ,MDSYS.SDO_DIM_ARRAY( MDSYS.SDO_DIM_ELEMENT('X', 232850, 993600, 0.03), MDSYS.SDO_DIM_ELEMENT('Y', 526000, 1134000, 0.03)), NULL );
Commit;
Exit;
**************** PARCEL835105.CTL ********
LOAD DATA
INFILE 'PARCEL835105.Dat'
APPEND INTO TABLE PARCEL835105
FIELDS TERMINATED BY '|' OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
ID,
SPATIALAREA COLUMN OBJECT
( sdo_gtype INTEGER EXTERNAL,
sdo_srid INTEGER EXTERNAL,
isnull FILLER CHAR,
SDO_POINT COLUMN OBJECT NULLIF SPATIALAREA.isnull="pt"
( X INTEGER EXTERNAL,
Y INTEGER EXTERNAL,
Z INTEGER EXTERNAL),
SDO_ELEM_INFO VARRAY terminated by ';'
(SDO_ORDINATES char(38)),
SDO_ORDINATES VARRAY terminated by ':'
(SDO_ORDINATES char(38))) ,
APN,
FLOOR,
DGN,
SOURCE_CD )
**************** IMPORT.BAT********
@echo off
REM Copyright (c) 1999-2002 by Intergraph Corporation. All Rights Reserved.
Rem Use this script to create tables and metadata with PL/SQL and populate tables with SQL*Loader.
if "%1"=="" goto usage
SQLPLUS %1 @"PARCEL835105.PRE"
SQLLDR %1 CONTROL= PARCEL835105
SQLPLUS %1 @"PARCEL835105.POS"
goto end
: usage
@echo Syntax of the command is: "Import <username>/<password>@<ConnectString>"
echo Examples:
echo Import scott/tiger@db_orcl
: end
pause

Doc ID: Note:1020247.102,Subject: Validating Geometry Returns ORA-13349 or ORA-13356 [published @ metalink]
Problem Description:
====================
Validating geometries for polygons in the Spatial Data Cartridge, may give: ORA-13349: polygon boundary crosses itself or ORA-13356 adjacent points in a geometry are redundant However, examining the polygon data shows that there are no crossing lines and no redundant points. This error may also be raised by SDO_BUFFER, which will appear to create an invalid polygon. Solution
Description:
=====================
This is caused by the SDO_TOLERANCE being set to an inappropriate value for the data in the layer. The tolerance will be taken into account when validating whether two points are the same or if two lines cross.
Explanation:
============
SDO_VALIDATE_GEOMETRY generates an ORA-13349 when it detects that the geometric properties of the data are incorrect, and that the shape crosses itself. The reason for the errors is that the buffer function sometimes needs to generate very small shapes, typically circular arcs. There are situations where the ordinates generated have a precision higher than the SDO_TOLERANCE setting. Once rounded using the SDO_TOLERANCE setting, then it is possible that the shape appears to cross itself (ORA-13349). Setting the tolerance to 0.0 will remove the errors, since rounding will no longer happen. An simple example is if there are two points on the polygon: 2.60, 3.00 and 2.56, 3.00 with the tolerance set to .05 When rounded these will both appear to be 2.6, 3.00 and give the ORA-13356 error. Setting the tolerance to .005 would avoid this error. For SDO_BUFFER this error should not be reported from 8.1.6 onwards.

Line string validation and ORA-13349 on polygons

Hi all,
We are having the following problem:
Our application accepts linestrings and connects them to create polygons. Each individual line validates TRUE but some polygons validate with ORA-13349. The problem is caused by lines that we call Lightning bolts. These are lines that cut back very sharp on themselves so that one or more points are within tolerance distance of a line segment.
An example:
mdsys.sdo_geometry(2002
,null
,null
,mdsys.sdo_elem_info_array(1, 2, 1)
,MDSYS.SDO_ORDINATE_ARRAY(258699.59,472878.73
,258688.58,472879.66
,258688.589,472879.659));
Oracle spatial seems to be very tolerant in validating these lines but once they are used in a polygon they are not accepted.
Why is this ?
Also we are looking for is a way to detect these lines before the polygons are created.
thanks, Rene

Hi,
To detect the "lightning bolts" this procedure seems promising.
Do a self intersect of the geometry.
Determine de spatial relationship between the original and the self intersect.
If the spatial relationship is not "EQUAL" you have you lightning.
Here is a real life example:
declare
l_geo1 mdsys.sdo_geometry := mdsys.sdo_geometry(2002
,90112
,null
,mdsys.sdo_elem_info_array(1, 2, 1)
,mdsys.sdo_ordinate_array(258727.255
,472853.276
,258724.984
,472848.338
,258714.12
,472852.98
,258709.61
,472854.55
,258710.89
,472859.11
,258712.41
,472865.36
,258712.3
,472868.37
,258711.51
,472871.47
,258709.83
,472874.33
,258704.77
,472877.1
,258699.59
,472878.73
,258688.58
,472879.66
,258688.589
,472879.659));
l_geo2 mdsys.sdo_geometry;
l_result varchar2(100);
l_tolerance number := 0.0005;
begin
l_geo2 := mdsys.sdo_geom.sdo_intersection(l_geo1, l_geo1, l_tolerance);
l_result := sdo_geom.relate(l_geo1, 'mask=determine', l_geo2, l_tolerance);
dbms_output.put_line(l_result);
end;
This example returns an unknown mask 100110001 which I believe should be a OVERLAPBDYDISJOINT. But it is definitely not an EQUAL.
I will have to go and find some more examples to test this method.
thanks Rene

Again: ORA-13349 (Self-touch)

I know this topic has been discussed several times.
My question is, how to store my land use data as shown in picture linked below:
http://mroy.wordpress.com/files/2006/07/ora-13349.jpg
Bunch of polygon "B" touched each other, so it's caused polygon "A" self touched.
Should I manipulate the data, while the data it self is real-world data? Why ESRI ArcGIS topology doesn't think this is an error?
TIA,
Roy Irwan

Bryan Hall wrote:
I would hazard to guess that the polygons inside the
multipolygon don't touch, but actually overlap.Well, actually they are touched each other. They have exactly the same coordinate at one vertex, that's why I call it 'touched'.
From the ESRI Shape validation page found at the
bottom of this document:
http://edndoc.esri.com/arcsde/9.0/general_topics/shape
_validation.htm
* Multipart area shapes may not overlap. However, two
parts may touch at a point.Good article. As I told you, my data has been validated by ArcGIS, and they are all valid.
For SDO_GEOMETRY multipolygons:
There can be no shared area between polygons
Different polygons can touch each other at point
locations, but the boundaries cannot run along each
other.I completely clear about the rules. But why? Why can't we have touched polygons covered by other polygon? Even this is the real condition?
Rgds,
Roy Irwan

Do you have any plans to add user polygon (boundary) creation ability to your great Excel Power Map program ?

Hi Microsoft Excel Power Map program team!
I looked @ your Excel Power Map program add on, and it’s great.
However everyone is looking for the ability for the user to create polygon (boundary) maps.
It should not be that hard to add this functionality onto such a great map program you already have.
For example: let’s say one has 10 latitude & longitude coordinates and he wants to see the polygon (boundary) of them on your great map. One should be able to just put those 10 latitude & longitude coordinates in an Excel sheet, fire up your Power
Map, select that it should be plotted as a polygon (boundary) and it will display on the map.
Does Microsoft have any plans to add user polygon (boundary) map creation ability to your great Excel Power Map program?
I would also like to see Excel Power map have USA census tracts built into it just like is has USA zip codes built into it. Census data is also very important as thousands and thousands of people need to display polygon (boundary) for census tracts.
Please let me know if Microsoft has any plans to add user polygon (boundary) creation ability to its great Excel Power Map program?
Thank you very much!

Hi,
Thanks for your feedback, based on your feature required, I'll move your thread to Power Map forum, there might be give us some light.
https://social.technet.microsoft.com/Forums/en-US/home?forum=powermap&filter=alltypes&sort=lastpostdesc
Regards,
George Zhao
TechNet Community Support
It's recommended to download and install
Configuration Analyzer Tool (OffCAT), which is developed by Microsoft Support teams. Once the tool is installed, you can run it at any time to scan for hundreds of known issues in Office
programs.

Need to Improve Performance on a Spatial Boundary Crossing Calculator

I am attempting to compare a series of geometries to calculate a number of statistics where they overlap. Essentially I have a table of 50,000 lines and another table of 1000 circles. I need to determine which lines overlap each circle, and for each intersection, I need to determine how much time and distance each line spends in each circle.
I have a PL/SQL program that performs this operation now and it works. The problem is that it takes far too long.
Here is a summary of how the job runs:
1) For each LINE, determine which CIRCLES it overlaps with
2) Each each LINE/CIRCLE pair, determine the intersection points
3) Insert the intersection points in a temporary table
4) Once you have all the points, pair them up as Entry/Exit points for each circle
5) Calculate duration (time) and distance between entry and exit points
6) Return to step 1 for next LINE
There are multiple loops here:
1-6 is the outer loop performed once for each of the 50,000 lines.
2-3 is performed once for each line/circle pair (probable avg of 5 circles per line)
4-5 is performed once again for each line/circle pair
Even if the process only takes a couple of seconds per LINE, we are still taking more than 24 hours to process, which is not acceptable.
This original process was written with 9i, and I am now running 10gR2, so I know there are new features that should help. For starters, I think I can use SDO_JOIN in place of the original outer loop to generate a complete list of geometry interactions in one query. Of course, I am still concerned about how long that might take.
Even more troubling is, if that works, I still don't see how to improve the rest of the calculations. Any suggestions would be appreciated.

No, I don't mind providing it.
Here it is:
-- cre_&stab._bndxing.sql
--Procedure definition of bndxings
def stab=&1
CREATE OR REPLACE PROCEDURE Find_&stab._bndxings
(theDate IN DATE, theStr IN VARCHAR2) IS
--Select flights from table
CURSOR FCursor IS
SELECT new_Flight_Index,
Acid,
New_Act_Date,
Dept_Aprt,
Dep_Time,
Arr_Aprt,
Arr_Time,
Acft_Type,
Physical_Class,
User_Class,
Nrp,
     d_lat,
d_lon,
a_lat,
a_lon,
     flight_track
FROM jady.Flight
WHERE new_act_date = theDate
AND flight_track IS NOT NULL
AND substr(acid,1,1) = theStr
--AND acid in (select acid from name_temp)
--AND acid = 'AAL1242'
ORDER BY acid,new_flight_index;
--Temp vars for storing flight info
fi_var NUMBER;
acid_var VARCHAR2(7);
dep_time_var DATE;
arr_time_var DATE;
F_Rec FCursor%ROWTYPE;
--Temp vars for flight
tcnt INTEGER;
cur_lat NUMBER;
cur_lon NUMBER;
last_lat NUMBER;
last_lon NUMBER;
--Temp vars for airspace and xing geometries
aname VARCHAR2(20);
bxings MDSYS.SDO_GEOMETRY;
bxcnt INTEGER;
--Select xings made from temp bndxing table
CURSOR XCursor IS
SELECT Act_Date,
Name,
Lon,
Lat,
Alt,
Time,
OPS
FROM bndxing_tmp
WHERE Flight_Index = fi_var
AND Acid = acid_var
ORDER BY Name,Time;
--Temp vars for paired in/out xings
ad date;
ilon NUMBER;
ilat NUMBER;
ialt NUMBER;
isec NUMBER;
iops NUMBER;
olon NUMBER;
olat NUMBER;
oalt NUMBER;
osec NUMBER;
oops NUMBER;
gcr NUMBER;
dist NUMBER;
dura NUMBER;
ops VARCHAR2(1);
i INTEGER;
i_aname VARCHAR2(20);
o_aname VARCHAR2(20);
names_match BOOLEAN;
theSeq NUMBER;
same_airport_no_tzdata BOOLEAN;
-- Cursor and variables for bndxing sequencing
CURSOR BCursor IS
SELECT * FROM bndxing
WHERE act_date = theDate
     AND Acid = acid_var
     AND Flight_Index = fi_var
ORDER BY in_time
FOR UPDATE;
BRec BCursor%ROWTYPE;
--Error logging variable
strErrorMessage VARCHAR2(255);
BEGIN --Start of Main Loop
--Loop for each flight in table
OPEN FCursor;
FETCH FCursor INTO F_Rec;
-- FOR f IN FCursor LOOP
WHILE FCursor%FOUND LOOP
fi_var:= F_Rec.new_Flight_Index;
acid_var := F_Rec.acid;
arr_time_var := F_Rec.arr_time;
dep_time_var := F_Rec.dep_time;
last_lat := -10000; --initializtion
last_lon := -10000; --initializtion
-- DEBUG STATEMENT
/* Insert into bnd_error values (err_seq.NEXTVAL,
sysdate,
F_Rec.Acid,
F_Rec.new_Flight_Index,
'Checkpoint 1');
--Add departing xing to temp table if in US airspace
DECLARE
CURSOR DepCur IS
SELECT Name
FROM &stab.
WHERE SDO_RELATE(Airspace,
     MDSYS.SDO_GEOMETRY(2001,8307,
MDSYS.SDO_POINT_TYPE(F_Rec.d_lon,F_Rec.d_lat,null),
     null, null),
'mask=CONTAINS querytype=WINDOW') = 'TRUE';
BEGIN -- Start of Departing Airspace Loop
FOR c in DepCur LOOP
INSERT INTO Bndxing_Tmp VALUES (F_Rec.new_Flight_Index,
F_Rec.acid,
F_Rec.New_Act_Date,
c.name,
2,
F_Rec.d_lon,
F_Rec.d_lat,
0,
(F_Rec.Dep_Time-F_Rec.New_Act_Date)*86400);
END LOOP;
EXCEPTION
WHEN NO_DATA_FOUND THEN NULL;
WHEN OTHERS THEN
strErrorMessage := SQLERRM;
INSERT INTO bnd_error VALUES (err_seq.NEXTVAL,
sysdate,
                         F_Rec.Acid,
                         F_Rec.new_Flight_Index,
                         'Exception from Departing Airspace loop: ' || strErrorMessage);
COMMIT;
END; -- End of Departing Airspace Loop
--Add arrival xing to temp table if in US airspace
DECLARE
CURSOR ArrCur IS
SELECT name
FROM &stab.
WHERE SDO_RELATE(Airspace,
     MDSYS.SDO_GEOMETRY(2001,8307,
MDSYS.SDO_POINT_TYPE(F_Rec.a_lon, F_Rec.a_lat, null),
null, null),
'mask=CONTAINS querytype=WINDOW') = 'TRUE';
BEGIN -- Start of Arrival Airspace Loop
FOR c IN ArrCur LOOP
INSERT INTO Bndxing_Tmp VALUES (F_Rec.new_Flight_Index,
F_Rec.acid,
F_Rec.New_Act_Date,
c.name,
1,
F_Rec.a_lon,
F_Rec.a_lat,
0,
(F_Rec.Arr_Time - F_Rec.New_Act_Date)*86400);
END LOOP;
EXCEPTION
WHEN NO_DATA_FOUND THEN NULL;
WHEN OTHERS THEN
strErrorMessage := SQLERRM;
INSERT INTO bnd_error VALUES (err_seq.NEXTVAL,
sysdate,
                         F_Rec.Acid,
                         F_Rec.new_Flight_Index,
                         'Exception from Arrival Airspace loop: ' || strErrorMessage);
COMMIT;
END; -- End of Arrival Airspace Loop
--DEBUG STATEMENT
/* Insert into bnd_error values (err_seq.NEXTVAL,
sysdate,
F_Rec.Acid,
F_Rec.new_Flight_Index,
'Checkpoint 4');
--Find all intersections between the flight track and airspace boundaries and insert into temp table
DECLARE
--Find airspace boundaries that interact with the flight track
CURSOR CCursor IS
SELECT Name, Boundary
FROM &stab.
WHERE SDO_RELATE(boundary,F_Rec.flight_track,'mask=OVERLAPBDYDISJOINT querytype=WINDOW')='TRUE';
BEGIN
FOR c IN CCursor LOOP
bxings := SDO_GEOM.SDO_INTERSECTION(c.boundary,F_Rec.flight_track,10);
bxcnt:=bxings.sdo_ordinates.count;
LOOP
INSERT INTO bndxing_tmp VALUES (F_Rec.new_Flight_Index,
F_Rec.acid,
F_Rec.New_Act_Date,
c.name,
0,
bxings.sdo_ordinates(bxcnt-3),
bxings.sdo_ordinates(bxcnt-2),
bxings.sdo_ordinates(bxcnt-1),
SDO_LRS.FIND_MEASURE(F_Rec.flight_track,
MDSYS.SDO_GEOMETRY(2001,8307,NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1,1,1),
MDSYS.SDO_ORDINATE_ARRAY(bxings.sdo_ordinates(bxcnt-3),
bxings.sdo_ordinates(bxcnt-2)))));
bxcnt := bxcnt - 4;
EXIT WHEN (bxcnt < 1);
END LOOP;
END LOOP; -- end CCursor LOOP
EXCEPTION
WHEN OTHERS THEN
strErrorMessage := SQLERRM;
INSERT INTO bnd_error VALUES (err_seq.NEXTVAL,
sysdate,
                         F_Rec.Acid,
                         F_Rec.new_Flight_Index,
                         'Exception from bndxing loop: ' || strErrorMessage);
COMMIT;
END;
--DEBUG STATEMENT
/* Insert into bnd_error values (err_seq.NEXTVAL,
sysdate,
F_Rec.Acid,
F_Rec.new_Flight_Index,
'Checkpoint 6');
--After all xings for a flight have been collected sort Xings by name and time and grab pairwise
theSeq :=0;
OPEN XCursor;
BEGIN -- Start of Stats Loop
LOOP
     FETCH XCursor INTO ad, i_aname, ilon, ilat, ialt, isec, iops; --CHANGED CODE
EXIT WHEN XCursor%NOTFOUND ;
FETCH XCursor INTO ad, o_aname, olon, olat, oalt, osec, oops; --CHANGED CODE
EXIT WHEN XCursor%NOTFOUND ;
names_match := (i_aname = o_aname); --NEW CODE
WHILE not names_match LOOP --NEW CODE
i_aname := o_aname; --NEW CODE
     ilon := olon; --NEW CODE
     ilat := olat; --NEW CODE
     ialt := oalt; --NEW CODE
     isec := osec; --NEW CODE
     iops := oops; --NEW CODE
FETCH XCursor INTO ad, o_aname, olon, olat, oalt, osec, oops; --NEW CODE
EXIT WHEN XCursor%NOTFOUND; --NEW CODE
names_match := (i_aname = o_aname); --NEW CODE
END LOOP; --NEW CODE
     --Calculate stats
     BEGIN -- Start of In Values Loop
     i:=4;
     IF (iops<>2) THEN
     -- Did not depart from this airspace, calculate entry altitude into airspace.
     LOOP
     i:=i+4;
     EXIT WHEN F_Rec.flight_track.sdo_ordinates(i)>isec;
     END LOOP;
IF ( F_Rec.flight_track.sdo_ordinates(i-1) = F_Rec.flight_track.sdo_ordinates(i-5) ) THEN
ialt := F_Rec.flight_track.sdo_ordinates(i-1);
ELSE
ialt:=SDO_LRS.FIND_MEASURE(
     MDSYS.SDO_GEOMETRY(3302,8307,NULL,
     MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),
MDSYS.SDO_ORDINATE_ARRAY(F_Rec.flight_track.sdo_ordinates(i-7),
F_Rec.flight_track.sdo_ordinates(i-6),
F_Rec.flight_tracK.sdo_ordinates(i-5),
F_Rec.flight_track.sdo_ordinates(i-3),
F_Rec.flight_track.sdo_ordinates(i-2),
F_Rec.flight_track.sdo_ordinates(i-1))),
     MDSYS.SDO_GEOMETRY(2001,8307,NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1,1,1),
MDSYS.SDO_ORDINATE_ARRAY(ilon,ilat)));
END IF;
     END IF;
     EXCEPTION
     WHEN OTHERS THEN
     strErrorMessage := SQLERRM;
     INSERT INTO bnd_error VALUES (err_seq.NEXTVAL,
     sysdate,
                              F_Rec.Acid,
                              F_Rec.new_Flight_Index,
                              'Exception from In Values section: ' || strErrorMessage);
     COMMIT;
     END; -- End of In Values Loop
BEGIN -- Start of Out Values Loop
     i:=4;
     IF (oops<>1) THEN
-- Did not arrive in this airspace, calculate departure altitude from airspace.
LOOP
i:=i+4;
EXIT WHEN F_Rec.flight_track.sdo_ordinates(i)>osec;
END LOOP;
     --Find alt at this time
IF ( F_Rec.flight_track.sdo_ordinates(i-1) = F_Rec.flight_track.sdo_ordinates(i-5) ) THEN
oalt := F_Rec.flight_track.sdo_ordinates(i-1);
ELSE
     oalt:=SDO_LRS.FIND_MEASURE(
     MDSYS.SDO_GEOMETRY(3302, 8307, NULL,
     MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),
MDSYS.SDO_ORDINATE_ARRAY(F_Rec.flight_track.sdo_ordinates(i-7),
F_Rec.flight_track.sdo_ordinates(i-6),
F_Rec.flight_track.sdo_ordinates(i-5),
F_Rec.flight_track.sdo_ordinates(i-3),
F_Rec.flight_track.sdo_ordinates(i-2),
F_Rec.flight_track.sdo_ordinates(i-1))),
     MDSYS.SDO_GEOMETRY(2001,8307,NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1,1,1),
MDSYS.SDO_ORDINATE_ARRAY(olon,olat)));
END IF;
END IF;
     EXCEPTION
WHEN OTHERS THEN
strErrorMessage := SQLERRM;
INSERT INTO bnd_error VALUES (err_seq.NEXTVAL,
     sysdate,
                              F_Rec.Acid,
                              F_Rec.new_Flight_Index,
                              'Exception from Out Values loop: ' || strErrorMessage);
COMMIT;
END; -- End of Out Values Loop
BEGIN -- Start of Finish Loop
--Find GCR, actual distance and duration in airspace
gcr := SDO_GEOM.SDO_DISTANCE(MDSYS.SDO_GEOMETRY(2001,8307,
MDSYS.SDO_POINT_TYPE(ilon,ilat,NULL),NULL,NULL),
MDSYS.SDO_GEOMETRY(2001,8307,
MDSYS.SDO_POINT_TYPE(olon,olat,NULL),NULL,NULL),
10,'unit=naut_mile');
--DEBUG STATEMENT
/* Insert into bnd_error values (err_seq.NEXTVAL,
sysdate,
F_Rec.Acid,
F_Rec.new_Flight_Index,
'In Finish Loop: isec: ' ||isec||' osec: '||osec
                    ||' airspace: '||i_aname);
dist := SDO_GEOM.SDO_LENGTH(SDO_LRS.CLIP_GEOM_SEGMENT(F_Rec.flight_track,isec,osec),10,'unit=naut_mile');
     dura := (osec - isec);
--Set OPS Flag
iops := iops + oops;
IF (iops=3) THEN
ops := 'B';
ELSIF (iops=2) THEN
ops := 'D';
ELSIF (iops=1) THEN
ops := 'A';
ELSE
ops := 'O';
END IF;
     theSeq := theSeq + 1;
--Insert into Bndxing table
INSERT INTO Bndxing VALUES (F_Rec.Acid,
F_Rec.new_Flight_Index,
F_Rec.New_Act_Date,
     theSeq,
     F_Rec.Dept_Aprt,
     F_Rec.Arr_Aprt,
i_aname,
round(ilon,3),
round(ilat,3),
ialt,
isec/86400 + ad,
NULL, -- IN_SPEED (TBD)
round(olon,3),
round(olat,3),
oalt,
osec/86400 + ad,
NULL, -- OUT_SPEED (TBD)
gcr,
dist,
dura,
ops, -- CHANGED CODE
nvl(F_Rec.Acft_Type,'----'),
NULL, -- IF_FLAG (NULL)
nvl(F_Rec.Physical_Class,'-'),
nvl(F_Rec.User_Class,'-'),
F_Rec.Nrp,
NULL, -- FFS_FLAG (NULL)
NULL, -- ER_SG (NULL)
NULL, -- ER_TI (NULL)
NULL, -- ER_ZT (NULL)
NULL, -- ER_DU (NULL)
NULL, -- ER_SP (NULL)
NULL -- ER_BD (NULL)
DELETE FROM bndxing_tmp
     WHERE acid=F_Rec.Acid and flight_index=F_Rec.new_Flight_Index;
     COMMIT;
EXCEPTION
WHEN OTHERS THEN
strErrorMessage := SQLERRM;
INSERT INTO bnd_error VALUES (err_seq.NEXTVAL,
     sysdate,
     F_Rec.Acid,
     F_Rec.new_Flight_Index,
     'Exception from Finish loop: ' || strErrorMessage);
COMMIT;
END; -- End of Finish Loop
END LOOP;
EXCEPTION
WHEN OTHERS THEN
strErrorMessage := SQLERRM;
INSERT INTO bnd_error VALUES (err_seq.NEXTVAL,
sysdate,
F_Rec.Acid,
F_Rec.new_Flight_Index,
'Exception from Stats loop: ' || strErrorMessage);
COMMIT;
END; -- End of Stats Loop
--Reset cursor and track geometry
CLOSE XCursor;
F_Rec.flight_track.sdo_ordinates.delete;
-- delete from hist_bndxing_tmp
-- where acid=acid_var and new_flight_index=fi_var;
FETCH FCursor INTO F_Rec;
END LOOP;
--DEBUG STATEMENT
/* INSERT INTO bnd_error VALUES (err_seq.NEXTVAL,
sysdate,
acid_var,
fi_var,
'Checkpoint 7');
CLOSE FCursor;
theSeq := 1;
OPEN BCursor;
LOOP
FETCH BCursor INTO BRec;
IF BCursor%NOTFOUND THEN
EXIT;
END IF;
UPDATE bndxing
SET segment = theSeq
WHERE CURRENT OF BCursor;
theSeq := theSeq + 1;
END LOOP;
CLOSE BCursor;
EXCEPTION
WHEN OTHERS THEN
strErrorMessage := SQLERRM;
Insert into bnd_error values (err_seq.NEXTVAL,
sysdate,
                         acid_var,
                         fi_var,
                         'Exception from main: ' || strErrorMessage);
COMMIT;
CLOSE FCursor;
END; -- End of Main Loop
SHOW ERRORS;
--exit;

ORA-13349 with different tolerances

Hi
I have the following geometry:
SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 5, 3, 1, 2, 2, 9, 2, 1, 25, 2, 2), SDO_ORDINATE_ARRAY(577581.917, 184411.939, 577578.113, 184409.454, 577574.969, 184406.174, 577572.632, 184402.257, 577571.243, 184397.912, 577576.479, 184372.519, 577595.843, 184375.038, 577605.277, 184384.152, 577601.714, 184399.53, 577602.738, 184399.438, 577599.34, 184414.163, 577598.332, 184414.207, 577590.675, 184414.136, 577586.17, 184413.538, 577581.917, 184411.939))
I got from validate_geometry the following output:
SQL> select sdo_geom.validate_geometry(geom, 0.05) from bienfonds_tser where fid = 52375;
SDO_GEOM.VALIDATE_GEOMETRY(GEOM,0.05)
TRUE
SQL> select sdo_geom.validate_geometry(geom, 0.03) from bienfonds_tser where fid = 52375;
SDO_GEOM.VALIDATE_GEOMETRY(GEOM,0.03)
13349
SQL> select sdo_geom.validate_geometry(geom, 0.01) from bienfonds_tser where fid = 52375;
SDO_GEOM.VALIDATE_GEOMETRY(GEOM,0.01)
TRUE
Wath I don't understand: I get a valid geometry with 0.01 and 0.05, but a invalid with 0.03.
I expected that a geometry is invalid to a certain tolerance, say 0.05, and for tolerances less than 0.05 the geometry is valid.
Did I understand something wrong? Can someone explain me?
Philipp

I wonder if this is an XP platform specific bug. Can you post the results of the following three statements?
select sdo_geom.validate_geometry(
MDSYS.SDO_GEOMETRY(2003, NULL, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 5, 3, 1, 2, 2, 9, 2, 1, 25, 2, 2),
MDSYS.SDO_ORDINATE_ARRAY(577581.917, 184411.939, 577578.113, 184409.454,
577574.969, 184406.174,
577572.632, 184402.257, 577571.243, 184397.912, 577576.479, 184372.519,
577595.843, 184375.038, 577605.277, 184384.152, 577601.714, 184399.53,
577602.738, 184399.438, 577599.34, 184414.163, 577598.332, 184414.207,
577590.675, 184414.136, 577586.17, 184413.538, 577581.917, 184411.939)),0.05) from dual;
select sdo_geom.validate_geometry(
MDSYS.SDO_GEOMETRY(2003, NULL, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 5, 3, 1, 2, 2, 9, 2, 1, 25, 2, 2),
MDSYS.SDO_ORDINATE_ARRAY(577581.917, 184411.939, 577578.113, 184409.454,
577574.969, 184406.174,
577572.632, 184402.257, 577571.243, 184397.912, 577576.479, 184372.519,
577595.843, 184375.038, 577605.277, 184384.152, 577601.714, 184399.53,
577602.738, 184399.438, 577599.34, 184414.163, 577598.332, 184414.207,
577590.675, 184414.136, 577586.17, 184413.538, 577581.917, 184411.939)),0.03) from dual;
select sdo_geom.validate_geometry(
MDSYS.SDO_GEOMETRY(2003, NULL, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 5, 3, 1, 2, 2, 9, 2, 1, 25, 2, 2),
MDSYS.SDO_ORDINATE_ARRAY(577581.917, 184411.939, 577578.113, 184409.454,
577574.969, 184406.174,
577572.632, 184402.257, 577571.243, 184397.912, 577576.479, 184372.519,
577595.843, 184375.038, 577605.277, 184384.152, 577601.714, 184399.53,
577602.738, 184399.438, 577599.34, 184414.163, 577598.332, 184414.207,
577590.675, 184414.136, 577586.17, 184413.538, 577581.917, 184411.939)),0.01) from dual;
Thanks.

Format of VALIDATE_GEOMETRY_WITH_CONTEXT output

Hi,
I'm trying to write a generic routine to display validation errors (e.g. show the geometry with the erroneous segments highlighted), with the aim to more easily correct them.
What I am wondering is, is there are documentation on the format of the context information output by VALIDATE_GEOMETRY_WITH_CONTEXT, as there are several outputs produced
e.g.
13356 [Element <1>] [Coordinate <4>][Ring <1>]
13349 [Element <1>] [Ring <1>][Edge <6>][Edge <21>]
I can decipher these specific errors, but a definitive reference would be appreciated.
thanks in advance,
Andrew

Hi Andrew,
I know this is hard, but it is a great improvement from earlier, when Oracle didn't report any location information.
The reference for the numbers (13356 or 13349) is the error messages documentation.
ORA-13349: polygon boundary crosses itself
Cause: The boundary of a polygon intersects itself.
Action: Correct the geometric definition of the object.
ORA-13356: adjacent points in a geometry are redundant
Cause: There are repeated points in the sequence of coordinates.
Action: Remove the redundant point.
The rest of the information is an attempt to help you locate where in the geometry the problem was found.
13356 [Element <1>] [Coordinate <4>][Ring <1>]
The first element in SDO_ORDINATE array is the one with the problem
The 4th vertex is a duplicate of the 5th vertex (falls within the specified tolerance so the two coordinates are considered the same).
Ring 1 - The first element is a polygon, and a single polygon can consist of an exterior ring with one or more holes (interior rings). Since this is ring 1, it is the exterior ring associated with the first element. If it was Ring 2, it would be the first hole, ring 3 would be the second hole, and so on.
13349 [Element <1>] [Ring <1>][Edge <6>][Edge <21>]
With this error the first ring (exterior ring) of the first element in the sdo_ordinate_array has edges that self intersect. The edges are edge 6 and edge 21. The edges can be identifed as the 6th and 7th vertices (edge 6) and the 21st and 22nd vertices.
You can use sdo_util.get_vertices to look at coordinate pairs.
There is also sdo_util.remove_duplicate_vertices to get rid of the duplicate vertex errors.
Sometimes I union a geometry with itself to see if Oracle can fix an invalid polygon whose edges intersect (this isn't guaranteed to work because operations on invalid geometries aren't supported), but if it succeeds I look at the input and output geometries together and if I am convinced they are the same then I put the new geometry back into the table.
Hope this helps,
Dan

Sdo_geom.validate_geometry_with_context - Reporting multiple errors

All Oracle versions.
sdo_geom.validate_geometry_with_context appears to report only the first error it finds in an sdo_geometry.
Thus, it reports only the first duplicate vertex in "ORA-13356: adjacent points in a geometry are redundant", or only
the first loop in a ring for "ORA-13349: polygon boundary crosses itself".
I understand that, for some errors, reporting more than one error would be difficult but for more simple errors such as
the two mentioned, it would be most helpful to have validate_geometry_with_context report more than one error location
in its return string. Such reporting would reduce the time and effort required in find-fix-find error correction cycle.
Comments?
regards
Simon

A triangle is a bad example for ORA-13349. In fact, it is impossible for a triangle not to be right unless two points are the same.
I don't agree with a lot of the comments because I know that many simple types of errors can be detected. Here is
a polygon with a hole that has multiple 13349 errors because of "bow-ties" or "loops in the outer boundary".
select sdo_geom.validate_geometry_with_context(MDSYS.SDO_GEOMETRY(2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1,17,2003,1),
                                  MDSYS.SDO_ORDINATE_ARRAY(
                                  523960.5, 5201847.7, 525174.7, 5202361.9, 525171.4, 5202328.8, 524843.0, 5202839.7,
                                  524889.4, 5202833.0, 523748.1, 5202484.7, 523781.3, 5202554.4, 523960.5, 5201847.7,
                                  524141.2, 5202192.9, 524223.1, 5202550.3, 524197.1, 5202520.5, 524502.3, 5202546.6,
                                  524584.2, 5202293.4, 524614.0, 5202345.6, 524171.0, 5202189.2, 524141.2, 5202192.9)),0.005) as error
          from dual;
ERROR
13349 [Element <1>] [Ring <1>][Edge <5>][Edge <7>] As you can see, validate_geometry_with_context() only returns the first loop in the outer boundary (1003).
But with a slight modification of approach we can get at least one more:
select sdo_geom.validate_geometry_with_context(b.geom,0.005) as error
from (select mdsys.sdo_util.extract(
                MDSYS.SDO_GEOMETRY(2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1,17,2003,1),
                                   MDSYS.SDO_ORDINATE_ARRAY(
                                   523960.5, 5201847.7, 525174.7, 5202361.9, 525171.4, 5202328.8, 524843.0, 5202839.7,
                                   524889.4, 5202833.0, 523748.1, 5202484.7, 523781.3, 5202554.4, 523960.5, 5201847.7,
                                   524141.2, 5202192.9, 524223.1, 5202550.3, 524197.1, 5202520.5, 524502.3, 5202546.6,
                                   524584.2, 5202293.4, 524614.0, 5202345.6, 524171.0, 5202189.2, 524141.2, 5202192.9)),1,a.elem_no) as geom
         from (select level as elem_no from dual connect by level < 3) a
      ) b;
ERROR
13349 [Element <1>] [Ring <1>][Edge <5>][Edge <7>]
13349 [Element <1>] [Ring <1>][Edge <7>][Edge <5>]So, by extension, it is possible to return all the other bow-ties: I have done this in a function I have written. I now
need to extend it to find all other bow-ties in a ring.
I have function that finds all duplicate vertices (13356) in a geometry. Works well.
select rownum as point, b.valid, c.geometry
from (select substr(sdo_geom.validate_geometry_with_context(a.geom,0.005),1,40) as valid,
               a.geom
          from (select MDSYS.SDO_GEOMETRY(2006, NULL, NULL,
                                  MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1,13,2,1),
                                  MDSYS.SDO_ORDINATE_ARRAY(50.0, 15.0, 55.0, 15.0, 55.0, 15.0, 55.0, 15.0, 60.0, 15.0, 60.0, 15.0, 65.0, 15.0)) as geom
                  from dual) a
        ) b,
        TABLE(sdo_error.getErrors(b.geom,0.005)) c;
POINT VALID                                    GEOMETRY
1     13356 [Element <1>] [Coordinate <2>] MDSYS.SDO_GEOMETRY(2001,NULL,MDSYS.SDO_POINT_TYPE(55,15,NULL),NULL,NULL)
2     13356 [Element <1>] [Coordinate <2>] MDSYS.SDO_GEOMETRY(2001,NULL,MDSYS.SDO_POINT_TYPE(55,15,NULL),NULL,NULL)
3     13356 [Element <1>] [Coordinate <2>] MDSYS.SDO_GEOMETRY(2001,NULL,MDSYS.SDO_POINT_TYPE(60,15,NULL),NULL,NULL)As I said, this can be done for simple elemental errors. Errors that involve interactions of rings for example are harder. But, gee, other
software packages provide such capability so it is possible. And, these are data-level issues so I think it reasonable that Oracle
provides an improved set of functions and not hand it over to external GIS software clients.
regards
Simon

How to find the points that define an edge?

I'm looking at a very large geometry that's generating an error from VALIDATE_GEOMETRY_WITH_CONTEXT:
ORA-13349: polygon boundary crosses itself 13349 [Element <5>] [Ring <1>][Edge <7566>][Edge <7591>]
How can I find the X & Y coordinates of those two edges?
It's a two-dimensional polygon, with thirty two inner rings, and extracting ring 5 doesn't show any obvious errors: It doesn't have seven thousand edges to it either though - is that supposed to be the edge number counting from the start of the outer ring, or just the start of that element?
Cheers
Simon Anderson
Scisys

Hi,
What I'm looking for is a way to report the error back to the end-user. The information is there in the form of:
[Element <5>] [Ring <1>][Edge <7566>][Edge <7591>]
But the exact position of the error is often hard to find in a CAD system.
I want to return edge 7566 and edge 7591 as geometry objects.
So the question is:
Given a geometry object and a list of element,ring,edge elements. How to create geometry objects for these edges?
Rene

Easyloader help

does anyone know Easyloader and how to upload a Oracle 8i Spatial table from a Mapinfo table ?
I tried to upload a table in Oracle8i Spatial starting from a Mapinfo table.
The question is : how the oracle table should be created to match the Mapinfo table ?
Could anyone forward me a Mapinfo table and the related oracle table to be used with Easyloader ?
Thanks
Cheers
Giovanni

Here are some issues I run in too sometimes
when I use Easyloader. I will also discuss
some workarounds. MapInfo does know about these issues and will have a new version of Easyloader that fixes them very soon.
Sometimes Easyloader uploads polygons that
generate the following error when you call mdsys.sdo_geom.validate_geometry.
ORA-13050 unable to construct spatial object
You must correct the 13050 geometries.
The problem occurs because Easyloader is not orienting the polygons correctly (i.e Outer rings counterclockwise and inner rings clockwise).
MapInfo is aware of the problem, and will
have a fix available very soon in a future
release of Easyloader.
Until then, for polygon layers, you can create a shortcut to easyloader.exe and
add a /v to the shortcut.
i.e. easyloader.exe /v
If you run the shortcut, it will upload data
into the Oracle 8.1.6 database, but in the
8.1.5 data format (single digit gtype and element type).
You can then use the Oracle Spatial migration utility SDO_MIGRATE.FROM_815_TO_81x to
correct the rotation of the polygon layer.
Another problem I have encountered with
MapInfo Easyloader is the tollerance
value is not always set small enough.
This may cause validate geometry to
produce the following Oracle errors:
ORA-13349 polygon boundary crosses itself
ORA-13356 adjacent points in a geometry are redundant
The workaround is after you upload your
data, you may have to make your tolerance values smaller in USER_SDO_GEOM_METADATA.
i.e. By default, Easyloader is setting
tolerance to .000005
change the tolerance to something
smaller .00000005
Mapinfo knows about the problem and will address this issue in a future version of Easyloader.
Also, I don't recommend creating the spatial index through Easyloader, or any other data
loading utility.
It is best to use the Spatial Index Advisor to tune and create your spatial indexes.
In Oracle 8.1.6, Oracle recommends a fixed index. The Spatial Index Advisor only allows you to do analysis for a hybrid index. In the performance white paper on OTN, it discusses how to workaround this, and create a fixed index with the advisor.
In Oracle 8.1.7, the spatial index advisor will allow you to tune for a fixed index directly.
Hope this helps. Thanks.
Dan

How to resolve VALIDATE_GEOMETRY_WITH_CONTEXT 'errors'?

Hello,
I have some problem to select my spatial data (see Result of sdo_within_distance ). Sometime I select data and my database connection will be separated (ORA-03113, ORA-03114).
Now I try to analys my data with VALIDATE_GEOMETRY_WITH CONTEXT:
SELECT c.SPA_CODE, SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(c.GEOM, 0.5)
FROM protection_area.sk_2006_spa c
WHERE SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(c.GEOM, 0.5)<>'TRUE'
ORDER BY c.SPA_CODE
Here a part of the result:
1     SKCHVU002     13348 [Element <1>] [Ring <2>]
2     SKCHVU003     13349 [Element <1>] [Ring <1>][Edge <5247>][Edge <5252>]
3     SKCHVU004     13367 [Element <5>] [Ring <1>]
4     SKCHVU009     13348 [Element <1>] [Ring <14>]
5     SKCHVU010     13348 [Element <2>] [Ring <1>]
6     SKCHVU013     13348 [Element <1>] [Ring <8>]
7     SKCHVU015     13348 [Element <6>] [Ring <7>]
8     SKCHVU016     13349 [Element <3>] [Ring <1>][Edge <2175>][Edge <2178>]
9     SKCHVU017     13367 [Element <5>] [Ring <2>]
10     SKCHVU018     13349 [Element <9>] [Ring <1>][Edge <5368>][Edge <5370>]
11     SKCHVU019     13348 [Element <14>] [Ring <29>]
12     SKCHVU021     13367 [Element <1>] [Ring <1>]
13     SKCHVU025     13367 [Element <1>] [Ring <13>]
What can I do to avoid this 'errors'?
I already tried this:
UPDATE protection_area.sk_2006_spa c
SET c.GEOM = SDO_UTIL.REMOVE_DUPLICATE_VERTICES(c.geom,0.5)
Any hints?
Thanks,
matthias

Hi,
You need to correct those geometries.
I've got this from Oracle Spatial 10g User's Guide:
Rings: A ring is only used with polygon elements. Exterior rings in a polygon are
considered polygon elements, and an exterior ring can include zero or more
interior rings (or holes). Each interior ring has its own ring designation, but Ring 1
is associated with the exterior polygon itself. For example, Element 1, Ring 1 refers to the first exterior polygon in a geometry; Element 1, Ring 2 refers to the first interior polygon of the first exterior polygon; and Element 1, Ring 3 refers to the second interior polygon. If the geometry is a multipolygon, Element 2, Ring 1 is
used to refers to the second exterior polygon. If there are interior polygons
associated with it, Element 2, Ring 2 refers to the first interior polygon of the
second exterior polygon.
Edges: An edge refers to a line segment between two coordinates. Edge 1 refers to the segment between coordinate 1 and coordinate 2, Edge 2 refers to the line segment between coordinates 2 and 3, and so on. The most common place to see edge errors when validating geometries is with self-intersecting polygons. (The Open Geospatial Consortium simple features specification does not allow a
polygon to self-intersect.) In such cases, Oracle reports error 13349 (polygon
boundary crosses itself), including the Element, Ring, and Edge numbers where
self-intersection occurs.
Hope it helps,
Luiz

Lookup of Oracle Error Message at application level

Hi
I'm writing a c# application that connects to an oracle database. My application queries a table containing a column with oracle error codes BUT NO ERROR MESSAGES. The application must show these error descriptions to the user. As I cannot expect the user to know errorcodes, the application should be able to translate it into the error message
e.g.: instead of showing "ORA-13349" I'd like to show a textbox "polygon boundary crosses itself".
Question: is the mapping <error_code, error_message> accessible to an application? How ?
Thank you,
Marco
ps: it's not possible to change the stored procedure! I've to solve it at the application level

You can use the function: standard.sqlerrm and pass as parameter the number of the error.
http://www.tunzi.ch/page.php?name=errm
Bye, Aron

SDO_RELATE and SDO_BUFFER

Hi Folks,
I created a generic stored procedure that gets a table and a polygon coordinates as parameters and returns
the table records that satisfy a relationship.
One example of fhe SQL executed by the procedure is:
select GEOFT_MESORREGIAO.* from GEOFT_MESORREGIAO
where SDO_RELATE(GEOFT_MESORREGIAO.MES_GM_POLIGONO,
SDO_GEOMETRY(2003,2000004,NULL,
SDO_ELEM_INFO_ARRAY(1,1003,1),
SDO_ORDINATE_ARRAY(-51.427259,-20.547785,-51.575114,-22.289193,-49.094429,-22.387763,-49.028716,-20.457420)),'mask=ANYINTERACT') ='TRUE'
The GEOFT_MESORREGIAO stores polygon geometries.
Running the example I got 7 rows as result.
In the same procedure, users can pass additional parameters to create a buffer around the polygon defined as the query window.
In this case, the SQL executed is:
select GEOFT_MESORREGIAO.* from GEOFT_MESORREGIAO
where SDO_RELATE(GEOFT_MESORREGIAO.MES_GM_POLIGONO,
SDO_GEOM.SDO_BUFFER(SDO_GEOMETRY(2003,2000004,NULL,
SDO_ELEM_INFO_ARRAY(1,1003,1),
SDO_ORDINATE_ARRAY(-51.427259,-20.547785,-51.575114,-22.289193,-49.094429,-22.387763,-49.028716,-20.457420)),10,0.05,'unit=KM'),'mask=ANYINTERACT') ='TRUE'
Running this example I got 6 rows as result.
This is not right to me, because if I'm using a bigger query window created by the buffer function, it was expected to get more rows
as result or, at least, the same number of rows returned by the first example.
This was tested in Oracle 11g R1.
Am I missing anything?
Regards,
Luis

Hi
When validating your inline geometry, it returns a ORA-13348: polygon boundary is not closed.
The first coordinate should be repeated at the end to close a ring in a polygon.
SDO_GEOMETRY(2003,8236,NULL,
SDO_ELEM_INFO_ARRAY(1,1003,1),
SDO_ORDINATE_ARRAY(-51.427259,-20.547785,-51.575114,-22.289193,-49.094429,-22.387763,-49.028716,-20.457420*,-51.427259,-20.547785*))
will validate.
Try it and see if your results are as expected.
Luc

No geometry validation on insert ?

Hi!
How come Oracle let me insert a non-closed polygon in an spatial-indexed table ? When I run SDO_GEOM.VALIDATE_GEOMETRY() I get the right error code (ORA-13348 polygon boundary is not closed) but I really CAN insert it !!!
Here's the polygon i've inserted. This is really just example 2.3.3, but modified to be a polygon instead of a line.
INSERT INTO cola_markets VALUES(
11,
'compound_line_string',
MDSYS.SDO_GEOMETRY(
2003,
NULL,
NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1,1005,2, 1,2,1, 3,2,2),
MDSYS.SDO_ORDINATE_ARRAY(10,10, 10,14, 6,10, 14,10)
Is it the programmer's responsability to write his own trigger to validate the geometry that is inserted ? I dont mind doing it, but I still think there's something weird going on !
Thank you!
Mathieu Gauthier
Development Team
JCMB Technology Inc

Oracle Spatial does not do geometry validation on insert, as you've found. The reason for this is that some people require geometry loading to go as fast as possible, and having a trigger on every insert would slow things down.
You can create a trigger to do the validation as you've described, if you need it.

ORA-13349: polygon boundary crosses itself

Similar Messages

Maybe you are looking for