Extracting cell values falling within buffer features

[AustinReeves]

Hello all,

I am currently trying to find a tool that will help me with this problem. I have a feature class containing many buffers created from a point dataset. I also have a raster dataset where the cells are classed into simple groups. I am trying to find a tool that will give me an output that contains both the input feature class (buffers) data, along with respective cell counts for each cell class that fall within each buffer. I have tried the "extract by mask" tool, but the output of that keeps no data from the buffers. I was wondering if some tool could keep the same data table format as the feature class in the output, yet still add the cell value counts from the raster overlay. Anything helps! Thanks

-Austin

[curtvprice]

Have you tried Zonal Statistics As Table? You could take that output and join it to your buffer feature class.

[AustinReeves]

I have tried that, however this tool does not give me the stats I am looking for. Specifically what I need is the counts of the top three (or all) represented classes within each buffer. The best option this tool gives me is "majority", which is only the most represented cell class. 

[curtvprice · Accepted solution]

Well if that is what you want, how about the Tabulate Area tool?

If the buffers overlap you may want to look at the NACT toolbox.

[AustinReeves]

Awesome suggestion! That toolbox is perfect for my project! I am currently trying out the Tabulate Features to Percent tool (as my buffers do overlap), and will let you know how it goes! Thank you!

[AustinReeves]

You are a savior sir! Tool works flawlessly. Thank you again. 

[AustinReeves]

Curtis,

One more question regarding the tool. I'm using the Tabulate Features To Percent, and have tried multiple configurations for the parallel processing factor but am not successfully utilizing more than one core on my CPU (of 8). I have read that some tools use a step-by-step process where one task is only able to be run after the previous one has been finished, and I was wondering if this is the case with this tool? Takes quite some time to process ~700 buffers in each dataset I have. Let me know what you think! Thanks

[curtvprice]

So thrilled my old toolbox is working for you!

My python script processes the buffers one at a time and does not do this with multiprocessing (this is kind of tricky in Python especially with tools launched the usual way from a toolbox). If you can separate your buffers into non-overlapping groups you can assign each buffer an index number to process in groups. I have not implemented multiprocessing but even doing non-overlapping groups sequentially would be a LOT faster than one by one. I do not have a tool unfortunately to find the non-overlapping groups.

Multiprocessing in the ArcGIS environment s a lot easier to implement in C++ (as opposed to python script tools -- there are several geonet threads on this) and the current Pro 2.5 version of Zonal Statistics is supposed to allow for overlapping buffers, maybe when the term is over I will update my tool to take advantage of that.

[AustinReeves]

That's what I had suspected on the multiprocessing for this tool once I realized the parallel processing wasn't doing anything. I have also read some of those threads regarding C++ vs Python and associated difficulties with coding multiprocessing with Python. 

My buffers are grouped via year (water sample date) and finding specifically the non-overlapping would indeed be tedious. I think I will stick to the slower process for now as it is still faster than me finding/grouping the specific buffers. The Zonal Stats tool does take advantage of overlap as it works on my datasets (quite fast at that) and believe it would very well be possible for you to implement in your toolbox. Thank you for the confirmation though! 

[curtvprice]

Note that since these are point buffers, you could filter the points with the Weed Points tool included in the toolbox, at least to get one weeded group to do at once before doing the rest sequentially. I mention this because this may save you days of processing.