Pixel value sum per buffer is incorrect

[ChristopherBride]

I have a 100m^2 raster of population and a series of buffers: 1,2,3,4,5,10,15,20,25,30,50 km. I am tasked with finding the population per buffer, which I am doing by using the "zonal statistics as table" geoprocess. The pixel value (population) sum decreases between 2km and 3km, and even further 3km to 4km. It then jumps way up to what I would expect to be normal at 5km. I have not gone beyond that because these results are unusable. I have verified that the projections between layers are consistent. I upgraded to the latest service pack and got identical results upon reprocessing. Can anyone help me out with this? This is a seemingly simple and straight-forward process. I've also verified that the scale is all positive (not centered on 0 which would allow negative numbers).

[KeaganAllan]

It really isn't that complicated.

Simply drag and drop in the tools you want to use and set it up as you would have doing it manually.
You will have to set up each process though - for example - if you need 25 buffers, you need to create 25 buffer tools in the model builder.

I have included a very rough diagram, hopefully that helps.
[ATTACH=CONFIG]28718[/ATTACH]
There may be ways to automate the whole process in the builder, although I haven't really tried.
Another option is creating an Add-In using .Net or Python - although once again, I am not sure the effort is worth it.

At least doing it in model builder you can set it up and not have to worry about user fatigue.
If you make a mistake its simply a process of changing the component that is wrong - rather than starting over.

Good luck

K

[ChristopherBride]

I was able to set up for the first 10, seems to be running fine. I have a little experience using python and am trying to find the time to continue with it. Seems that there is an iterator or loop function you need to utilize in order to get the model to go back and run the process again with a new input and output. I wish I had thought of this last week! crunching away....

[KeaganAllan]

Cool,

Hindsight is always 20/20 ...
Good luck with the rest of the process.

On a side note, you can export the model to Python, so that may help in terms of identifying the correct coding structures.

Cheers,

K

[PeterHarrel]

I have found that the zonal functions (zonal stats, zonal stats as table, Tabulate Area) do not work with overlapping polygons as the zones.  It does not handle the overlap correctly. You would have to do each polygon zone as a separate zonal stat, which is a lot more work.  Even though your polygon attribute table sees them as separate polys without an intersection (ie, not a coverage format for example), zonal functions don't deal with it properly.  Too bad - it would be really useful it it would handle this correctly.

[ChristopherBride]

thanks for the feedback pharell123. I have been working with converting the raster into a huge vector layer. So, the polygons with common values (population) are dissolved together. Then I intersect the buffers with the polygons, and calculate population by: (area/pixel size)*pixel value. Since I need to do the stats per province, I also run an identity function and later sum by province name. Seems to be the magic bullet.

[DavidHarbor]

This is late in the game, but the next time you need to create multiple buffers, don't use the buffer tool.  Instead, use the "Euclidean Distance" raster tool and then either reclass the distances or use a nested "con" statement to transform unique floating point distances into discrete "zones" that don't overlap.

[ChristopherBride]

This is late in the game, but the next time you need to create multiple buffers, don't use the buffer tool.  Instead, use the "Euclidean Distance" raster tool and then either reclass the distances or use a nested "con" statement to transform unique floating point distances into discrete "zones" that don't overlap.

that's a really interesting suggestion. I will try it to verify the results I got from turning the raster into a vector layer. Thanks!