1

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.

  • 1
    I'd vectorised NLCD first and intersect it with meshblocks. Moving population inside resulting vectors is easy. – FelixIP Apr 8 '15 at 0:22
  • @traggatmot You can use reclassify to nullify raster cells (or alter them to other values). – dof1985 Apr 9 '15 at 22:14
  • If you feel like editing/adding to you answer more information about the complete workflow I can mark it as the solution. – traggatmot Apr 9 '15 at 22:16
  • Please add some links and better explain the acronyms used. I.e., what is NLCD and where can I find it. Yes, I can search. But for the sake of completeness and consistency, I think it's better to provide such information in the original question. – Nikos Alexandris Oct 5 '18 at 9:00
4

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.

  • It appears that I could use your answer in tandem with dof1985's answer, right? I could use his suggestion to calculate the real density of each zone (census block) after having nullified areas where the density values/population counts should apply - coming up with a new density value. Then I could apply your solution to weight the final raster by the land cover. Does this sound like a workable merge of the ideas? – traggatmot Apr 10 '15 at 19:46
  • Yes, you could--but you don't have to do it so inefficiently. Any land cover classes to which you assign a relative density of zero would automatically be nullified. Thus you could proceed directly to apply my solution without any preliminary work. – whuber Apr 10 '15 at 21:02
  • Hmm. I had added another comment where I figured that out, but I guess it didn't take. But yes! I see that's the way to go! – traggatmot Apr 10 '15 at 21:21
  • 1
    Got it all worked out! Amazing!! – traggatmot Apr 11 '15 at 3:12
  • 1
    @Nikos Research "dasymetric mapping" (bearing in mind it's frequently misspelled with various numbers of s's and m's). The idea is to exploit spatial patterns in overlaid, correlated grids to perform the downscaling. – whuber Oct 5 '18 at 12:57
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:

Data

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: TABLE

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.

  • 1
    See my edits above. You may have solved part of this for me. The rest I think I can figure out. Thanks! – traggatmot Apr 9 '15 at 21:07
  • How would you handle blocks that overlap with or sit between two different polygons? Is there a way to assign them to both or either? or to split the area appropriately between the polygons? Which would be the preferred method. If splitting them appropriately isn't an option, I suppose I could resample the 30m by 30m NLCD data into 1m by 1m cells to more precisely assign the living/working from non-living area. What do you think? – traggatmot Apr 9 '15 at 23:01
  • @traggatmot, I'm not sure - but I think it is slightly a different question; you might either update your question to include it (preferably with an image that shows it), or (for my taste) open a new question about it. You might also pursue other opinions about editting or asking a new question using the Meta GIS.SE. – dof1985 Apr 10 '15 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.