SDO_UTIL.TO_CLOB odd head scratcher

Question

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

Answer 1

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