topic Geoprocessing: Geometry Field updates in Geoprocessing Questions

Geoprocessing: Geometry Field updates

CraigEissler — Sun, 09 Mar 2014 22:36:45 GMT

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!

Re: Geoprocessing: Geometry Field updates

RichardFairhurst — Mon, 10 Mar 2014 00:44:21 GMT

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.

Re: Geoprocessing: Geometry Field updates

CraigEissler — Mon, 10 Mar 2014 16:29:12 GMT

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?

Re: Geoprocessing: Geometry Field updates

RichardFairhurst — Mon, 10 Mar 2014 17:23:27 GMT

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.

Re: Geoprocessing: Geometry Field updates

CraigEissler — Mon, 10 Mar 2014 22:16:14 GMT

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?

Re: Geoprocessing: Geometry Field updates

CraigEissler — Sat, 15 Mar 2014 18:06:27 GMT

...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?

Re: Geoprocessing: Geometry Field updates

RichardFairhurst — Sat, 15 Mar 2014 22:35:26 GMT

...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.

Re: Geoprocessing: Geometry Field updates

CraigEissler — Sun, 16 Mar 2014 00:34:55 GMT

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?

Re: Geoprocessing: Geometry Field updates

RichardFairhurst — Sun, 16 Mar 2014 02:59:00 GMT

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.

Re: Geoprocessing: Geometry Field updates

CraigEissler — Sun, 16 Mar 2014 16:23:30 GMT

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?

Re: Geoprocessing: Geometry Field updates

CraigEissler — Sun, 16 Mar 2014 16:32:43 GMT

...Ok, I'm going to partially answer my own question.
First f all, my data is projected, so that's not the reason. I read now that the reason is because these are ArcGIS managed fields.

Ok so now I'm back to my original dilemma ;-/

It seems if I'm working with Shapefiles (which I will now try to avoid like the plague) I will have to make a pseudo-copy of those Fields and Calculate Geometry and just know that those original ArcGIS Geometry Fields are bogus from here on out. And my new User-defined Geometry Fields will potentially be bogus in the future if I do further geo-processing.

And if I'm working with Geodatabases, I will only need to do the same "if" I desire to see geometry values in different units. My original ArcGIS Geometry Fields will be dynamically valid with potential future geoprocessing, but my User-defined Fields will have the same behavior as they would in a Shapefile as described above.

Sound correct, ...finally? 😉

Re: Geoprocessing: Geometry Field updates

CraigEissler — Sun, 16 Mar 2014 16:48:17 GMT

haha, now I'm answering my own question again!

It looks to me like you CAN edit (Calculate Geometry for) a Shapefile's ArcGIS-managed Geometry Fields, but you CANNOT edit (Calculate Geometry for) a Geodatabase Feature Class.

...So now the Shapefile doesn't sound quite as bad as the plaque, but the Geodatabase still has the advantage of having "valid" ArcGIS-managed Geometry Fields, even though they may not be the Units you desire. ...In other words, square feet and square meters are are pretty small units for covering large areas.

Re: Geoprocessing: Geometry Field updates

RichardFairhurst — Sun, 16 Mar 2014 17:22:20 GMT

haha, now I'm answering my own question again!

It looks to me like you CAN edit (Calculate Geometry for) a Shapefile's ArcGIS-managed Geometry Fields, but you CANNOT edit (Calculate Geometry for) a Geodatabase Feature Class.

...So now the Shapefile doesn't sound quite as bad as the plaque, but the Geodatabase still has the advantage of having "valid" ArcGIS-managed Geometry Fields, even though they may not be the Units you desire. ...In other words, square feet and square meters are are pretty small units for covering large areas.

That is correct. If you want other units create your own double field and calculate it to the units you want as a static value. I never use shapefiles as a matter of sanity. They perform horribly and I tell everyone to stop using them.

Also, in a geodatabase feature class if you have to calculate your own units in a static field and know the conversion factor you can find all of the outdated values with a simple SQL query against the native length field. I.e,

ABS(Length_Miles - Shape_Length / 5280) > .001

This find all values where the shape length has changed by more than 1/1000th of a mile if my native units are in feet. Then you can just recalculate the Miles field for these records that changed over your tolerance and don't have to recalculate everything. This is also a good way of making sure you have posted date stamps to all of the recent changes if you do that. Shapefiles cannot do this. You have to calculate every feature every time to be sure you are fully up to date on any field tracking geometry and cannot detect just the changes for date stamping.

Re: Geoprocessing: Geometry Field updates

CraigEissler — Mon, 17 Mar 2014 15:35:59 GMT

OK great -- I got it now
Thanks for all your help!