Calculating areas with CalculateField_management

[BrianAmos]

I'm running this line of code:

arcpy.CalculateField_management("checkhull", "hullarea", "float(!shape.area@acres!)", "PYTHON")

However, checking the attribute table, it's returning square decimal degrees instead. No matter what I change the @acres portion to (@squaremiles, @squarefeet), it returns the same result. If I change the @acres portion to something not on the list of allowed units, though (say, @asdfasdf), it returns an "invalid property" error.

If I go to the attribute table and start an editing session, the "Calculate Geometry" function works properly. I tested it further by going to the Field Calculator and entering !shape.area@acres!, along with a few other types of units, but it's still returning square decimal degrees.

Any ideas of what might be going on? Is there a module I need to import to make this work properly (other than arcpy)?

[DanPatterson_Retired]

Not necessarily the answer you want...but if one needs answers in planar units...project the data so that your file is in the desired coordinates, keeping the DD file as a backup

[KimOllivier]

CalculateField is best kept for ModelBuilder. It simply wraps a cursor around the expression, so why not use a cursor if you are writing a script?
It has a lot more capability:

• You can project data on the fly for calculation


• The field list can restrict the fields retrieved for efficiency


• You can use an sql expression to select a subset of records


• You can return records sorted


• It is possible to trap unexpected data


• It is much easier to program complicated functions


• All the other script variables are available


• It is just as fast as calculatefield

When you add a spatial reference to the cursor the attributes are projected on the fly for returned variables such as the area calculation. There is no need to project your source. (You might also need a transformation to be set.)

I personally do not hold any data in decimal degrees if I am going to run any geoprocessing tool or model. This is because I live in the temperate zone (37S - 47S) where the distortion between latitude and longitude scales is 50% and unacceptable for everything using distance, bearings, area or tolerances. [The only tool to properly account for geodetic calculations is the point buffer tool. Everything else assumes planar coordinates.] So what shape is your convex hull boundary? Does it have straight lines between points, or is it curved to trace the longitude paths? Before you reproject it, has it been densified to allow for non-linear curves? So I agree with Dan that it might be better to project the source points before you even run the convex hull tool.

# ----- snip -----
projectedRef = gp.CreateObject("SpatialReference")
projectedRef.CreateFromFile("MySr.prj")
factor = 123223324 # the factor from map units to acres
# in metric societies this is simply a power of 10 from metres to hectares
cur = gp.UpdateCursor("checkhull","",projectedRef)
row = cur.next()
while row:
    row.hullarea = row.shape.area * factor
    cur.updateRow(row)
    row = cur.next()
del row,cur # must close to flush file buffers

Very similar code for ArcPy at 10.x