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

[ΠαναγιώτηςΠαπάζογλου]

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?

[RichardFairhurst]

Joshua:

Thanks for the information about how Python interacts with ArcObjects.  With Python being a wrapper that would account for part of the reason that the Python calculation takes longer.  It is most likely that different programmers wrote methods for determining area during the various versions and rewrites of this software.  Complex shapes I am sure have several programmatic techniques for breaking them down to simpler shapes as well as choices for methods that can handle floating point accuracy differently for performance reasons.  Again, with the concept of Resolution and Tolerance understood by each programmer, all of the results are "correct" since they adhere to that requirement.  If a user is intolerant of differences below those amounts that means that they chose the wrong Tolerance setting, not that the approach the programmer took was wrong.

[DanPatterson_Retired]

but of course you can calculate area in pure python and/or numpy if you need speed and want to leave out the wrapper

[RichardFairhurst]

Do you have the pure Python code ready to release that would determine the areas of every polygon shape that exists?  If not, then I actually can't do that calculation in pure Python, since I lack the time, expertise or justification to my employers that would allow me to start the development of such code on my own.

[DanPatterson_Retired]

It has existed for a long time and variants covering the methods of shape recording are well documented in many languages, including python and its associates.  esri didn't invent area calculation. In fact, the geometry package is a subset of what is available to represent spatial data in vector form, since they deal with the needs of the masses

[RichardFairhurst]

Dan:

I know nothing about the resources you are talking about.  How do I go about finding all of this

[DanPatterson_Retired]

Well a general introduction would to be to start with the basics "shoelace formula" for calculating area and shape centroid for simple irregular, non-intersecting shapes.  That will bring you into the realm of the mathematical history (which is interesting in itself).  Then you have shapes with holes, ring orientation and its affect on area, multipart shapes (which may have holes) boundary sharing.  A long path but you will get back to popular literature in the late 1990's (paul bourke) and C implementations of common 2D geometry (point in polygon, etc), divergence into other languages.  If you want to go on a real tangent into the maths, you might end up in Euclid's Elements (available and translated into english) which brought back the what's old is new again history of geometry.  Now top this off with the move into 3D geometry (and beyond) and the complexities that each dimension brings (arc* doesn't even implement 'full' 3d geometry since shared edges bearing the same attribute in 2D and 3D are dissolved and 3D shapes are extruded rather than 'drawn' because of this.)

I digress, I will be posting before sept. working exercises on geometry etc for upcoming courses and they will appear in ArcScripts (beta) with references in my blog, which contains some, in  a totally tagential organized way.