After turning census block data into a raster, how do I redistribute the density to reflect land cover types

Question

I plan on rasterizing (terminology?) census block data relating to density to a regular 30 m by 30 m grid for use with NLCD data. I then hope to distribute the density of the original census block among each result set of grid cells within the original polygon according to the land cover type dictated by the NLCD dataset. For example, let's imagine a string of city blocks with a park, all found within one census block. If within this census block the average density is 1000 people/km^2, we ultimately would want the resulting grid cell containing the park to have a lower population density than the grid cells containing the surrounding apartments. This information may be captured by the NLCD dataset, with the park being classified as '21' (open but developed land) versus 24 for apartment buildings which could be classified as '24' (high density development). Is there a method, or set of methods, within ArcMap that would allow me to:

• Redistribute the density based on the NLCD value
• Perform this redistribution only within the original census block polygon

I don't know if this is possible, but I figured I would ask.

Edit

Here's what I have been trying:

I converted the census block data to a raster, snapping it to the NLCD land cover data and ensuring the output grid cells were the same size. Each cell contains the same info as the original census block (housing umbers, population, etc). I have been trying to figure out a way to edit the new grid so that if the NLCD grid cell contains a land cover type that doesn't support a business or housing (park, forest, farm, etc.) that it's housing and population values area set to 0. My next move was going to be figuring out how to subtract the non-residential/non-business grid cells area from the area of the original census block, and force a recalculation of the density. Converted the altered census block layer to grid cells again, with each having the new density value, and once again set the cells' housing, population, and density values that don't support a business or housing (park, forest, farm, etc.) to 0.

Kind of circular, and I'm not sure of all the steps (raster calculator for editing individual grid cells based on another raster's grid cell value?), but it seems to logically work out if I can get the parts to work.

On the other hand, @dof1985's answer seems to simplify the first part of my workflow (by directing me to the correct toolset), but I will still have to nullify the grid cells where parks, etc., do exits after the density has been recalculated for the census data.

Answer 1

You have two inputs:

1. A polygon layer of Census counts.

2. A classified land cover layer.

You would like to perform a kind of dasymetric mapping in which the output is a density raster. It has two defining properties:

1. The integrated density over each Census block should equal the original count.

2. The different types of land cover should have differing densities associated with them.

There are several ways to quantify (2). One expedient would be to assign a table of relative densities to the land cover types. For instance, suppose there were three types of land cover: high population density, low density, and unpopulated. Then you might assign relative densities of 10:1:0 to these types. You will have to obtain the proper densities in some way, perhaps via statistical analysis of other data.

With this approach, the solution is relatively simple:

1. Create a density grid for the Census data by dividing each polygon's count by its area and converting that directly to raster format.

2. Create a relative density grid for the land cover data by joining the relative density table to the land cover type identifier.

3. Multiply the two grids (1) and (2).

4. Compute a zonal sum of the product in (3), using the Census regions as zones. Store this as a raster rather than a table.

5. Multiply (3) by the Census counts, divide by (4), and divide by the cell area.

Why does this work? It should be clear that the values in (3) give the correct relative densities within each polygon, because (a) the value of (1) in each polygon is constant and (b) the value of (2) gives the relative densities. Dividing by the zonal sum (4) gives a set of non-negative weights that sum to unity within each polygon. The products in (5) adjust (or "normalize") these weights to make the sum of the values, times the cell area, equal to the total count in each polygon. Thus the final result is indeed a density grid that correctly reflects the original Census counts, while varying the densities (within each polygon) according to the land cover type.

This approach can fail in two circumstances:

1. Some polygons may disappear in conversion to raster format. This happens when a polygon contains no center of any raster cell. One solution is to use a finer resolution for the grid. Another is to combine such polygons with one or more of their neighbors, which can be done in various ways.

2. A polygon with a nonzero count is covered only by land cover types with zero density. This is an inherent inconsistency between the two inputs, so the procedure had better fail! In most software you will get NaN or NoData values to indicate the problem.

Answer 2

I suggest a different work flow. That is, I assume you have the Spatial Analyst. The workflow is based upon the tool: Tabulate Area. Note that using the tool with your polygon layer, i.e. blocks, will automatically convert those to a raster, thus it is better if you would manually convert it, in order to have control on the output.

My data is a 2 block polygon layer, each has a population density field; also I have a "NLCD" data (not real data), contain 3 raster Values, namely: High density residential (green), Desnsity and Commercial Mixed use (blue), and Park (red). See image below:

I used the Tabulate Area tool to count the cells by Value in each polygon (Zone); I have used join to relate the blocks attributed table with the output table of the Tabulate tool (PK= ObjectID; FK= ObjectID_1). Joint table presented here:

In a new field (float/double) I have calculated the "new area" or "living effective area", using the following if-block:

def NewArea(x,y,Z,area):
   if (Z>0):
     return(((x+y)/(x+y+Z))*area)
   else:
     return(area)

It basically checks if there is a park (Z variable) count in each block, and if so it ignores it to compute the effective living area (that is based on ratio of the living pixels to the total pixels).

Use this code in the calculation window (field calculator):

NewArea( !Dns_resi!, !Mix_resi!, !Park!, !SHAPE_Area!)

Note that if you have more than one land-use that should be igonred, the code should be modified.

Based on the "new area" it is easy to re-calculate the population Density as follows:

!Density!* !SHAPE_Area!/ !Fixed_area!

Note that both codes are using python.

The result was that parcel 1 population density has been raised from 1000 to 1333, while parcel 2 density wasn't altered.