SDO_UTIL.FROM_WKTGEOMETRY doing some odd math

Question

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}

Answer 1

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