Summarize population density within a watershed boundary

4780
4
08-27-2012 01:51 PM
AndyBell2
New Contributor
Hi All,

I am looking for a way to calculate population density within a watershed (and sub-watersheds). I currently have the polygons deliminating the upstream sub-watersheds from several monitoring points along the creek. In order to quantify disturbance at the sites, I want an estimate of the number of people per area that live upstream.

The population data that I am using is Census 2000 GIS Block Data for the state of California. Attribute data include population size, housing units, etc. The issue that I am struggling with is how to deal with the census blocks that are split by the boundary of the watershed.

I am hoping to have something like http://resources.esri.com/help/9.3/arcgisserver/apis/javascript/arcgis/demos/geoprocessor/gp_zonalst... except being able to control the polygon.

-Andy
0 Kudos
4 Replies
GregoryLund1
New Contributor III
Hello Andy,
I read, with interest, your question and have a few ideas.
My initial thought was suggesting you use 2010 Census data available from the Census.gov.

As for your analysis, depending on how accurate you'd like the information, you could merely split the block data by area using the watershed boundary and call it good.

There is a tool similar to the one you posted at: http://egisws02.nos.noaa.gov/socioeco/genericProfile.html?datasource=censustrends, but I am not sure if your intended area of study is available.

Last but not least, myself and a few others may begin collaborating on a tool for a local non-profit that ideally will work on any watershed, taking several other factors into account to determine a more accurate population estimate than merely dividing up the blocks by % of area of said block within the watershed.

I am interested to hear input from others.
Greg
0 Kudos
JeffreyEvans
Occasional Contributor III
I would be very cautious performing a direct aggregation between census block and watersheds. This is a classic example of the Modifiable Areal Unit Problem (Openshaw 1984; Cressie 1996) issue and could yield unstable results. One option to mitigate MAUP is to use an areal interpolation technique such as dasymetric mapping (Reibel & Agrawal 2007). 

USGS Dasymetric mapping ArcGIS tool
http://geography.wr.usgs.gov/science/dasymetric/data.htm 

References:
Cressie, N. (1996) Change of Support and the Modifiable Areal Unit Problem. Geographical Systems, 3:159-180.

Openshaw, S. (1984) The Modifiable Areal Unit Problem. Norwich, Geo Books ISBN 0-86094-134-5.

Reibel, M., and A. Agrawal (2007) Areal Interpolation of Population Counts Using Pre-classified Land Cover Data. Population Research and Policy Review, 26(5):619-633
0 Kudos
GregoryLund1
New Contributor III
I would be very cautious performing a direct aggregation between census block and watersheds. This is a classic example of the Modifiable Areal Unit Problem (Openshaw 1984; Cressie 1996) issue and could yield unstable results. One option to mitigate MAUP is to use an areal interpolation technique such as dasymetric mapping (Reibel & Agrawal 2007). 

USGS Dasymetric mapping ArcGIS tool
http://geography.wr.usgs.gov/science/dasymetric/data.htm 

References:
Cressie, N. (1996) Change of Support and the Modifiable Areal Unit Problem. Geographical Systems, 3:159-180.

Openshaw, S. (1984) The Modifiable Areal Unit Problem. Norwich, Geo Books ISBN 0-86094-134-5.

Reibel, M., and A. Agrawal (2007) Areal Interpolation of Population Counts Using Pre-classified Land Cover Data. Population Research and Policy Review, 26(5):619-633


Exceptional points, and thank you for the references, they will be valuable as we proceed.
Modifiable Areal Unit Problem's when 'splitting' US Census blocks are exactly what we're hoping to resolve.

Regards,
Greg
0 Kudos
GregoryLund1
New Contributor III
Andy, et.al.,
I am following up on your original August 2012 Post.

The esri tool link you provided, does not allow the user to input a specific boundary, and it is unknown if the tool uses the pro-rated area to calculate the population.

An alternative is the NOAA 'Quick Report Tool' @ http://egisws02.nos.noaa.gov/socioeco/genericProfile.html?datasource=censustrends, but as noted by Jeffrey Evans, the tool does not take into account where within the population resides within the Census Block. This tool pro-rates the population by area. Splitting the blocks by area and pro-rating the population of each by area is problematic because the portion within the boundary (Watershed) may or may not have an equal amount of population as the portion outside of the boundary.

A similar 'tool' is available from the Washington State Department Office of Financial Management. They developed the 'Small Area Estimate Program' (SEAP) which forecasts population data over time, however it too relies on the pro-rated area for boundaries that cut across known population units. (And is only available for WA State).

As a solution in progress, I, along with Rick Hollatz, Alyssa Tanahara and Jim Goldsmith have created a tool that uses Water Features, Land-Use Data and Slope when determining where the population likely lives, prior to splitting the Census Blocks.

Our results were as follows:
The NOAA Quick Report tool indicated that the 2010 population of WRIA 9 in WA State was 417,850 people.
The Office of Financial Management (SEAP) indicated that the 2010 population of WRIA 9 in WA State was 579,064.
Our Area estimation (similar in functionality to NOAA and the SEAP tools) indicated that the 2010 population of WRIA 9 in WA State was 580,637. (Completed for comparison.)
We are not 100% sure as to why NOAA's tool results differed from the SEAP and our tool (using the same methods) by over 150,000 people (for the same WRIA unit).

Finally, our Areal Interpolation tool (Taking Water Features, LandUse and Slope into account) indicated that the 2010 population of WRIA 9 in WA State was 580,494.

While it is only set up for WA State, it could, theoretically be used in others.

You are welcome to contact me through this forum and I will gladly communicate to the other members of our team.

Regards,
Gregory Lund (gwlgis@uw.edu)
0 Kudos