# Calculating kernel density for polygons in ArcGIS Desktop [closed]

I have a population data set at the census block level. My goal is to use the data set to identify some population centers in the region based on population density. The simplest way to do it is to calculate the density by census blocks and use an arbitrary density cut-off value to determine those centers. One shortcoming of this method, however, is that it relies on census blocks, which have irregular size and shape.

The other approach I am thinking of is to covert census blocks into points based on their centroids, and calculate kernel density based on these points. But I am not sure if this makes sense.

In other words, does this approach help me overcome the problems that are associated with the first approach?

Also, if it makes sense to do that, how the output raster size should be determined?

• How large is your region? The resulting KDE will need a bandwidth and cell size, both of which will be dependent on study area and number of observations within the area. – Barbarossa Mar 7 '14 at 20:06
• @Barbarossa This is a census, not a sample: it represents what is known about the entire population at the finest level of detail. If a density method is chosen to represent these data, choices of bandwidth and cellsize ought to be based on considerations other then numbers of census blocks in the area. – whuber Mar 7 '14 at 20:32
• @whuber I agree. I understand the surface is to be based on population density. I thought that the number of observations might be of interest in case an adaptive bandwidth was chosen. – Barbarossa Mar 7 '14 at 20:40
• Thanks for the reply. The study region has about 230,000 blocks. The mean size of blocks is 372199 m2 (about 600mx600m). should I consider the size of blocks when I decide on the cell size of the raster output? – Gary Mar 7 '14 at 22:09
• Rather than respond in Comments, I think it will be better to use the edit button beneath your Question to revise it with these additional details. – PolyGeo Mar 8 '14 at 1:40

The biggest difficulty is that blocks can range widely in extent, from portions of a city block (only a few tens of meters across) to many kilometers in rural areas. When the cellsize is not small enough to capture every single block polygon (or centroid) and uniquely represent it, data will be lost--and lost in a biased fashion (that is, in regions of high population density). However you proceed, the key is to avoid this data loss. Unfortunately, using a sufficiently small cellsize can be prohibitively expensive when the study region is of large extent, creating a grid with very large numbers of rows and columns.

One of the more convenient solutions is first, as a preliminary matter, to convert the block polygons to a raster at the smallest practicable cellsize. The values in this raster are the polygon identifiers. By joining the raster attribute table to the original polygon attribute table you can identify any blocks that are not represented on the raster. A spatial join of those missing blocks to the nearest blocks that are represented will enable you to add the populations of the missing blocks into blocks that are on the raster. In this fashion, when the conversion to raster is redone using the (adjusted) block populations for the values, all the population will be counted within that raster. As a check, its total population should equal the total population of the original block features.

At this point, divide the populations in the raster by the block areas as computed in the original raster itself. (These block areas can be found by multiplying the [count] field in the raster by the square of the cellsize.) This division thereby produces a raster of population densities. If you used a very small cellsize, you might want to aggregate these densities onto a coarser grid for further analysis. Use a cellsize that is an integral multiple of the original cellsize (to avoid resampling issues) and request the mean as the aggregation statistic.

As a final check, the sum of all values in this population density grid, when multiplied by the square of the cellsize, should be very close to the original total population. (Some small error, typically around one to ten parts per million of the total, usually arises due to single-precision floating roundoff.)

An alternative solution performs the conversion of blocks to raster using a set of different grids adapted to the cities and the countryside and then aggregates these and mosaics them.

Solutions based on block centroids are usually not advisable due to the widely varying spacing between blocks and because the same problems pertain in the high-density areas: points that fall into a common grid cell are often lost (although improvements to Spatial Analyst might have overcome that problem by now, or will overcome it in the future).

Data aggregation or the classics of discrete data symbolization (Dot Density, Proportional Symbol or Graduated Symbols) may be a possibility.

Not sure if that answers your question but it could be another way to look at the symbolization and data standardization for your data set/AOI.

• The goal is to identify boundaries of population sub-centers. The purpose of kernal density calculation is to reduce variation within the data set. So symbolization may not work. – Gary Mar 7 '14 at 22:32