result of arcpy.CalculateField_management with python is inconsistent but with VB, it is ok
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.
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.
arcpy.CalculateField_management(temp, "ft", "!SHAPE.area!", "PYTHON_9.3", "")
result:
arcpy.CalculateField_management(temp, "ft", "[shape.area]", "VB", "")
VB: arcpy.CalculateField_management(temp, "ft", "[shape.area]", "VB", "")
Python: arcpy.CalculateField_management(temp, "ft", "!SHAPE.area!", "PYTHON_9.3", "")
Richard,
It's SDE. I'm calculating the same polygon but results are different from using VB vs Python
Thanks,
Alice
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.
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.
But I got an error when I use VB option in my python scripts:
# Import arcpy module
import arcpy
# Local variables:
temp = "S:\\AVM\\ArcCatalogAvmConnections\\ro_gis(AVM).sde\\avm.AVM.Parcel_PolyOnly_Select_Ident1"
# Process: Calculate Field
I ran the following script using SDE under SQL server and it worked without error:
# Import arcpy module import arcpy # Local variables: temp = r"C:\Users\RFAIRHUR\AppData\Roaming\ESRI\Desktop10.2\ArcCatalog\Trans Connection to SQL Server.sde\GDB_TRANS.TRANS.Test_Area" # Process: Calculate Field arcpy.CalculateField_management(temp, "ft", "[Shape.STArea()]", "VB", "")
But I noticed that I have never had a field name called [Shape.area]. In my file geodatabase it is [Shape_area} and in my SDE database it is [Shape.STArea()]. But this could be a difference in the way my SDE administrator set my SDE geometry defaults up.
The script is being run on a computer with an Advanced Desktop license install. I have never used ArcGIS Engine license if that is what you are using. You would have to pose your question to users of Engine if that is what you are using.
This may be an installation option issue. I also do not do ArcGIS installations, so if my IT staff enabled some option that lets my script run that was not enabled when your install was done, I would not know what option that might have been, I only know that with Desktop installs there is a way to get VB Field Calculations to work within Python scripts.
Richard, I tried in sql and got an error:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Here's my python codes for this job in sql:
temp = r'C:\AVM\AVM @ RO_GIS - AVM.sde\avm.AVM.Parcel_PolyOnly_Select_Ident1'
I have never processed a script on a service, only on normal SDE connections through Desktop, so this may be a restriction when you are using services.
In that case, I have no solution for your problem if you are using services other than to run your nightly scripts against the Desktop SDE connection and replicate the result to the service. All versions of python will always simplify all of your true curves when they operate on your geometry and you will see a change the in the area output from what you see in the area field. Your only other option would be to permanently convert all of the polygons with true curves to high density N-gons to get both the VB Script and the Python calculations to return the same reported area shown in the shape.area field.
So if this was all done against a standard Desktop SDE connection you could use a VB Script calculation in a nightly Python script, but the same is not necessarily true for an SDE service. So the details of every aspect of your set up can be significant in determining the cause of the behavior and the different configurations of your data storage, software, database connections, etc. can all play a key role in the behavior of a given process.
Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
