Difference between !shape.area! and Calculate Geometry > area

21384
35
05-18-2016 05:46 AM

I have a shapefile with 62.000 polygons.

I have created two fields (Double) AREA1 and AREA2 with identical properties.

On AREA1 I have calculated the area of polygons with Calculate Geometry > area process.

On AREA2 I have calculated the area of polygons with Field calculator and the command: !shape.area!

When I compare the difference between the two fields ([AREA1] - [AREA2]), I find 30 polygons with no zero difference less than 0,01 square meters.

Is there a different algorithm for these processes?

Does anyone know why is this happening?

35 Replies
DanPatterson_Retired
MVP Emeritus

I calculated it several ways and the results were still the same... no difference ... I don't know what makes your installation different that all the rest of us, but I would investigate that as well.  PS, side the areas were in m^2, that area represents less than the area of a skin cell.

I also calculated in more than one PCs (5 to be exact) and the problem remains.

0 Kudos
DanPatterson_Retired
MVP Emeritus

Send your data set to tech support, file an issue and they will verify.  In the interim, upgrade to 10.4 and try it

You have entered the realm of floating point representation which isn't going to change, hopefully your clients are knowledgeable of such issues otherwise they ask them what their acceptable area resolution is.

0 Kudos
NeilAyres
MVP Alum

And, if you changed your coordinate system to something else, like UTM, you would get a different set of numbers.

And the differences between these new areas and your original would be significantly higher than what you are now seeing.

Everything is relative.

0 Kudos
RichardFairhurst
MVP Honored Contributor

I believe the Geometry Calculator is using code developed in C, which relies on math libraries developed independently from those for Python.  As Dan mentioned, Floating Point Precision is impossible for computers to represent with infinite precision and every time you alter the order of any two mathematical operations you can encounter different data type conversions and handling, even down to the bit handling level.

The Resolution and Tolerance settings of your data have been respected, and that is all that Esri has guaranteed you or your client.  There is no such thing as a setting for infinite Resolution and absolute Intolerance of rounding in the real world.  That is true for both computers and for Surveyors and their instruments.  No Surveyor would ever allow a provision in their contract that would let your client refuse to pay them because of differences in recorded measurements at these levels of precision.  They would reject any request by your client to even show them the measurements that their instruments may have recorded at these levels, since they know that they are inherently unreliable. The Surveyor, like Esri, only guarantees their reported measurements to a certain Resolution and Tolerance.  Unfortunately, giving the actual computer data to a client is like giving the unfiltered survey instrument measurements to a client, you have no way to prevent an untrained client from expecting the tool to perform far beyond its actual capabilities.  Your expectations are not in line with the reality of computer science or real world GIS.

Thanks for your detailed response.

0 Kudos
JoshuaBixby
MVP Esteemed Contributor

What you uploaded are shapefiles.  Out of interest, have you tried copying the data into a feature class in a file geodatabase and see if you see the same issue?

0 Kudos
DanPatterson_Retired
MVP Emeritus

Joshua... the shapefiles were checked by a couple of us with the same ...no difference ... result.  Someone with a 10.3.1 could give it a try, but I have been working with geometry all year and the only times things get "issued up" is when the coordinates are not known (no prj in the case of shapefiles, I have documented this) or the file is projected to a different coordinate system and back.  Then you enter the realm of floating point representation.

0 Kudos
JoshuaBixby
MVP Esteemed Contributor

I do have access to 10.3.1 machines.  If I can find the time, I may take the sample data for a spin in that version.

0 Kudos
JoshuaBixby
MVP Esteemed Contributor

Richard Fairhurst​, I agree completely with your second paragraph, i.e., the OP is overlooking the importance of Resolution, Tolerance, and the reality of computational precision.

Regarding ArcPy, it offers very little native functionality that isn't part of the core ArcGIS product.  ArcPy is a Python wrapper around all of the code that drives ArcGIS for Desktop, ArcGIS Pro, etc....  Looking through some of the files that make up the site package:

...\Desktop10.4\arcpy\arcpy\arcobjects\geometries.py

from arcpy.arcobjects.arcobjects import Geometry

...\Desktop10.4\arcpy\arcpy\arcobjects\arcobjects.py

class Geometry(mixins.GeometrySpecializationMixin,_BaseArcObject):
    """Geometry objects define a spatial location and an associated geometric
      shape."""
    
    def getArea(self, method="GEODESIC", units=None):
        from ..geoprocessing._base import gp_fixargs
        return convertArcObjectToPythonObject(self._arc_object.GetArea(*gp_fixargs((method, units))))

Area calculations with ArcPy Geometry come from ArcObjects and are converted back to Python.  There may be more than one set of geometry calculations within ArcObjects, and if there is they may not return the exact value in all circumstances, but that would be caused by differences in ArcObjects and not a difference between doing the calculation with Geometry Calculator versus ArcPy.