Census API data across superior geographies

Question

I am trying to populate a GeoJSON layer of blockgroups in Leaflet with attribute data pulled live from the Census API.

My GeoJSON has the full FIPS code for the blockgroups as an attribute. That is, each feature has the concatenation of State, County, Tract, and Blockgroup FIPS codes.

An example blockgroup FIPS:

Massachusetts (FIPS: 25), Suffolk County (FIPS: 025), Tract 07010, Blockgroup 3 renders as 25025070103.

I would like to be able to make a request that gets attribute data for all the visible blockgroups at once, by passing a list of these blockgroup FIPS codes. Because the FIPS code is fixed-length, the API should understand what geometry I'm requesting, at least within the State-County-Tract-Blockgroup-Block pipeline.

Example:

http://api.census.gov/data/2010/sf1?get=NAME,P0010001&for=blockgroups:250250701013,250250701014,250250701024&key=xxxx

However, the Census API documentation requires that superior geometries be specified, at least at the county level. However, if my layer crosses counties or states, I have to gather all of my blockgroup IDs, sort them, split them into different requests by states and/or counties, issue the requests sequentially, then add the data as it comes in.

The example from above, albeit a small one, splits into:

http://api.census.gov/data/2010/sf1?get=NAME,P0010001&for=block:3006,3007&in=state:25+county:025+tract:070101&key=xxxx

http://api.census.gov/data/2010/sf1?get=NAME,P0010001&for=block:4,&in=state:25+county:025+tract:070102&key=xxxx

Is there a way to issue a request with just tract/blockgroup/block FIPS codes? If not, could one be implemented?

Answer 1

The answer to your first question, "Is there a way to issue a request with just tract/blockgroup/block FIPS codes?" is no, as you found in the documentation.

The answer to your second question, "If not, could one be implemented?" is not really a great question for a Stack Exchange site. I don't think Census Bureau folks are monitoring this site, although other open data advocates in the US Government are, so maybe I'm wrong, or maybe that will change and they'll start coming around. (and having them use OpenData.StackExchange.com would be a big gain over http://apiforum.ideascale.com/)

As someone who has been working on a project (Census Reporter) which includes a Census data API, handling API requests for fine-grained Census data is hard to get right and make it perform well. I know that Census Reporter really doesn't handle bulk data for block groups well. The slowest part of our app is calling for arbitrary geojson for maps on our block group profile pages (example).

In short, this is an example when an API is probably not the right way to deal with this open data.

If you can at all handle it, I suggest you look into simply grabbing the bulk data that you need and updating your GeoJSON to include it. It doesn't change that frequently, so making API calls for it is, as you observed, complicated for you, and also likely to be hard to make perform as well as you would like.