Convenient JavaScript utilities for working with Census APIs: Statistics, Cartographic GeoJSON, lat/lng -> FIPS, and other niceties (written in ClojureScript)
index.edn has a couple of overloaded properties, namely:
The underlying APIs that citysdk abstracts need various configurations in order to be harmonized and merged together:
Tiger WMS services is used for both geocoding lat/lng coordinates as well as composing the needed geographic hierarchy for the stats API (api.census.gov)
GeoJSON API (a REST API built using raw files on github.com) provides files that contain geographic identifiers (GEOIDs),. Sometimes these GEOIDs are broken up into parts (e.g., ST, COUNTY) and sometimes they are nicely combined into a single GEOID under their properties
The way index.edn helps with the maintenance burden of updating the CitySDK - due to the complex differences between both the availability and format of the underlying resources - is to provide a single file that provides the needed paths to the underlying data so that they can be merged together.
A vector (path) is used to qualify the statistics API geographies (for :stats+ calls) when using the WMS geocoders. E.g.:
When given only place: { lat: 20, lng: -30 }, citysdk uses this path to both make the request to Tiger WMS for the correct FIPS codes and compose the correct arguments for the stats API. I.e.:
Note that citysdk provided state without user input. This is facilitated by this configuration.
Another path (sometimes identical to that above and sometimes simply [ :GEOID ]) points to the correct properties within the GeoJSON features to enable the results from the stats API to be merged with the GeoJSON
if :lookup is a vector: This path is used to configure the WMS and stats API and :id<-json is used to target the properties in the GeoJSON
if :lookup is not a vector (e.g., :2010), the :id<-json key from the vintage within the containing geographic scope is used to furnish the WMS configuration.
In either case, the last element on the path (vector) is used here
index.ednhas a couple of overloaded properties, namely:The underlying APIs that
citysdkabstracts need various configurations in order to be harmonized and merged together:lat/lngcoordinates as well as composing the needed geographic hierarchy for the stats API (api.census.gov)ST,COUNTY) and sometimes they are nicely combined into a singleGEOIDunder theirpropertiesThe way
index.ednhelps with the maintenance burden of updating the CitySDK - due to the complex differences between both the availability and format of the underlying resources - is to provide a single file that provides the needed paths to the underlying data so that they can be merged together.A vector (path) is used to qualify the statistics API geographies (for
:stats+calls) when using the WMS geocoders. E.g.:When given only
place: { lat: 20, lng: -30 },citysdkuses this path to both make the request to Tiger WMS for the correct FIPS codes and compose the correct arguments for the stats API. I.e.:api.census.gov/data/2019/acs/acs1/get=...&for=place:123&in=state:01Note that
citysdkprovidedstatewithout user input. This is facilitated by this configuration.Another path (sometimes identical to that above and sometimes simply
[ :GEOID ]) points to the correctpropertieswithin the GeoJSONfeaturesto enable the results from the stats API to be merged with the GeoJSON:lookupis a vector: This path is used to configure the WMS and stats API and:id<-jsonis used to target thepropertiesin the GeoJSON:lookupis not a vector (e.g.,:2010), the:id<-jsonkey from the vintage within the containing geographic scope is used to furnish the WMS configuration.In either case, the last element on the path (vector) is used here