Feature Class XY Domain Difference

1812
11
07-25-2014 10:13 AM
JenniferDick
New Contributor II

Hello,

I'm comparing feature classes using the Compare Feature tool in the ArcToolBox. One of the layers is a SDE 9.1 layer and we've re-created it in SDE 10.1. I'm using this tool to compare the differences and similarities.

One common difference is the XY Domain for example, I've attached to Feature Class Properties screen shots for both layers. The 10.1 domain is remarkably different, is this because of the high precision?

I know that high precision storage allows you to store coordinates closer together while expanding the x,y,z,m domain. Is this what's happening here?

Please help

Thanks

Jennifer 

0 Kudos
11 Replies
KenHartling
Esri Contributor

Hi Jennifer,

In case the Geodatabase folks don't see your post I'll reply.  I believe your guess about the difference between high/low precision is correct.

If you would like to confirm this for yourself, please see http://downloads.esri.com/support/whitepapers/ao_/UnderstandingCoordinateManagement_June2007.pdf‌ which has a good explanation of coordinate management in the geodatabase.

Ken

JenniferDick
New Contributor II

HI ken

thanks very much for your response. I've downloaded the document t from the link above which will help me document my testing. Have you been able to read the other post I made a couple days ago on the actual output results from the compare feature tool?

Thanks

jennifer

0 Kudos
KenHartling
Esri Contributor

I’ve replied to the post you mention.

0 Kudos
JenniferDick
New Contributor II

Hi,

Looking for someone from the Geodatabase space to provide some input on the screen captures I took of a layer in 9.1 and 10.1 above. I would like some insight into the comparison between the domain extents, resolution and tolerance. Going from single to double precision, should I expect to get the results I did with the 10.1 layer?

From what I've read it seems to make sense, but struggling on how to explain this to those not exposed to the GIS spatial world.

Any insight would be great!

Thanks

Jennifer

0 Kudos
VinceAngelo
Esri Esteemed Contributor

Yes, this would be expected when going from BASIC to HIGH coordinate reference precision.

Note that you are not going from "single to double precision", since ArcSDE has never used single precision, and HIGH precision is only 54-bits, not 64, because that is the size of the mantissa in IEEE double-precision values.

Maybe this will help you explain:

When "SDBE" was acquired by Esri, it made use of 32-bit integer arrays to store coordinate data. The integers were calculated explicitly by developers, by subtracting an offset and multiplying the remainder by a scale factor, and then rounding to the nearest integer. This resulted in reduced storage and faster comparison, because coordinate values were discrete.

Starting with SDE 3.0, Esri encapsulated the integer representation inside an "SE_SHAPE" object with a SE_COORDREF object to store the coordinate reference offsets and scales.  The problem was that there was only 31 bits available for coordinates, and those that wanted more were unhappy. So at 9.0, The ArcSDE API was updated to optionally support the use of 64-bit integers in coordinate arrays, under the name "64_BIT" precision.  ArcGIS did not use this capability until 9.2, by which time it was called "HIGH" precision, and was made the default.

Previously users had to carefully allocate their bits, but the additional space allowed for many options. Too many options, in fact, so a standardized set of coordinate references were calculated, with 0.1-1.0 millimeter precision in every possible projection.  You can still change this, but it's difficult to override the default.

Unfortunately, the standardization came at a cost:  Most users don't need sub-millimeter precision,  especially for data that isn't accurate to a meter, and the storage cost of the compressed integer array at higher precision is significant.  I often find I can use much less storage and see much better performance by using the old one million scale factor for decimal degree data, even if I now use a {-400,-400} origin.

Having read the Understanding Coordinate Management whitepaper, I would suggest you focus on the important components of the data extent --  the minimumX, minimumY, and XY precision.  The upper-left upper-right corner can mind its own business, so long as it isn't interfering with storing values.

- V

0 Kudos
JenniferDick
New Contributor II

Thanks Vince, appreciate the detailed response...the document certainly helps as well. I'll make sure that I completely understand the minX, minY, maxX, maxY and precision moving forward.

Not 100% sure on what you mean by the upper-left corner and storing values though...

0 Kudos
VinceAngelo
Esri Esteemed Contributor

Doh.  Upper-RIGHT corner (will change)

The MaxX and MaxY are distractions.  Only MinX, MinY, and precision matter (unless your precision is nanometers)

- V

0 Kudos
JenniferDick
New Contributor II

Roger that, okay...thanks Vince !

0 Kudos
JenniferDick
New Contributor II

What do you think about this Vince...

I'm trying to understand what our developer did in the back end when importing the layers to SDE 10.1. This is my thought below:

The Original Resolution = 0.0000001, I'm guessing to specify a smaller finer resolution, the value was divided evenly into the original XY resolution iteratively based on a power of 2. Therefore, to get obtain the higher resolution in the 10.1 database, 0.0000001/(2^6) equation was used?.

Am I'm loosing my mind? lol

0 Kudos