Different precision between ST_Geometry SQL result and ArcGIS Server REST API result

[StefanP__Jung]

When using ST_Geometry to get the wkt or wkb from a feature class each coordinate gets rounded to 4 numbers after the decimal.

Query:

SELECT sde.st_astext(g.shape) as wkt 
FROM geodata g 
WHERE gisid in (1234)

Result:

POLYGON  (( 818052.36380000 5742316.96420000,  ...) 

When accessing the same feature class via REST API Query from ArcGIS Server i will get:

[
      [
       818052.3638000004,
       5742316.9641999993
      ],
...
]

Using:
- ArcGIS Server 10 SP 2 on Windows 2008 english
- ArcSDE 10 SP 2, using direct connect for all features @ mxd
- Oracle 11.2.0.3 on Windows 2008 german

Why do i get only rounded values via ST_Geometry? Is this a Oracle Issue? It it possible to alter the session to get the complete value?

Querying the same feature via ArcGIS Server REST API and ST_Geometry should return exactly the same Polygon.

Any Idea?

Stefan

[VinceAngelo]

If you inspect the SRID of the ST_GEOMETRY layer, I'm sure you'll find it has been created
with an XY_SCALE (resolution) of 1000 (1mm).  If so, then you *are* getting the complete
value in SQL (and an imprecise one through the REST API).

If you wish greater precision, you'll need to specify it at layer creation.  But be sure you
understand the storage and performance ramifications before you ratchet up the precision
(greater precision decreases compression efficiency, slowing access proportionally).  It
would also be useful to compare the desired precision with the actual accuracy -- most
geospatial data isn't more accurate than a decimeter, much less a millimeter, so displaying
it to angstrom resolution is more than just a violation of the Heisenberg Uncertainty Principle.

- V

[StefanP__Jung]

Thanks for your reply,

i have checked the ST_SPATIAL_REFERENCES Table but there is no field named XY_SCALE like expected.

The field XYUNITS is set to 10000 and the TOL fields at SPATIAL_REFERENCES are set to 0.001 for this coordinate system.



But if the features are stored with a resolution of 1000 the REST API should return the same value. So the problem of the imprecise might be within the rest api.

Or any idea why the rest api should return a different value?

Best Regards

Stefan

[VinceAngelo]

Doh, yes, XYUNITS 10000 (0.1mm).

The problem *is* with the REST API, but it's more a simple issue about representing some
double values in text (and vice versa), which is why the n.9641999993 and n.3638000004
values exist. Given that the geospatial object's precision is at the thickness of a human hair,
and the imprecision is at the magnitude of the length of the covalent bond between carbon
atoms, I doubt it's really worth pursuing.

- V

[StefanP__Jung]

My problem is that i have a service that receives a wkb/wkt polygon from a client. This polygon originally comes from The ArcGIS Server REST API. The client requests to create a union with the given wkb/wkt and a polygon which is already stored @SDE.

If both polygons touch each other the union result is "corrupted" at the common border. If the ArcGIS Server REST would return the expected values the topology of the two polygons would be ok.

The union is performed via ST_GEOMETRY, is it possible to set the precision for the UNION?

I can post some detailed information tomorrow when i am back in the office,

Stefan

[VinceAngelo]

The precision of an ST_GEOMETRY object is defined by its SRID.  The ST_UNION
operator should handle the merge of overlapping geometries correctly.  You should
start an incident in the ArcGIS Server REST API queue if the display precision
is causing topology problems.

- V

[StefanP__Jung]

Esri was able to reproduce this issue:

NIM078128 REST JSON geometry query returns incorrect level of precision.

Stefan