It is a familiar story heard here at AGS…
“I loaded the data that I received from you into my GIS application, but when I map it, there is a county with no data. Please take a look at the attached map. Why don’t you have data for this area?”
The accompanying map indeed includes an area that is rather annoyingly labelled “No Data”, in this case, a county in South Dakota.
So, what’s going on here?
In 2014, more than 80% of the voters in Shannon County, SD voted to approve a county name change to Oglala Lakota County. Dutifully, the census bureau changed the county FIPS code from 46113 to 46102. When the data table was imported into the GIS system and matched using the FIPS code, the record for 46102 was not found, and of course when mapped, the cartographic record labelled 46113 legitimately has no data.
We often tend to think that the roster of geographic areas published with each census can be safely used until the next census. Over the last couple decades, we saw a number of changes at the county level including –
- The creation of Broomfield County, CO, which was carved out of portions of several counties in the northern suburbs of Denver
- The amalgamation of several independent cities in Virginia with their adjacent counties
- Name changes, which don’t change the boundaries at all, but do change the FIPS codes associated with the area in question
A change in the county from 46113 to 46102 immediately affects block group and census tract files, which must be relabeled, and the cartographic files updated. At other levels of geography, the changes tend to be more frequent:
- Cities and towns often annex territory, and the “place” level must be regularly updated to reflect changes over time.
- Metropolitan areas are defined and named by the Office of Management and Budget, and the naming of these areas is by population size. The metro area that includes both Santa Barbara and Santa Maria California has often changed name and number depending on which of these relatively equal sized cities is currently estimated to have more residents.
When we are asked for block group data on 2010 boundaries, our first question is “which roster are you using?” in order to attempt to minimize these kinds of problems. Currently, we output data for 2020 block groups, 2017 block groups (that is, 2010 updated to include the name change above plus another name change in Alaska), and 2014 block groups (which picks up the absorption of Bedford City into Bedford County VA, but not the name changes).
The currently pristine 2020 block groups are going to get complicated over the next couple of years, and many users will find annoying “no data” areas not just for one county, but for the entire state of Connecticut.
Over the course of the next year, the data produced by the census bureau (ACS, TIGER, etc.) will be reworked for the entire state, as the 8 counties will be represented as 9 “county equivalents”. From the census block on up, everything will be changed to reflect the new “county” codes. The census regularly reports on these changes.
The changes make sense, but we can’t help but ask the State of Connecticut why they didn’t request these changes in 2017, so that they could be incorporated into the 2020 census. It seems somewhat rude to us.
A year or so from now, when you map population density in New England at the census block level, the entire state of Connecticut will show up as “No Data”, unless you update cartographic files as well. Don’t worry, we will stay on top of these changes for you, but don’t be surprised when we ask, “do you want 2020 or 2022 block groups?”
It is also why we will ask the question, “do you need cartographic files with the data?”
Recent Comments