We are using Microsoft SQL Server 2012 and ESRI 10.2 in a Windows environment, shapes are stored in Geometry format.
We are trying to programmatically add shapes directly to an ESRI Geodatabase (IE via SQL, not ESRI routines).
Some of the shapes have suspect self-intersections and we need to either make them valid, or reject them.
This issue we are having is that raw SQL environment considers the shapes valid, but when they are read by ESRI products some are considered invalid.
This issue seems to be related to the number of decimal places used by SQL versus that used by ESRI.
The attached SQL code demonstrates the issue..
My question is have I detected a solution that is applicable to all cases (IE ESRI and SQL will always both agree on validity or otherwise).
Feedback from anyone with knowledge in this area would be appreciated
Older Microsoft releases used less than the 31-bits originally used by Esri. I don't think that's the case now.
Esri uses encoded long integers (long long -- 64-bits), but since the mantissa of a IEEE double is 52, the effective width is 54.
Accuracy isn't really on the table here. We're just talking about precision.
The whitepaper referenced in my GIS SE answer explains exactly how Esri coordinate references operate.
- V
Sorry Vince, I am having trouble locating 'The whitepaper referenced in my GIS SE answer'
It's linked to in a post above - arcgis desktop - Appending polygon feature classes with already repaired geometry => WARNING 000442:...