Streamline API call flow
ronnie-llamado opened this issue · comments
See the development branch here: https://github.com/ronnie-llamado/cenpy/tree/development
I've been messing around with an improved flow utilizing a mapping between the Census API and TIGER API. It allows for easy and modular support of census defined geographies. Using this mapping, SQL WHERE queries can be constructed using a defined hierarchy to pull geometry data in a single TIGER query (as opposed to pulling a geometry and using the bounds for another query).
I've gotten it to work with the ACS using almost all of the defined whole geographies (ignoring (or part) geographies for now and failing on congressional districts and zip code tabulation areas). See the latest build and tests for coverage. The key piece of this is located in a configuration file where the mapping is defined.
A few limitations (at the moment):
- Non-defined census geography hierarchies - such as pulling
tractfromcombined statistical areas- need to be identified and handled separately (or part)geographies (might?) require identifying multiple geometries, querying multiple layers, and taking an intersection of the two
However, I believe it's doable to get full support from both census defined and non-defined geographies with a little bit of work. This applies to both the ACS and Decennial products.
BIG NOTE: Getting this functional did require some reworking of the modules and I admittedly got very carried away. I made a handful of changes while I was reworking everything. It is very different from the original. Seeing if this was a worthwhile endeavor beforehand and consulting with the group would have been the smarter play.
Integrating this in would require a handful of work like testing, documentation, and adapting for backwards compatibility. Is this something that would be worth to start integrating into cenpy and continuing development in this repository? Perhaps 2.0?
This is super interesting! Yes, I would love to explore integrating this into a 2.0. the "products" API was a 1.0 innovation...
Actually this might be more of a 1.1 if we retain all backwards functionality. I'll start a project to start setting up tasks.
Here's the current list of exposed public objects:
products.ACSproducts.Decennial2010explorer.explorertools.set_sitekey