nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Trouver plus de publications taguées avec

Accepted answers

All comments

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!

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

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.

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.

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

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

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

EGModel.jpg

ChristopherBride

I've never done that outside the classroom. What a great idea! I don't really know that much about it, but I am learning a lot in this whole process. I can set it up for one buffer. How would I set it up to loop the process for all 10 buffers and then do it again for a second raster?

KeaganAllan

Glad to hear you came right.

Just a thought, would it be possible to set up the whole process in model builder to avoid user error?

Good luck with the work.

Cheers

ChristopherBride

Update: I systematically chose the previous buffer to create the next one. I was doing 30 buffers, and I lost track of what I was doing. Thanks for your input! It was user error.

ChristopherBride

I really wish I could attach the shapefiles, but the data is proprietary and I had to sign a non-disclosure agreement to get this gig (its with an NGO)

KeaganAllan

Hi,

I know the feeling.
I was assuming the point was coming from a single point and not a series of points.
Unfortunately I cannot get to my PC, but in the morning I will have a look and see what I can come up with.

Would it be possible to post your buffers / section of the buffers for me to look at?
Regards,

K

ChristopherBride

(yes, I am sitting on top of this thread to find a solution!)

All of the buffers are already dissolved, so that essentially I am dealing with discreet, non-intersecting polygons. The layer I used that has intersecting polygons accurately (as far as I could tell) sums of the population. Kinda odd. The problem of course is that i cannot add the population sums together because a huge portion of them would be counted 2,3,4 times over. Also, the individual processes should have no knowledge of the other buffers, they aren't present as an input.

KeaganAllan

Hi Christopher,

I am not a "Zonal Statistician", but just from working through some of my own examples, it seems that the way the Zonal Statistics to Table geoprocessor looks at the overlaps in the input and will report on only the the overlapping areas.

In this case, your 50km Ring Buffer may be the only one it is giving a result to.
A solution - albeit a long process - would be to cut out the smaller buffers from the larger buffer resulting in a single buffer dataset containing a series of "Donut" Polygons. (This is assuming you have the buffers in a single dataset - either merged buffers or buffers created in the multi-ring buffer tool).

This dataset could then be used to run the Zonal Stats to Table and then using Excel or a similar spreadsheet application calculate the cumulative population stats per polygon.

If I have missed your question, I apologise.

Let me know how it goes, I enjoy hearing how some of the tools in the toolbox are being used.

Cheers,
K

PS - Sorry something occurred as I re-read your original post...it could be the cell size of you Raster dataset? 100m^2 may result in some errors in the smaller buffers?
Have you checked the larger buffers to make sure?
Maybe try dropping the cell size of your raster and see if that makes a difference?

ChristopherBride

thanks for responding. The buffers were generated through the buffer geoprocess, one by one. Another question I will post later is "why won't 'zonal statistics as table' work on multi-buffers? i have not triedthe straight zonal stats. I'll look into it.

KeaganAllan

Hi Christopher,

Just a quick question, how were the buffers generated?
Have you tried using the straight Zonal Statistics using the buffers as the input feature?

Thanks,
K

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.