The Missouri Census Data Center has multiple applications that require us to determine if a geographic entity (such as a census tract, block group or block) falls "within" a circular area. Our series of CAPS applications are the most notable programs needing to make such determinations.
Our usual way of handling this is to use the internal point coordinates (centroid) of the entity; we calculate the distance between this point and the center of the circular area, and if this distance is less than or equal to the radius value, then we include the entity. This is an all-or-nothing approach — the entity is either entirely included or entirely excluded.
For example, if we are doing a 5-mile radius of a point in downtown St. Louis, then we look at all tracts in the area and identify all those to be included in our calculations. A tract that straddles the boundary of our 5-mile circle might contain a population of 5,000 people, some of whom live within the circle and some outside. We make a guess that they should all be included or excluded based on the location of the centroid assigned by the Census Bureau. We count on the assumption that there will be multiple tracts that straddle the area and that there will be a balancing of those being included and excluded. It is not a perfect algorithm, but it works fairly well, especially if when using block-level entities (as with our CAPS 2010 and Geocorr applications).
However, in the CAPS ACS application, we cannot use block-level entities, because there is no ACS data at the block level. There are data at the block group level, but not as much as there is at the tract level. So, we use census tracts as the entities to be aggregated when the smallest circle needed is larger than three miles radius (or when the user specifies on the form to use tracts for smaller circles). This can lead to pretty serious problems in trying to approximate, say, a 4-mile circle using census tracts. It is especially problematic in rural areas, where the tracts can be very large. To address this problem, the block-based inclusion algorithm (BBIA) is our approach to selecting and processing geographic entities for approximating circular areas.
The concept is simple enough. We have a "ground zero" location (latitude-longitude coordinates) and we have a data set with, say, census-tract-level data that include internal point coordinates for the tract. Traditionally, we would look at tracts in the area and determine which ones we would select for aggregation (to the n-mile circular area) based on the distance between the tract's internal point and the ground zero point (circle center). If we had data at the block level, we could do this much better, since a typical tract comprises 10-30 blocks, which are much smaller spatially.
Although there are no ACS data at the block level we do have 2010 decennial census data at the block level, including internal point coordinates and the 2010 population count for each block. We also have land and total area in square miles for each block. We use these block-level data to implement the BBIA as follows:
Some interesting things that you will note regarding the BBIA algorithm as used with the CAPS ACS web app: