Correct garden sizes using intersect, but a step too late!

[SarahRodgers]

Hi GIS forum,

I want to calculate the area of polygons (gardens) for each cell within a 250m grid. I have used the intersect function to ensure that garden polygons overlapping the grid lines are truncated so that there is no double-counting of gardens. Now I have garden polygons that have been artificially split by 250m grid. Unfortunately, when I check the sum of gardens within each grid cell, it tells me the original larger garden size (e.g. 1185 sq. m.) instead of the new smaller sum (e.g. 1060 sq. m.) when the area that should have split off is the difference (125 sq. m.)

But when I recalculate geometry it of course, gives me the 250m x 250m grid size = 62500 sq. m!! Interestingly, if I put in an extra calculation step, e.g. create buffer -1m around all gardens - it then gives me the correct answer - but a step late. I verified this onscreen using the measurement tool.

Can I streamline my method so it I get the correct answer at the point when I expect it?

Thanks,
Sarah

[BruceNielsen]

Sarah,

You must be working with a shapefile. If you put your garden data in a file geodatabase, the area for each polygon will automatically be re-calculated when you do the intersect. Not the area field you created, but the one that is created for each polygon featureclass (usually called SHAPE_Area) in a FGDB. Be sure you assign a projection to the featureclass that is measured in meters also.

[DaleHoneycutt]

You have to 'declare' beforehand what fields need to be reapportioned during an overlay operation.  You do this by using the Make Feature Layer tool to create a new layer, then running the overlay operation with this new layer.  The Make Feature Layer tool has a table where you can check  "Use Ratio Policy" for any of the feature class attributes.  In your case, you would want to use ratio policy for your area attribute (as previous response indicated, you wouldn't have to do this for geodatabase).

Here's a blurg from the documentation:

"Attribute values from the input feature class(es) will be copied to the output feature class. However, if the input is a layer(s) created by the Make Feature Layer tool and a field's "Use Ratio Policy" is checked, then a ratio of the input attribute value is calculated for the output attribute value. When "Use Ratio Policy" is enabled, whenever a feature in an overlay operation is split, the attributes of the resulting features are a ratio of the attribute value of the input feature. The output value is based on the ratio in which the input feature geometry was divided. For example, If the input geometry was divided equally, each new feature's attribute value is assigned one-half of the value of the input feature's attribute value. "Use Ratio Policy" only applies to numeric field types.

[DaleHoneycutt]

Forgot to mention... you're calculating areas.  You can always use the Calculate Field tool to recalculate areas to any units after modifying geometry.  See this blog post for more info

[SarahRodgers]

Thanks for your help both. The FGDB method simply led me back to 62500 sq. m. so I just tried the make feature layer tool and it seemed to work. However, when I completed a spatial join as the next process it all fell apart again. I will try and make another layer file as Dale suggested in the previous step and see if this works again...

[SarahRodgers]

Still no luck