ACS Data Users Group

I have geospacially clipped census blocks into a new geography to estimate the population for the new area (new area/old area * population estimate).

Is there a method to calculate the new margin of error for these new estimates?

ACS does not report block-level estimates or MOEs.

Hi!

To calculate margins of error for derrived estimates (such as when you group across geographies) see Chapter 8 of the Handbook

https://www.census.gov/content/dam/Census/library/publications/2018/acs/acs_general_handbook_2018_ch08.pdf

It provides formulas and examples.

Hope that is helpful.

It seems like Chapter 8 of the handbook deals with aggregating whole geographies (unless I'm reading it wrong) and it seems like OP is wanting to aggregate whole geographies and some 'clipped' or partial geographies. Am I correct in thinking that if it's not included in the handbook, then it's not recommended to work with partial tracts / geographies?

I don't think the handbook--by this omission--is intentionally trying to comment on the appropriateness of working with partial geographies. More to the point, the statistical principles guiding how to adjust MOEs when aggregating whole units are straightforward and easy to specify. The principles guiding MOEs for partial units are entirely unsettled. I took a stab at this issue, indirectly, in this 2007 paper. I don't know of much other research on this specific subject. In short, it depends on exactly how you're disaggregating from the whole to the parts, and the simplest approaches tend to be highly error-prone, so the MOE will tend to grow much larger than if you stick to whole units. Using partial units may still be adequately accurate for many applications, but to my knowledge, no existing literature or formulae will tell you exactly how to determine that.

Ah! Gotcha. Somehow I missed the "clipped" part and assumed they were doing point-in-polygon (whole block). The issues with using partial blocks are FAR greater than those of aggregating MOE. Population and housing are rarely distributed evenly within a block.

Beth Jarosz and Jonathan Schroeder,

I'm facing a very similar issue to OP and am following up here to inquire whether you're aware of any research on the subject of estimating MOE for geographies derived from polygon intersections (i.e., in Beth Jarosz's example above using partial blocks). In my case, these intersections are derived from ACS block groups, city council districts, and neighborhood boundaries. I understand this will result in large MOE, but these are the data I'm dealing with.

Feel free to advise this should be a new post all-together if you feel that's more appropriate (it just seemed in line with OP's inquiry and this line of conversation).

Thank you for any and all guidance!

I still know of no simple general guidance for estimating MOEs for disaggregated (i.e. split) summary data.

Through IPUMS NHGIS, we distribute geographically standardized time series tables, which provide 1990-2020 census statistics for 2010 geographies (census tracts, block groups, etc.). We do this by aggregating block data from each census year. In many cases, the source blocks are split among multiple 2010 units, so we apply interpolation to estimate how the source data are distributed among target units. We don't compute MOEs, but we do report lower and upper bounds, determined by assuming that either all of the split blocks' population and housing are in a given target unit (the upper bound) or none of the split blocks' characteristics are in the target unit (the lower bound). That's a simpler concept and easier to compute, so you may want to use that. The downside is that these bounds can be very large, and typically much larger than the actual statistical "90%" MOE.

If the areas are measured without error you can multiply the Est and MoE by scale factor new_clipped_area/old_area. This assumes that the population is distributed uniformly across the large area. You can calculate the area of intersections using the "sf" R package.

To do better than this you need to know the spatial distribution of the population within the large area. For geographies larger than blocks one way to get is to use decennial census block level counts for the blocks that make up the larger area and the "clipped" area. You can then calculate the scale factor as population_in_clipped_area/population_in large area. Geocorr does this for the available types of geographies in their system. You can get "afact" scale factors based on area or population from the most recent decennial census. The decennial census counts are measured without error.

Dave Dorer

David Dorer, this is a brilliant solution, thank you. As you guessed, I don't want to assume even distributions within areas, so this accommodates that concern. I am familiar with "sf" in R. I've never used Geocorr. Is this the correct site: https://mcdc.missouri.edu/applications/geocorr.html? There also appears to be an R package written to leverage it: https://github.com/jjchern/geocorr .

Dear Abe,

The university of Missouri in cooperation the the Census Bureau hosts Geocorr. I just google geocorr missouri

Glenn RIce handles the internals of geocorr and he monitors the website closely. So if you have any questions about geocorr post them here and Glenn will reply usually the same or next day.

Dave

Yes, that is the correct link for Geocorr (all versions).

As for that R package, it seems very out of date (still using Geocorr 2014 with 2010 geographies) and also fairly limited -- it includes only 11 crosswalks out of the hundreds possible in the Geocorr app.

Got it, thank you Glenn Rice. I'll do it the old fashioned way.

Since the block populations come from the decennial census they have a 0.0 MoE. If you assume that the population is uniform across the block then both the estimate and the MoE would scale by the same factor ( new_area/old_area ) * MoE. I can't think of a way you could quantify the error associated with the fact that it is unlikely that the population is uniformly distributed across the block. You might be able to find a research paper on this.

Best,

Dave