[boundary] Consider adding census GEOID to district record, deprecating boundary

[estaub]

The (district) boundary API either needs work, or should be deprecated, IMHO. I'd guess that the most common use of boundaries is for map tiling, and pulling shapes one at a time is nearly prohibitively slow for, say, tiling a state. A much better approach is to do what the census does: have online zipped shapefiles, one per state, which can be browser-cached.

Including a Census GEOID would be a great enhancement, since it would enable use of Census shapefiles instead of the boundary API (reducing server load). The shapefiles could be used directly from Census, cloned as static assets at OpenStates, or cloned in the using app. Also, perhaps as important, it would enable mashups with other Census data (e.g. income) per district.

In theory, one should be able to construct a Census GEOID from the existing district boundary_id, since they seem to be trying to be OpenCivicData division IDs. But in practice, it's impossible, because the sldl / sldu fields are incompatible; rather than the statewide integer needed in a GEOID, they are things like 6th_worcester and cheshire_16.

[estaub]

An approach to mapping boundary-id's to GEOID's appears to be to download https://github.com/opencivicdata/ocd-division-ids/blob/master/identifiers/country-us.csv, pull the needed rows (sldl's and sldu's) and columns (probably id and census_geoid_14), and merge them into district data.

[jamesturk]

After further consideration & discussion, we'll never have a perfect mapping to census GEOIDs as sometimes we have to use newer districts than the Census can provide.

We'll definitely consider exposing more of the available OCD mappings in the new Geo API, but I think we'll keep providing a way to fetch boundaries for the foreseeable future as all other mappings will be imperfect.