Geoprocessing: Geometry Field updates

[CraigEissler]

After Geoprocessing (trying various Tools) I notice that sometimes the Geometry Fields (Area, Length, etc.) are automatically updated for the new Feature record and sometimes they are not. ...Why is this?

Is there some concept to understand or List that explains which types of Tools provide these geometry updates and which do not?

Thanks!

[RichardFairhurst]

After Geoprocessing (trying various Tools) I notice that sometimes the Geometry Fields (Area, Length, etc.) are automatically updated for the new Feature record and sometimes they are not. ...Why is this?

Is there some concept to understand or List that explains which types of Tools provide these geometry updates and which do not?

Thanks!

If you output to a geodatabase feature class you should have a set of these fields that should always update.  If you create a shapefile these field should never update on their own.  They have become a snapshot of the geodatabase fields only and will now only update if the user does recalculations from the shapefile's shape geometry field.

If the area/length fields are simply copies of field values that prior to the tool were tied to geometry, but the tool only copied them in an operation that simply appended attribute values to another set of attributes, they have simply become another user updated attribute.  They are no longer tied to any new geometry and they will never update again.  They are a snapshot only and have names slightly modified from the original true area/length fields if they appear in a geodatabase feature class.

If you think you have seen a tool that violated these rules, let me know.

[CraigEissler]

Thanks for that info. Hmmm, you've got me thinking.

...By "copy" of a Field, so do simply mean the User made a copy of that Geometry Field, so its no longer the authentic field automatically generated by ArcGIS? ...If so, is there an example of when a User might do this? ...or see below:

How about when a User wants to re-calculate Area in different Units, but wants to create a New Field to populate, so as not to disturb the original Field values, and with the advantage of renaming it something distinguishable like "Area_sq_mi" ...would this have the "copy/snapshot effect" and no longer update automatically after running another Tool?

[RichardFairhurst]

Thanks for that info. Hmmm, you've got me thinking.

...By "copy" of a Field, so do simply mean the User made a copy of that Geometry Field, so its no longer the authentic field automatically generated by ArcGIS? ...If so, is there an example of when a User might do this? ...or see below:

How about when a User wants to re-calculate Area in different Units, but wants to create a New Field to populate, so as not to disturb the original Field values, and with the advantage of renaming it something distinguishable like "Area_sq_mi" ...would this have the "copy/snapshot effect" and no longer update automatically after running another Tool?

The only real geometry field is the Shape field.  In a geodatbase, the Area\Length fields are special attribute fields that ArcMap controls.  They cannot be created by the user or renamed by the user.  The Units shown by those automatically updated fields can only be in the underlying feature class units.

No user created fields can be automatically updated by changes to geometry without some kind of add-on extension that is not part of ArcMap out of the box.  If you add fields like you proposed without an add-on extension that listens for geometry changes and updates them, they would never be automatically updated and would always have to be manually updated using the Geometry Calculator or Field Calculator.

Some tools can run and transfer the values in the Area/Length fields to new outputs as though they were a normal attribute field.  If they are transferred to a new geodatabase feature class the tool renames the static values to something like Area_1/Length_1.  These fields will no longer be automatic but the normally named Area/Length fields that will also be in the feature class will be automatic.

Tools that output to Tables or shapefiles will either drop the Area/Length fields entirely, or turn them into mere attribute fields that are not automatically updated anymore.  So any time you see fields named Area/Length in those types of outputs they are static attribute values that the user must update manually.

I often want a static Area/Length values in operations like Union or Intersect where an original geometry gets cut up.  The static value that is from the original shape and not updated to reflect the new cut up shape lets me determine what percentage of the original polygon is in each of the cut up pieces.  I believe several of the overlay tools create the static copies of the original polygon Area/Length field values just for this purpose and if they don't preserve the original values I create my own fields and calculate those values into them prior to running these kinds of tools.  Sometimes the only reason to run a tool is to compare the tool output to the tool input.

[CraigEissler]

Thanks again for your reply. This makes total sense now.
...Note: yes, I'm using Geodatabases.

On a related note, I think I've learned that if I also want other (non-Geometric) Attributes to get updated by parsing the values according to the proportion of the area/length geometric split, that I cannot do that using the Geodatabase Split Policy since that is only valid for Editing. However, if use the 'Make Feature Layer' Tool, I can set a Ratio Policy to re-distribute the Attribute Values for features that were split during geoprocessing. But I wonder why this is not an option in the geoprocessing tool (like Intersect or Union) itself?

[CraigEissler]

...Well, wait a minute 😉

I just geoprocessed two Shapefile polygons (using Intersect) and noticed that 3 new Fields were added (2 Lengths and 1 Area).

I was under the impressions Shapefiles would not create new or re-calculate geometry ...that this was only possible using Geodatabases.

Anyone have an explanation?

[RichardFairhurst]

...Well, wait a minute 😉

I just geoprocessed two Shapefile polygons (using Intersect) and noticed that 3 new Fields were added (2 Lengths and 1 Area).

I was under the impressions Shapefiles would not create new or re-calculate geometry ...that this was only possible using Geodatabases.

Anyone have an explanation?

Those fields are static and not tied to the geometry anymore.  They are copied from the original line and polygon inputs like any other number field.  That is possible for all data types.  What is not possible is to make an automatically updated Length of Area field tied to the geometry in a Shapefile.  They don't support it. 

Only geodatabases have auto update versions of those fields and you cannot add them or delete them.  But you can add more copies of them as static fields under names the geodatabase did not assign.

The rules I have explained are not being violated.  You can have as many static versions of those fields in any data type that you want and even in Standalone tables, but the static versions never again interact with the feature geometry when you change it.

If you can change the shape of a feature in the Shapefile and see the Length or Area field update as a result without any extension or manual updating, only then have you experienced something that violates what I have explained and I would be surprised.

[CraigEissler]

OK, I see now that those Fields were transferred from the original Input polygon Layers.

And after further review I now see that some of the new Geometry Fields "appeared" to have been re-calculated because I had verified that their values were indeed correct! ...But as I scrolled down to investigate other Features/Records, I started to see some that were not correct. So, I think what I am seeing is that the result of the Geoprocessing > Intersect did not alter some of the features to their geometry values are still valid, but it did others, as well as add some brand new Features/Records, and those are not valid ...and would only be if I re-calculated their geometry.

...Am I back on the right track?

[RichardFairhurst]

OK, I see now that those Fields were transferred from the original Input polygon Layers.

And after further review I now see that some of the new Geometry Fields "appeared" to have been re-calculated because I had verified that their values were indeed correct! ...But as I scrolled down to investigate other Features/Records, I started to see some that were not correct. So, I think what I am seeing is that the result of the Geoprocessing > Intersect did not alter some of the features to their geometry values are still valid, but it did others, as well as add some brand new Features/Records, and those are not valid ...and would only be if I re-calculated their geometry.

...Am I back on the right track?

Yes.  In all likelihood the Intersect processing uses the fields in its process to divide a feature multiple times and updates that field to do some internal check of the next division iteration.  If the input was a geodatabase then it would have recalculated in the next iteration automatically and the new value would be turned into a hard number. 

Its a black box, so that is just a guess.  In any case, when I want to preserve a Length value I calculate it into a field that I know won't be changed by the tool.

[CraigEissler]

OK thanks.

I guess the last thing I'm wondering is why 'Calculate Geometry' function is sometimes grayed-out? In other words, what if I need to re-calculate the Shape_Area or Shape_Length Fields in a Shapefile, or wish to use different Units (like Sq. Mi. or Acres) in a Geodatabase?