Hi Everyone,

For a potential school research project, I will have something like rainfall data organized by grid (the orange lines in the picture below). I plan to create a vector grid and have average rainfall for each square--something like this:

Square A: 5 inches

Square B: 4 inches

Square C: 3 inches

Square D: 2 inches

I want to translate this data to a vector shape (polygon) in ArcGIS to something like a census tract that may perhaps lie in multiple squares. After processing, I want to be able to click on that census tract and have it show a sort of "average rainfall" within that census tract. The question is..

How best to do this?

Here's a possibility, and I'd really really appreciate any advice/tips/comments. If I (somehow) convert each square of rainfall grid data to a raster with a set number of pixels..for example Square A would have 100 pixels with each pixel a value of 5. Then, the census tract depicted below would have 55/100 pixels for A. Borrowing this logic for the other portions of the tract lying in the other grids, the average rainfall in the census tract can be summarized by

(Avg rainfall in tract)=(55/100)A+(33/100)B+(28/100)C+(22/100)D

What do you think? I am also a little fuzzy on my raster analysis and would really appreciate any pointers on any analysis tools that may help.

I really appreciate any help, thanks!

# Translating rain fall grid data to polygons

Started by
WholeMilk
, Aug 30 2012 03:22 AM

2 replies to this topic

###
#1
Posted 30 August 2012 - 03:22 AM

###
#2
Posted 03 September 2012 - 01:51 AM

Sounds ok to me. There are functions in ArcGIS for these kind of calculations.

###
#3
Posted 03 September 2012 - 11:54 PM

Hi WholeMilk,

Your method and equation seem like a clever summation of portions of each cell. I add that you might need to consider how finely you divide each input cell, because of a matter of sampling resolution. It might be that 100 sub-cells is fine enough to capture the geometry of the cencus tracts as their borders curve about, or you might need something finer - depends on the complexity of the tract geometry and the resolution of your input rain raster. You can divide to any number of sub-cells (so long as you preserve the square cells by having some number that x^2, where x is the length of one side of a sub-cell); the fraction, when multiplied by the original cell value as per your equation, will define the same portion. A bit of sampling theory might help you decision, or you could overkill it with very fine cells, though that will mean your computer might have to work for a long while, particularly if you do this with ArcGIS.

As you are probably already aware, this is a classic problem in geography. It's worth knowing (and probably noting to your audience) that this method is viable (and clever), but, as with other things geographers have tried, imperfect. (Worth also knowing that no model will ever be perfect!). This is related to the ecological fallacy: your method involves defining sub cells with the same aggregate value as the original larger cell.

As frax has noted, you can easily handle this in ArcGIS with raster resampling, and extraction by polygon mask, sum, raster calculator, etc.

Cheers,

P

Your method and equation seem like a clever summation of portions of each cell. I add that you might need to consider how finely you divide each input cell, because of a matter of sampling resolution. It might be that 100 sub-cells is fine enough to capture the geometry of the cencus tracts as their borders curve about, or you might need something finer - depends on the complexity of the tract geometry and the resolution of your input rain raster. You can divide to any number of sub-cells (so long as you preserve the square cells by having some number that x^2, where x is the length of one side of a sub-cell); the fraction, when multiplied by the original cell value as per your equation, will define the same portion. A bit of sampling theory might help you decision, or you could overkill it with very fine cells, though that will mean your computer might have to work for a long while, particularly if you do this with ArcGIS.

As you are probably already aware, this is a classic problem in geography. It's worth knowing (and probably noting to your audience) that this method is viable (and clever), but, as with other things geographers have tried, imperfect. (Worth also knowing that no model will ever be perfect!). This is related to the ecological fallacy: your method involves defining sub cells with the same aggregate value as the original larger cell.

As frax has noted, you can easily handle this in ArcGIS with raster resampling, and extraction by polygon mask, sum, raster calculator, etc.

Cheers,

P

#### 0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users