ArcGIS Pro Area Calculations are Incorrect and Glitchy

[jfischer91]

I'm getting inconsistent results when trying to calculate polygon areas in Pro 3.3.2 (but it was happening when I was on Pro 2.9.5 I think too). 

I have a layer in WGS84 Web Mercator and I'm calculating areas in NAD 1983 State Plane, in this case, Montana (though I saw this in Wyoming too). My map has a transformation set, and while I know maybe this is a strange workflow, I've done it this way for a while and never used to have issues. One of the perks of Pro, I thought, was being able to calculate areas in different coordinate systems without having to actually switch the map or layer's coordinate system.

I digitized about 50 polygons and then went to calculate their areas. When I batch calculate all at once, I get values that all seem correct, but have been assigned to the wrong polygon. Then, when I recalculate them individually or in groups of 2 or 3, they populate different, and more accurate, numbers. 

In the example below, see the ObjectID of the highlighted feature. The first screenshot has an area value that was populated when I batch calculated all 50 features. You can see that the map I digitized it from lists a very different value, and when I recalculate the feature individually, it populates a much more accurate number (second screenshot: confirmed it's the same feature by the ObjectID). 

Has anyone else experienced this, and what the heck is happening? It's concerning that one of the most basic GIS operations is now returning numbers I can't trust. Even if it was an issue of different coordinate systems, the fact that it seems to calculate values correctly but assigns them to incorrect features is crazy. I will test calculating areas with the map actually in that coordinate system, but this seems like a deeper issue.

[clt_cabq]

For sake of comparison, have you gone through the effort of projecting your digitized data into the same coordinate system you are trying to calculate in and performed the same operations? It might be interesting to see if you get similar results when your map and data set are all set to the coordinate system you are wanting results in. Something is bizarre for sure. Generally I think a best practice is to create your data using the spatial reference/coordinate system you want calculation results in. 

[ShaneONeill_144]

Have you tried this on 3.4 as well?

[KaseyCox]

I have a user encountering a similar issue but with lines and a length caluclation.  Data MUST be in WGS84 as set of NENA standard, but they need a length in foot for their road maintenance crews. 

[chill_gis_dude]

I know you commented on another post that I responded to but I wanted to post this here for anyone following because I think your issue could very well be related to this bug: 

Updates have been made to the following defect which you are associated with:
BUG-000171641 - When the Calculate Geometry geoprocessing tool is run on an enterprise geodatabase polygon feature class with attachments enabled and 65 or more records selected, the tool completes, but the values are applied to the wrong records.

Status: Fixed (Learn More)
Version Fixed: 3.5
Additional Information: This issue is addressed in 3.5

Alternate Solutio...

• Disable the attachments on the feature class, close and reopen ArcGIS Pro, then run Calculate Geometry again to see the expected values when making a selection of 65 or more features.
  • If attachments are still enabled, run Calculate Geometry on 64 features or less to see the expected values.
  • Run Calculate Geometry on the feature class as a whole instead of a selection of features if attachments are enabled.

    I did not like their suggested workarounds because they seemed finicky so I used a different workaround that the analyst suggested and it has worked without fail while we wait to upgrade to 3.5. I export any features I want to calculate geometry on to a file geodatabase preserving global ID's. I then calculate geometries in the file geodatabase and join the data back (using globalIDs) to the original layer in my enterprise geodatabase and use the field calculator to populate the values.