Inconsistent CalculateField with python vs VB

[alicexu]

result of arcpy.CalculateField_management with python is inconsistent but with VB, it is ok

[RichardFairhurst]

There is no way anyone can help you or replicate what you are reporting without the specific calculation code you are using.  Please post your calculation.  Otherwise, if you are just making a general statement about calculation behaviors using the two languages then your observation is not true for any of the calculations I do.

[alicexu]

arcpy.CalculateField_management(temp, "ft", "!SHAPE.area!", "PYTHON_9.3", "")

result:

arcpy.CalculateField_management(temp, "ft", "[shape.area]", "VB", "")

result:

[alicexu]

VB: arcpy.CalculateField_management(temp, "ft", "[shape.area]", "VB", "")

Python: arcpy.CalculateField_management(temp, "ft", "!SHAPE.area!", "PYTHON_9.3", "")

[RichardFairhurst · Accepted solution]

Alice:

What database are you using for this feature class, SDE? File Geodatabase? Personal Geodatabase?  (it does not appear it could be a shapefile based on the field names).  If it is SDE, what underlying database is SDE using?  What version of ArcMap do you have?

It is possible that rather than just transferring the value in the shape.area field the Python version is processing the actual shape geometry directly and perhaps altering it if the original geometry contains such things as true curves, rather than densified lines to form a curve.  Python has issues with true curves.

If you are at version 10.0 or above, the VB Script calculation has no access to the actual geometry and can only process the value in the shape.area field as a numeric field, so the methodologies underlying the two languages could be different.

[alicexu]

Richard,

It's SDE. I'm calculating the same polygon but results are different from using VB vs Python

Thanks,

Alice

[RichardFairhurst]

Flavor of SDE?  ArcMap version?  SDE database version?  How was the polygon geometry created?  COGO, buffer tool, parcel fabric processes?

All such details can potentially play an important role in what you are observing.

However, ultimately this question has to be posed directly to Esri, because the Field Calculator is a black box for everyone except for the developers of the tool.  All of the details above will be required to make the report.

[alicexu]

ArcGIS 10.2.2

[alicexu]

Richard,

I think you are right - it happened all polygons with curves (see the map - the blue are shapes without curves and they are correct numbers as shape.area, the red polygons are shapes with curves and they are different from shape.area...). So, how can I still use python but get the true result like using VB since I need to write python scripts for my nightly process? Many thanks !

Alice

[RichardFairhurst]

If the VB version of the calculation works, go ahead and include it in the nightly script.  They work for my nightly scripts and I use VB in my Python script Field Calculations more than Python_9.3 or Python.  Here are examples of VB script Field calculations I actually use in my nightly Python scripts:

Empty string assignment:

arcpy.CalculateField_management(CENTERLINE_ROUTES_MERGED__3_, "ROUTE_ALT1", "\" \"", "VB", "")

Numeric Value assignment:

arcpy.CalculateField_management(CENTERLINE_EXTENDED_Layer__13_, "CENTERLINE_EXTENDED.TRANSFERRED", "1", "VB", "")

Date/Time assignment:

arcpy.CalculateField_management(SCRIPT_LOG_View, "FINISH_TIME", "Now (  )", "VB", "")

Field data transfers in an unjoined table

arcpy.CalculateField_management(CENTERLINE_ROUTES_MERGED__5_, "ROUTE_NAME", "[ROUTE_ALT1]", "VB", "")

Field data transfers between joined tables

arcpy.CalculateField_management(RDNUMBER_Routes_Layer, "RDNUMBER_Routes.First_STNAME", "[RDNUMBERS_ALL.FIRST_STNAME]", "VB", "")

The calculation you are doing is in the Field data transfers in an unjoined table category and should work fine in your nightly python script.  I have found that only VB Script multi-line advanced field calculations are not supported in a Python script.