SDO_UTIL.PREPARE_FOR_TTS

I'm using this procedure as documented prior to exporting my metadata in preparation of transporting a tablespace to another database. I noticed that after this procedure is run, there is an addition parameter listed in the parameters column of ALL_INDEXES: TTS_TABLE=SDO_INDEX_TTS_METADATA$
If I run this procedure multiple times, as if I were going to transport this tablespace to yet another database, it placed yet another TTS_TABLE=SDO_INDEX_TTS_METADATA$ into the parameters column.
Does anyone out there know if this is a problem. Should I open a TAR on this problem.
I will be doing this at least 5 times (setting of 5 replica's of a master site) prior to turning on Advanced Replication.

Hi Paul,
I'm looking forward to hearing you work the term "fancy hat" into an explanation of this behavior.
I get the same behavior on 11.2.0.2. Tsk tsk on you for not mentioning your version. Back on 10.2.0.4 the same select statements yield:
ORA-06531: Reference to uninitialized collection
ORA-06512: at "MDSYS.SDO_UTIL", line 344
So the only nuance I can think of, which isn't really a nuance at all, is that getnumvertices isn't allowed for point types.
Matt

Similar Messages

SDO_UTIL.PREPARE_FOR_TTS and Partitioned Indexes

Does this procedure work with partitioned indexes?
After executing this procedure on tablespace that contains the first partition of the partition index, the table SDO_INDEX_TTS_METADATA$ is empty. In addition, I can only run this procedure once, it fails for each subsequent tablespace which has a partition.
When I execute the procedure on a tablespace with a non partitioned index the SDO_INDEX_TTS_METADATA$ table is populated.

Thanks Dear ,
for your immediate reply .....
As u suggest I have tried all the following combitation but still it does not work;
SDO_UTIL.INITIALIZE_INDEX*ES*FORTTS;
SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS;
SDO_UTIL.INITIALIZE_INDEX_FOR_TTS;
it gives same error....
Thanks & Regards
Chandrakishore Bankhede

Errors in sdo_util on 12c

I have installed spatial on an Oracle 12C database and I am receiving the error below when using sdo_util.to_wktgeometry. Some of the other sdo_util functions work as expected. I checked the class files and they are all valid. Has anyone else encountered this error.
ORA-29531: no method structToWktJS in class oracle/spatial/util/Adapters
ORA-06512: at "MDSYS.SDO_JAVA_STP", line 350
ORA-06512: at "MDSYS.SDO_UTIL", line 2813
ORA-06512: at "MDSYS.SDO_UTIL", line 2836
29531. 00000 - "no method %s in class %s"
*Cause:    An attempt was made to execute a non-existent method in a
           Java class.
*Action:   Adjust the call or create the specified method.

I am not getting any error, as shown below, using a few excerpts from the online documentation. Can you run the same or similar script without error? Can you post a run of a test case that does produce the error for you?
SCOTT@orcl12c> set long 2000;
SCOTT@orcl12c> SELECT banner FROM v$version;
BANNER
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
PL/SQL Release 12.1.0.1.0 - Production
CORE    12.1.0.1.0    Production
TNS for 64-bit Windows: Version 12.1.0.1.0 - Production
NLSRTL Version 12.1.0.1.0 - Production
5 rows selected.
SCOTT@orcl12c> CREATE TABLE cola_markets
2    (mkt_id    NUMBER PRIMARY KEY,
3      name    VARCHAR2(32),
4      shape    SDO_GEOMETRY);
Table created.
SCOTT@orcl12c> INSERT INTO cola_markets VALUES
2    (2, 'cola_b',
3      SDO_GEOMETRY
4        (2003, NULL, NULL,
5         SDO_ELEM_INFO_ARRAY (1,1003,1),
6         SDO_ORDINATE_ARRAY(5,1, 8,1, 8,6, 5,7, 5,1)));
1 row created.
SCOTT@orcl12c> INSERT INTO user_sdo_geom_metadata (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES
2    ('cola_markets', 'shape',
3      SDO_DIM_ARRAY
4        (SDO_DIM_ELEMENT('X', 0, 20, 0.005),
5         SDO_DIM_ELEMENT('Y', 0, 20, 0.005)),
6      NULL);
1 row created.
SCOTT@orcl12c> CREATE INDEX cola_spatial_idx ON cola_markets(shape) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
Index created.
SCOTT@orcl12c> SELECT SDO_UTIL.TO_WKTGEOMETRY (shape) FROM cola_markets WHERE name = 'cola_b';
SDO_UTIL.TO_WKTGEOMETRY(SHAPE)
POLYGON ((5.0 1.0, 8.0 1.0, 8.0 6.0, 5.0 7.0, 5.0 1.0))
1 row selected.

Using SDO_UTIL.GETVERTICES() together with functions

Hi again
I'm having a problem here in my spatial database I trying to use the function
TABLE(SDO_UTIL.GETVERTICES(c.shape)) in order to get the coordinates of shapes. But I need to first extract data from spatial functions like the centroid function. How do I get these 2 functions to work together.
thanks very much
Thomaz

Hi Thomaz,
Maybe I missed your point, but what about the following:
select t.y, t.x, t.id
from your_geom_table,
table(
sdo_util.GETVERTICES(
sdo_geom.sdo_centroid(geom, 0.005)
) t
regards,
Thomas

SDO_UTIL.FROM_WKTGEOMETRY doing some odd math

Hello,
Can anyone explain simply what's going on here with the WKT transformation? Why are the coordinates snapping to some kind of grid? How do I control this and where is this documented? Why would I want my coordinates to go from 14 digits of precision to 38 digits? I get the same results with the straightforward use of FROM_WKTGEOMETRY where the fucntion
{color:#008000}SELECT
MDSYS.SDO_GEOMETRY(
'GEOMETRYCOLLECTION(POLYGON((
-76.57573699951172 38.91845748333781,
-76.57571822404861 38.91807558545071,
-76.57517105340957 38.918440788391166,
-76.57573699951172 38.91845748333781
',8265)
from dual{color}
results in
{color:#008000}SDO_GEOMETRY
2004,
8265,
NULL,
SDO_ELEM_INFO_ARRAY
1,
1003,
1
SDO_ORDINATE_ARRAY
-76.57573699951171875,
38.91845748333781074279613676480948925018,
-76.575718224048614501953125,
38.91807558545070833133650012314319610596,
-76.575171053409576416015625,
38.9184407883911660519515862688422203064,
-76.57573699951171875,
38.91845748333781074279613676480948925018
{color:#000000}Thanks,
Paul{color}
{color}

Hello Siva,
Thanks for answering my question, I appreciate your time. I would argue that the primary problem here is the utter lack of any documentation concerning this issue by Oracle. I am glad that Oracle will correct this in "the next version". Does that include 10g or just 11g? Does that mean that these utilities will be converted from java into the core database or just rewritten better in java?
My organization serves basically as data middlemen and processors. We take data from various sources and then host it for services and analysis by our clients. The expectation is that we are not changing the source data beyond our documented processes (reprojection, etc). It not uncommon for a client to compare our output with the original data to see if we are following their specifications. As GIS professionals we value our ability to pass this scrutiny. I would argue that this java number jumble creates the impression of sloppiness. I do understand that this is meaningless in spatial terms.
Lets look at my triangle again:
Original valid WKT triangle from source
{color:#008000}-76.57418668270113{color} {color:#000080}38.91891450597657{color}
{color:#008000}-76.57484114170074{color} {color:#000080}38.91758725401061{color}
{color:#008000}-76.57661139965057{color} {color:#000080}38.91881851059802{color}
{color:#008000}-76.57418668270113{color} {color:#000080}38.91891450597657
{color}
After SDO_GEOMETRY conversion (results in invalid geometry)
{color:#008000}-76.57418668270112505069846520200371742249{color} {color:#000080}38.91891450597657353682734537869691848755{color}
{color:#008000}-76.57484114170074462890625{color} {color:#000080}38.91758725401061269622005056589841842651{color}
{color:#008000}-76.57661139965057373046875{color} {color:#000080}38.91881851059802244208185584284365177155{color}
{color:#008000}-76.57418668270112505069846520200371742249{color} {color:#000080}38.91891450597657353682734537869691848755
{color}
After correction via SDO_UTIL.RECTIFY_GEOMETRY
{color:#008000}-76.5741866827011{color} {color:#000080}38.9189145059766{color}
{color:#008000}-76.5766113996506{color} {color:#000080}38.918818510598{color}
{color:#008000}-76.5748411417007{color} {color:#000080}38.9175872540106{color}
{color:#008000}-76.5741866827011{color} {color:#000080}38.9189145059766
{color}
{color:#000000}So if we institute a test and autocorrection of badly converted geometries:
{color}<ul><li>geometries which convert properly get nutty precision added (out to 38 places in many case)</li>
<li>geometries which fail conversion and then are rectified actually lose precision</li>
</ul>
The issue here is explaining and documenting this so that clients are confident that we know what we are doing. If I pass someone two geometries with 14 digits of precision and they send me back one with 38 digits and a second with 12 digits I might wonder what the heck they are doing to my data. Is there any place where these issues are documented in depth by Oracle?
Thanks again for your time,
Paul

SDO_UTIL.TO_CLOB odd head scratcher

Hi folks,
I'll try to submit this to support but thought I should log it here in case anyone is interested.
Using Oracle 11.2.0.3.
I am still occasionally poking at the uber SDO_GEOMETRY issue (see Re: upgrading to uber SDO_GEOMETRY, looking for comments Anyhow one of the deal breakers has been the hassles to move geometries back and forth between uber-installed instances and regular instances. With datapump off the table, its kind of a bummer. Anyhow, I noticed that for reasons I cannot explain (any takers?) the following works to move SDO_GEOMETRY across a database link between uber and regular instances:
INSERT INTO local_table (shape)
SELECT
SDO_UTIL.FROM_CLOB(SDO_UTIL.TO_CLOB(a.shape))
FROM
remote_table@remote_instance a;I don't really understand why that works. But it does. Obviously over-sized geometries will fail if you try to move them to a regular instance. Performance is not too bad overall considering the deserialization and serialization taking place. I have not looked into what is occurring on what instance.
The only problem I found is a weird bug I think with the SDO_UTIL.FROM_CLOB for geometries with crazy precision.
SELECT
SDO_UTIL.TO_CLOB(SDO_GEOMETRY(2001,8265,NULL,SDO_ELEM_INFO_ARRAY(1,1,1),SDO_ORDINATE_ARRAY(-106.496121500000000992258719634264707565,43.01151182000000261496097664348781108856)))
FROM DUAL;When I plug the results into FROM_CLOB, I get
ORA-06502: PL/SQL: numeric or value error
ORA-06512: at "MDSYS.SDO_UTIL", line 3152
SELECT
SDO_UTIL.FROM_CLOB('2001||8265||NULL|NULL|NULL||1|1|1||-106.496121500000000992258719634264707565|43.01151182000000261496097664348781108856||')
FROM DUAL;Some kind of odd math bug I think. If I knock off 12 digits, then it works fine.
Cheers,
Paul

Paul,
As you know full well no one can measure the earth to the precision of the numbers of your 8265 SRIDed SDO_GEOMETRY.
Interestingly, the longitude in the example can't be represented in an Oracle NUMBER without loss of "precision" as can be seen following:
SELECT length('496121500000000992258719634264707565') as longPrecLength
FROM DUAL;
-- Results
LONGPRECLENGTH
36
-- The max precision for this longitude is 35.....
SELECT cast(-106.496121500000000992258719634264707565 as number(38,35)) as longitude
FROM DUAL;
-- Result
LONGITUDE
-106.49612150000000099225871963426470757
-- Trying to define 36 decimal digits throws an error
SELECT cast(-106.496121500000000992258719634264707565 as number(38,36)) as longitude
FROM DUAL;
-- Result
QL Error: ORA-01438: value larger than specified precision allowed for this column
01438. 00000 - "value larger than specified precision allowed for this column"
*Cause: When inserting or updating records, a numeric value was entered
that exceeded the precision defined for the column.
-- Try binary_double
SELECT cast(-106.496121500000000992258719634264707565 as binary_double) as longitude
FROM DUAL;
-- Results
LONGITUDE
-106.4961215I have no idea what 1/10^36 decimal degrees of longitude or latitude is in meters but it ain't measurable via any GPS/Surveying method I know! Perhaps CERN can help!
Thanks for the reference to my new article. It has been sitting on my computer hard disk now for well over 6 months. I often wonder how many people actually read my articles (just like I wonder if anyone uses GeoRaptor)!
To be honest, when I first started using Oracle SDO_GEOMETRY I met end users who constantly asked why the number of decimal digits was greater than they expected. So, 10+ years ago I wrote a coordinate rounding function. (Perception management?) I never thought about the saving of space (most say it doesn't matter today due to large, cheap, fast disks, and fast networks) nor about performance aspects. I think my article points the way forward for others to investigate and, I hope, share* their results and experiences.
regards
Simon

SDO_UTIL.FROM_KMLGEOMETRY and Java

Hello,
I'm trying to write a Java program that will parse a KML file, convert KML geometry coordinates into SDO_GEOMETRY coordinates, then insert appropriate records into the database.
I'm stuck on the 2nd part, converting KML into SDO_GEOMETRY. Here's my code:
private static void getSDOGeom(Connection con, String [] geomKML, JGeometry [] geomSDO) throws Exception {
CallableStatement s = con.prepareCall("{? = call SDO_UTIL.FROM_KMLGEOMETRY(?)}");
ResultSet rs = null;
for (int i = 0; i < geomKML.length; i++) {
s.registerOutParameter(1, JGeometry.GTYPE_POINT);
s.setString(2, "\'<Point><coordinates>" + geomKML[i] + "</coordinates></Point>\'");
rs = s.executeQuery();
geomSDO[i] = (JGeometry) s.getObject(1);
Here's my error message:
java.sql.SQLException: ORA-06550: line 1, column 13:
PLS-00382: expression is of wrong type
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
-then stack trace saying which line of my program caused the error - the executeQuery line.
It looks like my problem is from the JGeometry.GTYPE_POINT in the registerOutParameter method call. I've tried a number of items here to no effect. The geomKML array contains KML coordinates stripped from a KML/XML file, I had to put the <Point> and <coordinates> tags in because the XML parser isn't including them. I've converted coordinates directly in the database, so I know the KML input is correct. The geomSDO array is of the proper size, but is null. I'm not sure what I'm doing wrong and can't find anything like this in the forums. A DB guy here at work did some searching and said I should use JGeometry, but he's not sure why it isn't working either.
Anyone have any ideas?

Thanks for the help... my problem was the ResultSet. I didn't noticed until your most recent code example that you weren't using it, but were acting upon the CallableStatement directly for the getObject method. I was using CallableStatement wrong. I think I saw an example somewhere with the CallableStatement and the ResultSet both being used. Thanks for the STRUCT code too, I saw something about that in a forum post, but wasn't sure what it was doing... but my code doesn't work without it. I did have to track down the jar libraries and imports for STRUCT and OracleType, but that wasn't too difficult.
As to your other points, there is a bit of a misunderstanding because of the limited information I posted - I should have been more clear. This method is one method in a larger program - my database connection was already set up and working, though I thank you for being proactive and including it just in case. I was also printing out my KML coordinates to check to make sure they were ok and had already tested them in the database with a written procedure and knew they were working. The "\" was an escape character for a single quote, which I thought I needed to include because the input to FROM_KMLGEOMETRY needed to be surrounded by single quotes in the database testing. Your initial response also included them. I found that by removing them, my error went away - in fact, I didn't even notice they were there at first. Finally, the JGeometry array does indeed work and the array list isn't needed. I was hoping the array would work as it's more light weight and I'm able to pass the object by reference instead of by value, decreasing the overhead of my code. I was delighted to find that it did work once I fixed the ResultSet issue as previously mentioned. It is initialized elsewhere in my code to be the same size as the array with the KML geometry.
I don't add the comments above to rebuff you. I'm very glad to you provided extremely complete answers. You've helped me before. I add them in case someone else stumbles upon this thread in hopes that the information will be useful to them.
For posterity, Final code with related imports:
import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.DriverManager;
import oracle.spatial.geometry.JGeometry;
import oracle.jdbc.OracleTypes;
import oracle.sql.STRUCT;
private static void getSDOGeom(Connection con, String [] geomKML, JGeometry [] geomSDO) throws Exception {
CallableStatement s = con.prepareCall("{? = call SDO_UTIL.FROM_KMLGEOMETRY(?)}");
STRUCT geomSDO_STRUCT = null;
for (int i = 0; i < geomKML.length; i++) {
s.registerOutParameter(1, OracleTypes.STRUCT, "MDSYS.SDO_GEOMETRY");
// You could also add extrude, tessellate and altitudeMode
s.setString(2, "<Point><extrude>0</extrude><tessellate>0</tessellate>" +
"<altitudeMode>clampToGround</altitudeMode><coordinates>" + geomKML[i] +
"</coordinates><extrude>0</extrude><tessellate>0</tessellate>" +
"<altitudeMode>clampToGround</altitudeMode></Point>");
s.executeQuery();
geomSDO_STRUCT = (STRUCT) s.getObject(1);
geomSDO[i] = JGeometry.load(geomSDO_STRUCT);
s.close();
The libraries that I needed to add to the project at compile time (already had the jdbc driver loaded for runtime) are
sdoapi.jar (this is for JGeometry and other spatial related items) located <oracle home>/md/jlib/
ojdbc6.jar (this is where the STRUCT and OracleTypes are found) located <oracle home>/jdbc/lib/
Thanks,
Edit:
If you're trying to write SDO_GEOMETRY to a database, this thread will help.
ORA-00939: too many arguments for function
Edited by: J-rd-n on Sep 14, 2010 11:44 AM

SDO_UTIL.FROM_WKBGEOMETRY function

Hi there.
I have been struggling to convert WKB(Blobs) to SDO_GEOMETRY.
If I understand correctly there is some SDO functions that doesn't`t work in Oracle XE or should I rather say it has a differant syntax in XE than enterprise.
My problem is that I want to transform WKR(Blobs) to SDO_Geometry.
I tried the following procedure but to no avail.
CREATE OR REPLACE PROCEDURE IMIS_MAP_GEO.BLOB_TO_SDO
IS
CURSOR TCURS IS
SELECT SEQ,
SDO_GEOM.VALIDATE_GEOMETRY(SDO_UTIL.SIMPLIFY((SDO_UTIL.FROM_WKBGEOMETRY(A.GEOMETRY)),0.00000005),0.000001) AS "VALIDATION",
SDO_UTIL.SIMPLIFY((SDO_UTIL.FROM_WKBGEOMETRY(A.GEOMETRY)),0.00000005) AS GEOM
FROM LAND_PARCELS_REGD_ERVEN A
WHERE GEOMETRY IS NOT NULL;
BEGIN
FOR TROW IN TCURS LOOP
IF TROW."VALIDATION" = 'TRUE'
THEN
UPDATE LAND_PARCELS_REGD_ERVEN A
SET A.GEOMETRY_TEST = TROW.GEOM
WHERE A.SEQ = TROW.SEQ;
ELSE
DBMS_OUTPUT.PUT_LINE('GEOMETRY NOT VALID WITH ORA-' ||TROW."VALIDATION"|| ' ON SEQ'||TROW.SEQ);
END IF;
END LOOP;
END;
The values it returns is an blank GEOMETRY.
Any help would be appreciated.
Thanks in advance

Hi Siva.
Thanks for the reply.
Do you know of any workarounds?or is the only way to use Enterprise?
Thanks in advance,

SDO_UTIL.TO_WKTGEOMETRY crashes when processing collection

Hi folks,
Another weird WKT thing. I have what I think is a very reasonable collection comprising one polygon with a bunch of holes and one linestring. SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT says the geometry is valid. However when I attempt to convert the geometry to WKT, I get a generic java runtime error on 11.1.0.6 and a specific error on 10.2.0.4 of
ORA-29532: Java call terminated by uncaught Java exception: java.lang.RuntimeException: oracle.spatial.util.GeometryExceptionWithContext: Unsupported collection element: elemInfo type 2003
ORA-06512: at "MDSYS.SDO_UTIL", line 2495
ORA-06512: at "MDSYS.SDO_UTIL", line 2517
ORA-06512: at line 561
Why would a 2003 polygon not be supported in a collection?
Thanks!
Paul
Here is the procedure with the troublesome geometry:
DECLARE
sdo_example SDO_GEOMETRY;
str_validate VARCHAR2(16);
clb_wkt CLOB;
BEGIN
sdo_example := SDO_GEOMETRY
2004,
8265,
NULL,
SDO_ELEM_INFO_ARRAY
1,
1003,
1,
415,
2003,
1,
433,
2003,
1,
451,
2003,
1,
471,
2003,
1,
485,
2003,
1,
499,
2,
1
SDO_ORDINATE_ARRAY
-118.651784895553,
40.0356302970485,
-118.651814679249,
40.0354702026973,
-118.652439578073,
40.0350811147507,
-118.652528705644,
40.0347836130663,
-118.652707072544,
40.034600496421,
-118.652736912119,
40.034394580999,
-118.652439075159,
40.0340514258819,
-118.652885327685,
40.0333420933535,
-118.653688593409,
40.0326556154812,
-118.654491691494,
40.0317171775986,
-118.654967504199,
40.0308019855276,
-118.655086583104,
40.0308019855276,
-118.656514915289,
40.0300235861168,
-118.656574426802,
40.0297491067266,
-118.65636588505,
40.0294288062655,
-118.656514524134,
40.0290855952691,
-118.657198710953,
40.0283074752551,
-118.65853679798,
40.0261563994965,
-118.659012722444,
40.0254927762802,
-118.661333112647,
40.0238219276958,
-118.663593488424,
40.0215789862781,
-118.664129092038,
40.0215101987925,
-118.664575288685,
40.0213041157324,
-118.66549707452,
40.0202055834987,
-118.666181317218,
40.0197019987542,
-118.667371379835,
40.0192669220987,
-118.668144917742,
40.0188317895637,
-118.668620674568,
40.0183512271134,
-118.668620618688,
40.0181454234501,
-118.668055175498,
40.0180769153613,
-118.668054896102,
40.017596520549,
-118.667727275445,
40.0172533095526,
-118.66769737999,
40.0170245953538,
-118.668143520758,
40.0165439770242,
-118.668291992203,
40.0162236206838,
-118.66930368792,
40.0160858780745,
-118.669392703732,
40.0158800185318,
-118.668112675354,
40.0149196200629,
-118.668052884445,
40.0146449171552,
-118.668469520913,
40.0145990960844,
-118.669064915437,
40.0150336139464,
-118.669421984514,
40.015124920812,
-118.669511223843,
40.0150104798936,
-118.670104774349,
40.0126766227658,
-118.670162777119,
40.0103200227407,
-118.670281408989,
40.0099539012088,
-118.670727382119,
40.0093359873047,
-118.670786614235,
40.009061284397,
-118.670547897631,
40.0079631991981,
-118.670784714337,
40.006201490783,
-118.670516381675,
40.0054465048218,
-118.669949876778,
40.0035249255729,
-118.669830797873,
40.0032275915266,
-118.669681599996,
40.0025640800691,
-118.669473225882,
40.0024956278596,
-118.668938013423,
40.0028619170295,
-118.659718981608,
40.0101405941328,
-118.659719875677,
40.0119251013246,
-118.659185501409,
40.0141674839488,
-118.658234378912,
40.0164327771084,
-118.657877924509,
40.0177370012467,
-118.6580276253,
40.0193843246228,
-118.657968504943,
40.0204825215805,
-118.657849817193,
40.0209172070806,
-118.657492915755,
40.0213978254102,
-118.65677900112,
40.0220157951937,
-118.654458387399,
40.0235950016364,
-118.65377420058,
40.0243274123383,
-118.651543496741,
40.0273708813912,
-118.650472401271,
40.0282404759088,
-118.650145283528,
40.0289040991251,
-118.650324097463,
40.0294988789763,
-118.651723316505,
40.0304595009627,
-118.651574677421,
40.0312144869239,
-118.651098976475,
40.0321756118245,
-118.649462214297,
40.0327479840545,
-118.648896826986,
40.033091195051,
-118.648688508752,
40.0333200768878,
-118.648480190517,
40.0333200768878,
-118.648212193132,
40.0330227987208,
-118.647914579689,
40.0330686197917,
-118.647617022125,
40.033274591093,
-118.646278488063,
40.0358144754015,
-118.6440169947,
40.0384001807809,
-118.643243289155,
40.0389950723909,
-118.642469527731,
40.0393157081281,
-118.642231314042,
40.0392926858339,
-118.642231314042,
40.0393842720962,
-118.640564600529,
40.0399564766882,
-118.640118124485,
40.0401854144044,
-118.639016910043,
40.0412151032731,
-118.638570601637,
40.0417641738123,
-118.63827332347,
40.0432286040605,
-118.637916198514,
40.0437548758229,
-118.637410099199,
40.0441896172024,
-118.636160022155,
40.0447846764504,
-118.634046497323,
40.0456771256241,
-118.632826092216,
40.0465467201417,
-118.632826203975,
40.0466611051808,
-118.632022379458,
40.0472559967907,
-118.630265979582,
40.0479881839752,
-118.630027821772,
40.0481026807729,
-118.629611073545,
40.0481026807729,
-118.628866704661,
40.0479653851985,
-118.62776532258,
40.0481943229146,
-118.627021009576,
40.0484688023048,
-118.625979027249,
40.0484460035281,
-118.624460673423,
40.0485603885672,
-118.621632619283,
40.0494069049113,
-118.620233176724,
40.0496356749894,
-118.619578326566,
40.0496128203333,
-118.618833901803,
40.049429703688,
-118.61627362153,
40.0496584178867,
-118.615350773988,
40.0496584178867,
-118.614755323584,
40.0494066813939,
-118.614338519478,
40.0494753012414,
-118.613891875796,
40.049772691167,
-118.613326320847,
40.0498641097913,
-118.611926990047,
40.0495206752774,
-118.610766096453,
40.0490173140504,
-118.60969438631,
40.0483994001463,
-118.608860778097,
40.0484679082351,
-118.60752090293,
40.0495201723632,
-118.607133714881,
40.050275102445,
-118.606835822041,
40.0512360038282,
-118.60647830593,
40.0517850743673,
-118.606299715513,
40.0519224258211,
-118.605852792434,
40.0529976004846,
-118.605554899594,
40.053295102169,
-118.605376085659,
40.0536839107189,
-118.605346301963,
40.0542788023289,
-118.604482295381,
40.0560176002086,
-118.604303593205,
40.0567040222015,
-118.604303313808,
40.0574818069394,
-118.604660494643,
40.0579166041982,
-118.604660327005,
40.058854595046,
-118.605047179777,
40.0594495984146,
-118.604451282339,
40.0607078897234,
-118.603825880601,
40.0613026136953,
-118.603855496659,
40.0614856744613,
-118.604867974687,
40.0615545178263,
-118.605284890552,
40.0615088085141,
-118.606416503364,
40.0611199999642,
-118.607220495519,
40.0610744024108,
-118.60990041349,
40.0612347761588,
-118.610674510191,
40.0614178928041,
-118.611716604276,
40.0618528018216,
-118.612222815351,
40.0618986228924,
-118.613056591202,
40.0616927074704,
-118.614783710296,
40.0615098143425,
-118.615438672213,
40.0617845172502,
-118.615706613718,
40.0618073160269,
-118.617969727583,
40.0614871832039,
-118.618743880163,
40.0611897932782,
-118.618982093852,
40.0610295871684,
-118.619011877548,
40.0609152021293,
-118.619518088622,
40.0606406109804,
-118.620351976232,
40.0605719911328,
-118.621126072932,
40.060709398466,
-118.621870385937,
40.0605721028915,
-118.62300188699,
40.0598628821219,
-118.623537993519,
40.0596112015084,
-118.624758678022,
40.0590849856253,
-118.625979418404,
40.0586961211961,
-118.62770642574,
40.0584671834799,
-118.629195219387,
40.0580552967565,
-118.629731102399,
40.057803616143,
-118.630862379934,
40.0570256078878,
-118.631606692939,
40.0569340216254,
-118.631844906628,
40.0568424912424,
-118.632083120317,
40.0563848952069,
-118.633392876511,
40.0551263803807,
-118.634524377564,
40.0547374041927,
-118.635238906872,
40.0542339870864,
-118.636399688707,
40.0532500075297,
-118.637024811048,
40.0524262899623,
-118.637649709872,
40.0510764123912,
-118.638215208941,
40.0504584984871,
-118.639554804711,
40.049337223356,
-118.640953688476,
40.0487650746434,
-118.641727673418,
40.0483530761613,
-118.642293116608,
40.0476437995123,
-118.643275475663,
40.0472547115656,
-118.644108916238,
40.0471173042324,
-118.644257778839,
40.0471630135445,
-118.644645022767,
40.0475518779738,
-118.644883124698,
40.0475975872859,
-118.645151010324,
40.0475060010236,
-118.645508191159,
40.0470254944527,
-118.646400975609,
40.0460872242081,
-118.646847004618,
40.0447602012931,
-118.647352992175,
40.0444626996087,
-118.647412391929,
40.0438448974633,
-118.647322984961,
40.043661780818,
-118.647322482047,
40.0423120150056,
-118.647590200035,
40.0416026824772,
-118.647619816093,
40.0412823820162,
-118.647351874588,
40.0412595273601,
-118.64669702443,
40.0413968788139,
-118.646518489892,
40.0412826055336,
-118.646518378133,
40.0410309249201,
-118.647321811495,
40.0401613862819,
-118.647381323007,
40.0399783255159,
-118.64827388394,
40.0389028155763,
-118.650029501505,
40.0371636265411,
-118.650922006558,
40.0361338817929,
-118.651784895553,
40.0356302970485,
-118.627229495448,
40.0502077119433,
-118.627289006961,
40.0499102102589,
-118.628033319965,
40.0496585855248,
-118.628241694079,
40.0494755247588,
-118.628539419281,
40.049338173305,
-118.628747681635,
40.0494526142234,
-118.62877757709,
40.0498414786527,
-118.628271477775,
40.050138980337,
-118.627229495448,
40.0502077119433,
-118.643958209619,
40.040642395767,
-118.643719884171,
40.0403907151535,
-118.643719772412,
40.0399331749973,
-118.643957818463,
40.0396584720897,
-118.644315111057,
40.0395669975861,
-118.644464085417,
40.0397270919372,
-118.644285606758,
40.0405508095047,
-118.644166583732,
40.0406422840083,
-118.643958209619,
40.040642395767,
-118.648868216756,
40.0361571276045,
-118.648897888694,
40.0359512121825,
-118.649433604067,
40.035630688204,
-118.649522787517,
40.0354476833174,
-118.649701210297,
40.0353331865196,
-118.649909696169,
40.0354476833174,
-118.649820512719,
40.0358138048493,
-118.649612306243,
40.0360425749274,
-118.649255125408,
40.0362027810372,
-118.648868216756,
40.0361571276045,
-118.645177888293,
40.0381025114585,
-118.64520761611,
40.0378051215328,
-118.645505117795,
40.037370324274,
-118.645892026446,
40.0372329728202,
-118.645743387363,
40.0380109251961,
-118.645505285433,
40.0381254219939,
-118.645177888293,
40.0381025114585,
-118.61558870828,
40.0512142108799,
-118.615380390046,
40.050848089348,
-118.615648275672,
40.0504592249187,
-118.615886489361,
40.0504363143833,
-118.616005624145,
40.0505965204932,
-118.615975672811,
40.0511913003444,
-118.61558870828,
40.0512142108799,
-83.088467803182,
32.7318730307068,
-83.0882509912858,
32.7317356233736,
-83.08719420093,
32.7316896346647,
-83.0851351584685,
32.7310939048644,
-83.0836449678378,
32.7305898172058,
-83.0826968069475,
32.7299482663346,
-83.0813963267259,
32.7294212681406,
-83.0801230038707,
32.729008878503,
-83.0795269387943,
32.7289858562089,
-83.0794185328462,
32.7291002971273
str_validate := SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(sdo_example,0.5);
dbms_output.put_line(str_validate);
clb_wkt := SDO_UTIL.TO_WKTGEOMETRY(sdo_example);
END;

Hi Siva,
That makes sense that Oracle is using an older version of the WKT specification. But when I look at the documentation on these WKT functions, there is no mention of the specification used. For example, the GML converter specifies GML 2.0 right in the documentation. Do you know the version of WKT is currently supported by Oracle? Where is this documented? I should also note that it doesn't seem to mention anywhere that Oracle WKT functions are restricted to two-dimensional geometries only. Is this mainly a case of really poor documentation?
Anyhow, on page 21 of the current WKT specification 1.2, it states that GEOMETRYCOLLECTIONs:
A GeometryCollection is a geometric object that is a collection of some number of geometric objects.
All the elements in a GeometryCollection shall be in the same Spatial Reference System. This is also the Spatial
Reference System for the GeometryCollection.
GeometryCollection places no other constraints on its elements. Subclasses of GeometryCollection may restrict
membership based on dimension and may also place other constraints on the degree of spatial overlap between
elements.
Cheers and thanks for your help!
Paul

SDO_UTIL.AFFINETRANSFORMS

I have the following parameters for 2D affine transformation:
Two translation:
tx=2754.3661 and ty = -237.0731
and rotation in radians: -.001016214498072193185827329
Is this specification correct:
SDO_UTIL.TO_WKTGEOMETRY(SDO_UTIL.AffineTransforms (
geometry =>myGeometry,
translation => 'TRUE', tx => 2754.3661, ty => -237.0731, tz => 0.0,
scaling => 'FALSE', psc1 => NULL, sx => 0.0, sy => 0.0, sz => 0.0,
rotation => 'TRUE',
p1 => MDSYS.SDO_GEOMETRY(2001, NULL, MDSYS.SDO_POINT_TYPE(0, 0, NULL), NULL, NULL), line1 => NULL,
angle => -.001016214498072193185827329,
dir => -1,
shearing => 'FALSE', shxy => 0.0, shyx => 0.0, shxz => 0.0, shzx => 0.0, shyz => 0.0, shzy => 0.0,
reflection => 'FALSE', pref => NULL, lineR => NULL, dirR => -1, planeR => 'FALSE', n => NULL, bigD => NULL
Thanks.
BTW, in PostGIS it works correctly:
ST_Affine (myGeometry, cos(rotation), sin(rotation), -sin(rotation), cos(rotation), tx, ty));
Edited by: qwe14450 on 13-Jul-2012 15:03

Qwe (for Qwe must be your name),
It is tricky to get this function to work as the error message thrown when you get the parameters wrong is useless.
ORA-29532: Java call terminated by uncaught Java exception: java.lang.Exception: Invalid parameter for affine transform
ORA-06512: at "MDSYS.SDO_UTIL", line 266
29532. 00000 - "Java call terminated by uncaught Java exception: %s"
*Cause:    A Java exception or error was signaled and could not be
           resolved by the Java code.
*Action:   Modify Java code, if this behavior is not intended.The thing I kept yelling at the screen was "what parameter is invalid"!!!!!
But I got this to work:
select mdsys.sdo_geometry(2002,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(2.0,2.0,2.0,4.0,8.0,4.0,12.0,4.0,12.0,10.0,8.0,10.0,5.0,14.0)) as geomm from dual;
select SDO_UTIL.AffineTransforms (
        geometry => mdsys.sdo_geometry(2002,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(2.0,2.0,2.0,4.0,8.0,4.0,12.0,4.0,12.0,10.0,8.0,10.0,5.0,14.0)),
        translation => 'TRUE',
          tx => 2754.3661,
          ty => -237.0731,
          tz => 0.0,
        rotation => 'TRUE',
          p1 => MDSYS.SDO_GEOMETRY(2001, NULL, MDSYS.SDO_POINT_TYPE(0, 0, NULL), NULL, NULL),
          angle => -0.001016214498072193185827329, /*cogo.radians(45),*/
          dir => -1,
          line1 => NULL,
        scaling    => 'FALSE', psc1 => NULL, sx => 0.0, sy => 0.0, sz => 0.0,
        shearing   => 'FALSE', shxy => 0.0, shyx => 0.0, shxz => 0.0, shzx => 0.0, shyz => 0.0, shzy => 0.0,
        reflection => 'FALSE', pref => NULL, lineR => NULL, dirR => -1,
        planeR     => 'FALSE', n => null, bigD => null
from dual;
-- Result
SDO_GEOMETRY(2002,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(2756.36813139595,-235.075133461338, 2756.3701638246,-233.07513449403, 2762.37016072653,-233.081231779969, 2766.37015866114,-233.085296637262, 2766.37625594708,-227.085299735337, 2762.37625801246,-227.081234878044, 2759.38032441879,-223.078188300459))Note the reference to /*cogo.radians(45),*/.... I have a function Radians in a package called Cogo that I use to convert from degrees (360) to radians:
Create   Function radians(p_degrees in number)
    Return number
Is
     c_PI NUMBER(16,14) := 3.14159265358979;
Begin
    Return p_degrees * (c_PI / 180.0);
End radians;
/If this helps, please award points.
regards
Simon

SDO_UTIL.APPEND strips away LRS dimensions

Hi folks,
Checking over the forum it seems I did note this issue in passing a year ago
https://community.oracle.com/message/11033886#11033886
But it came out to bite me today. It does seem true that I flog poor old SDO_UTIL.APPEND every-so-often and perhaps I should find other interests.
I am thinking this is probably a "feature" and a small blurb should be added to the documentation for the function. SDO_UTIL.APPEND simply says of itself, "Appends one geometry to another geometry to create a new geometry."
There is no mention of what types of geometries you should or should not feed to it.
However feeding LRS geometries to SDO_UTIL.APPEND is a bad idea (see below) as the function destroys the LRS dimension from the SDO_GTYPE producing a 3D geometry. I guess that I should be using SDO_LRS.CONCATENATE_GEOM_SEGMENTS though I am not interested in this case in merging the geometries, I just want to house them together in a multi-geometry. I think this is what SDO_UTIL.APPEND was meant for.
Assuming this is just a feature, perhaps Oracle could add a note on the SDO_UTIL.APPEND page that the function is not valid for LRS geometries? Or is this a bug?
Cheers,
Paul
ON 11GR2:
SELECT
SDO_UTIL.APPEND(
    SDO_GEOMETRY(3302,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(1,1,1, 2,2,2))
   ,SDO_GEOMETRY(3302,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(3,3,3, 4,4,4))
FROM dual;
RESULT:
SDO_GEOMETRY(3006,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1,7,2,1),SDO_ORDINATE_ARRAY(1,1,1,2,2,2,3,3,3,4,4,4))

Paul,
My take on append, is that it will just stuff the first and the second geometries together with no logic applied. So although your example result geometry just happens to work out, there is no logic given to the measure portion of the LRS. The measure can be a distance, say meters for Lat/Lon - or it can be some arbitrary scale such as the percentage of a city block going from 0 to 1. Since append would have no knowledge of how your two line stings are to be stuck together, you could easily wind up with:
SELECT
SDO_UTIL.APPEND(
    SDO_GEOMETRY(3302,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(3,3,3, 4,4,4)),
    SDO_GEOMETRY(3302,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(1,1,1, 2,2,2))
FROM dual;
RESULT:
SDO_GEOMETRY(3006,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1,7,2,1),SDO_ORDINATE_ARRAY(3,3,3,4,4,4,1,1,1,2,2,2))
...that of course is completely invalid as the measure is not progressing in order:
SELECT
SDO_LRS.VALIDATE_LRS_GEOMETRY(
   SDO_GEOMETRY(3306,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1,7,2,1),SDO_ORDINATE_ARRAY(3,3,3,4,4,4,1,1,1,2,2,2))
FROM
dual;
RESULT ON 11.2.0.4.2: 13335
ORA-13335 LRS segment is not defined
Cause: The given start or end measures are not defined, or some assigned measures in between are not in an ascending order.
Action: An LRS geometric segment is defined if its start and end measure are assigned (non-null). Any other measures assigned on the segment must be in an ascending order.
Bryan
PS - Yes, I agree on the error message - or more so, on checking for valid inputs to start with. However, I do get the idea that doing so on something that is called millions or billions of times in a row, can cause it to run slightly slower. All in all, I'd personally rather have validity checks that a routine that runs 2% faster and can give me invalid answers.

SDO_UTIL.FROM_WKTGEOMETRY seems ignorant of ring rotation

Hello,
Back with more WKT issues. The OGC WKT spec does not enforce any kind of ring rotation on its polygons. However Oracle SDO_GEOMETRY does. When SDO_UTIL.FROM_WKTGEOMETRY converts a WKT polygon it doesn't seem to correct the ring rotation - it just leaves the rings rotated exactly as in the WKT resulting in invalid SDO_GEOMETRY polygons. Wouldn't this be a bug? I can't find anywhere in the SDO_UTIL documentation where we are told to always runs RECTIFY_GEOMETRY after the conversion.
Simple Example:
{color:#008000}SELECT SDO_UTIL.VALIDATE_WKTGEOMETRY('
POLYGON((
-76.57418668270113 38.91891450597657,
-76.57484114170074 38.91758725401061,
-76.57661139965057 38.91881851059802,
-76.57418668270113 38.91891450597657
))') FROM dual
{color}
returns TRUE though ring is clockwise - okay for WKT.
But when we convert it to SDO_GEOMETRY, the ring is still clockwise and throws an error
{color:#008000}SELECT SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(
SDO_GEOMETRY('
POLYGON((
-76.57418668270113 38.91891450597657,
-76.57484114170074 38.91758725401061,
-76.57661139965057 38.91881851059802,
-76.57418668270113 38.91891450597657
))',8265),0.0001) FROM dual
{color}
returns {color:#ff0000}13367 [Element <1>] [Ring <1>]
{color}{color:#000000}
So is this a bug or a feature? Does all WKT polygons coming into Oracle need to have their rings prerotated and if so, why would VALIDATE_WKTGEOMETRY not warn us of the problem.
Cheers,
Paul
{color}

Paul,
In case you are not aware:
SELECT SDO_MIGRATE.TO_CURRENT(
MDSYS.SDO_GEOMETRY('POLYGON((-76.57418668270113 38.91891450597657,-76.57484114170074 38.91758725401061,-76.57661139965057 38.91881851059802,-76.57418668270113 38.91891450597657))',8265)
,SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -99999.00000, 99999.00000, 0.0001),SDO_DIM_ELEMENT('Y', -99999.00000, 99999.00000, 0.0001)))
FROM dual
---produces:
MDSYS.SDO_GEOMETRY(2003, 8265, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1), MDSYS.SDO_ORDINATE_ARRAY(-76.5741866827011,38.9189145059766,-76.5766113996506,38.918818510598,-76.5748411417007,38.9175872540106,-76.5741866827011,38.9189145059766))
---thus:
SELECT SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(
MDSYS.SDO_GEOMETRY(2003, 8265, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1), MDSYS.SDO_ORDINATE_ARRAY(-76.5741866827011,38.9189145059766,-76.5766113996506,38.918818510598,-76.5748411417007,38.9175872540106,-76.5741866827011,38.9189145059766))
,0.0001) FROM dual
---produces: TRUE
r,
dennis

SDO_UTIL Missing Functions?

Folks,
I am accessing a 10.2.0.1 SE database at a client site and when I describe the SDO_UTIL package I don't get all the functions in 10.2.0.1 that I use when developing my PL/SQL packages (for download at my website).
SQL*Plus: Release 10.2.0.1.0 - Production on Fri Feb 9 09:06:27 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Release 10.2.0.1.0 - 64bit Production
SQL> desc sdo_util
FUNCTION APPEND RETURNS SDO_GEOMETRY
Argument Name Type In/Out Default?
GEOMETRY1 SDO_GEOMETRY IN
GEOMETRY2 SDO_GEOMETRY IN
FUNCTION EXTRACT RETURNS SDO_GEOMETRY
Argument Name Type In/Out Default?
GEOMETRY SDO_GEOMETRY IN
ELEMENT NUMBER IN
RING NUMBER IN DEFAULT
FUNCTION GETVERTICES RETURNS VERTEX_SET_TYPE
Argument Name Type In/Out Default?
GEOMETRY SDO_GEOMETRY IN
FUNCTION REMOVE_DUPLICATES RETURNS SDO_GEOMETRY
Argument Name Type In/Out Default?
GEOMETRY SDO_GEOMETRY IN
DIM SDO_DIM_ARRAY IN
FUNCTION REMOVE_DUPLICATE_VERTICES RETURNS SDO_GEOMETRY
Argument Name Type In/Out Default?
GEOMETRY SDO_GEOMETRY IN
TOLERANCE NUMBER IN
FUNCTION TRUNCATE_NUMBER RETURNS NUMBER
Argument Name Type In/Out Default?
VALUE NUMBER IN
NO_OF_DIGITS NUMBER IN
In particular, I am looking for CONCAT_LINES() and RECTIFY_GEOMETRY.
Any pointers?
regards
Simon Greener

Dan,
This explains it. I am running 10.2.0.1 on my laptop and have all the functions etc.
I have seen this error:
ORA-04063: type body "MDSYS.SDO_INDEX_METHOD_9I" has errors
at many sites but never quite got to the bottom as to why it occurred was occuring on 10g databases! I always assumed the _9I thing was a short term carry over.
Now I know!
Mate, I am really well. Thankfully, reasonably busy, though things were a bit quiet when I got back from Europe (last October). It was great to meet you though it would have been nice to have had a chance to catch up over a drink/dinner but you had to fly back to the USA. I have started down the OCP track which, on top of everything else, is keeping me out of mischief!
I hope all is going well with you. We should drop each other an email off line...
regards
S

SDO_UTIL.SIMPLIFY seems to be rather unhappy with my polygon

Hi folks,
Not sure if this is a bug or just how things are. I have a polygon that is valid, looking like an upside Q - i.e. a ring-like polygon with a big hole in the middle. On 10.2.0.4, when I run SDO_UTIL.SIMPLIFY with a 20 meter threshold, it returns NULL. A threshold of 80 returns a line whilst a threshold of 10 returns a reasonable result. But NULL? I don't see anything in the documentation about this.
Next I tried the exact same thing on 11.1.0.7 and rather than NULL, I get ORA-13199 instead. This seems like an improvement. So I assume what produces NULL on 10g throws an error on 11g. I guess we call that progress and move on - any plans to backport this behavior to 10g?
But back to the results. Looking through
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_util.htm#sthref2702
I don't see any mention that a legal function result can be ORA-13199. So is this a bug? Or are some threshold values "just not gonna" work and always return an error by design?
Thanks!
Paul
SELECT
SDO_UTIL.SIMPLIFY(
SDO_GEOMETRY(
2003,
8265,
NULL,
SDO_ELEM_INFO_ARRAY(
1,
1003,
1,
63,
2003,
1
SDO_ORDINATE_ARRAY(
-80.6678363850029,
27.1544468240932,
-80.6676581190441,
27.1544578908543,
-80.6673811848868,
27.1545404243406,
-80.6669873181666,
27.1546888239902,
-80.6669011856599,
27.154727424447,
-80.6667227848805,
27.1548484903997,
-80.6666243193133,
27.1549804918455,
-80.6665567184542,
27.1551016239273,
-80.6665443185942,
27.1552556914498,
-80.6666181177095,
27.1555144243224,
-80.6667779183997,
27.1559106917256,
-80.6668025185416,
27.1560536914105,
-80.6668271189153,
27.1560868245381,
-80.6668579182135,
27.1560866907775,
-80.6669009855045,
27.1560592917636,
-80.6669071190522,
27.1559382250141,
-80.6669871190558,
27.1559106906018,
-80.6673439852962,
27.1559052909276,
-80.6673931847717,
27.1558888246279,
-80.6674363186955,
27.1558722246153,
-80.6675469848459,
27.1557622244607,
-80.6678731857396,
27.155575091261,
-80.6679839844916,
27.1554870246634,
-80.6680947191472,
27.1553660239724,
-80.668279384442,
27.1550798248074,
-80.66834698489,
27.1549642916886,
-80.6683593847143,
27.1548432242984,
-80.6683101849162,
27.1547276237897,
-80.6681687190595,
27.1545734909874,
-80.6679841179111,
27.1544468907341,
-80.6678363850029,
27.1544468240932,
-80.6670609857901,
27.1558170906695,
-80.6669317858199,
27.1558172245472,
-80.6668271853341,
27.1557840250493,
-80.6666919857747,
27.1552446911476,
-80.6667105183963,
27.155134623902,
-80.6668213180802,
27.1549420246816,
-80.6670549849476,
27.154793491146,
-80.6674795852521,
27.1546338906477,
-80.6678303186443,
27.154556890968,
-80.6679287847641,
27.1545568916289,
-80.6681071851569,
27.1546450245379,
-80.6681933180075,
27.1547606247241,
-80.6682117191289,
27.1548872243023,
-80.6681931847942,
27.1549532242227,
-80.6681809185176,
27.1549918246254,
-80.6678917187281,
27.1553990242445,
-80.6677069852055,
27.155542091489,
-80.667479384833,
27.1556740913815,
-80.667270184745,
27.1558170915238,
-80.6670609857901,
27.1558170906695
),20,0.001) from dual

Hi folks,
Not sure if this is a bug or just how things are. I have a polygon that is valid, looking like an upside Q - i.e. a ring-like polygon with a big hole in the middle. On 10.2.0.4, when I run SDO_UTIL.SIMPLIFY with a 20 meter threshold, it returns NULL. A threshold of 80 returns a line whilst a threshold of 10 returns a reasonable result. But NULL? I don't see anything in the documentation about this.
Next I tried the exact same thing on 11.1.0.7 and rather than NULL, I get ORA-13199 instead. This seems like an improvement. So I assume what produces NULL on 10g throws an error on 11g. I guess we call that progress and move on - any plans to backport this behavior to 10g?
But back to the results. Looking through
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_util.htm#sthref2702
I don't see any mention that a legal function result can be ORA-13199. So is this a bug? Or are some threshold values "just not gonna" work and always return an error by design?
Thanks!
Paul
SELECT
SDO_UTIL.SIMPLIFY(
SDO_GEOMETRY(
2003,
8265,
NULL,
SDO_ELEM_INFO_ARRAY(
1,
1003,
1,
63,
2003,
1
SDO_ORDINATE_ARRAY(
-80.6678363850029,
27.1544468240932,
-80.6676581190441,
27.1544578908543,
-80.6673811848868,
27.1545404243406,
-80.6669873181666,
27.1546888239902,
-80.6669011856599,
27.154727424447,
-80.6667227848805,
27.1548484903997,
-80.6666243193133,
27.1549804918455,
-80.6665567184542,
27.1551016239273,
-80.6665443185942,
27.1552556914498,
-80.6666181177095,
27.1555144243224,
-80.6667779183997,
27.1559106917256,
-80.6668025185416,
27.1560536914105,
-80.6668271189153,
27.1560868245381,
-80.6668579182135,
27.1560866907775,
-80.6669009855045,
27.1560592917636,
-80.6669071190522,
27.1559382250141,
-80.6669871190558,
27.1559106906018,
-80.6673439852962,
27.1559052909276,
-80.6673931847717,
27.1558888246279,
-80.6674363186955,
27.1558722246153,
-80.6675469848459,
27.1557622244607,
-80.6678731857396,
27.155575091261,
-80.6679839844916,
27.1554870246634,
-80.6680947191472,
27.1553660239724,
-80.668279384442,
27.1550798248074,
-80.66834698489,
27.1549642916886,
-80.6683593847143,
27.1548432242984,
-80.6683101849162,
27.1547276237897,
-80.6681687190595,
27.1545734909874,
-80.6679841179111,
27.1544468907341,
-80.6678363850029,
27.1544468240932,
-80.6670609857901,
27.1558170906695,
-80.6669317858199,
27.1558172245472,
-80.6668271853341,
27.1557840250493,
-80.6666919857747,
27.1552446911476,
-80.6667105183963,
27.155134623902,
-80.6668213180802,
27.1549420246816,
-80.6670549849476,
27.154793491146,
-80.6674795852521,
27.1546338906477,
-80.6678303186443,
27.154556890968,
-80.6679287847641,
27.1545568916289,
-80.6681071851569,
27.1546450245379,
-80.6681933180075,
27.1547606247241,
-80.6682117191289,
27.1548872243023,
-80.6681931847942,
27.1549532242227,
-80.6681809185176,
27.1549918246254,
-80.6678917187281,
27.1553990242445,
-80.6677069852055,
27.155542091489,
-80.667479384833,
27.1556740913815,
-80.667270184745,
27.1558170915238,
-80.6670609857901,
27.1558170906695
),20,0.001) from dual

SDO_UTIL.BEARING_TILT_FOR_POINTS returning ORA-03113

I am attempting to run a set of points through the SDO_UTIL.BEARING_TILT_FOR_POINTS procedure using the example listed in the Oracle Spatial Developers Guide. I have tried this on 2 different Oracle 11 instances, windows and linux based, and they all throw me an ORA-03113 End of File on Communication Channel when executed from SQL Plus. Here's the code I am running:
SET SERVEROUT ON;
DECLARE
bearing NUMBER;
tilt NUMBER;
BEGIN
SDO_UTIL.BEARING_TILT_FOR_POINTS(
SDO_GEOMETRY(2001, 26913, SDO_POINT_TYPE(712232.0632,4140111.6492, 0), NULL, NULL), -- start_point
SDO_GEOMETRY(2001, 26913, SDO_POINT_TYPE(712232.4586,4140107.6570, 0), NULL, NULL), -- end_point
0.05, bearing, tilt);
DBMS_OUTPUT.PUT_LINE('Bearing in degrees = ' || bearing * 180 / 3.1415926535897932384626433832795);
DBMS_OUTPUT.PUT_LINE('Tilt in degrees = '|| tilt * 180 / 3.1415926535897932384626433832795);
END;
I have tried decreasing the precision of my point ordinates, reducing the tolerance, adding elevation to second point specification etc, to no avail.
Anyone have any ideas?
Edited by: Aggieangler on Feb 2, 2011 11:38 AM

The input to the bearing_tilt function should be geodetic data, it won't work with projected data.
siva

SDO_UTIL.PREPARE_FOR_TTS

Similar Messages

Maybe you are looking for