You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we only allow specific geographic units: Watershed, Congressional District, etc. We use these as part of an attribute selection for the data (e.g. region_type = Congressional District, region_values=[01,02], state="IA" will return facilities / program data for facilities in CDs 01 and 02 in Iowa.)
But if we move to a more "open concept" approach to selecting the place of analysis, a la here: https://colab.research.google.com/drive/1WkopgBp7cImVyLFvLar9zAsjbkSAXG_L#scrollTo=9A_5rSlKn2bT then we'd need some way of filtering data that isn't based on attributes (since the facilities within the new boundary may not share the same ZIP code, for instance, and selecting all represented ZIP codes would probably get us more facilities than we wanted)
I think there should be a "Neighborhood" region_type that takes REGISTRY_IDs as the region_values and uses these to look up program data.
In a notebook context, you would draw the neighborhood boundary, get the ECHO_EXPORTER data within that boundary, pull out the REGISTRY_IDs, and then uses those for selecting program data.
Alternatively, the region_values could be lat/long bbox values that could then be used against the FAC_LAT and FAC_LONG fields in ECHO_EXPORTER as well as the various MVIEWs. This is probably a more straightforward approach...
The text was updated successfully, but these errors were encountered:
Currently, we only allow specific geographic units: Watershed, Congressional District, etc. We use these as part of an attribute selection for the data (e.g. region_type = Congressional District, region_values=[01,02], state="IA" will return facilities / program data for facilities in CDs 01 and 02 in Iowa.)
But if we move to a more "open concept" approach to selecting the place of analysis, a la here: https://colab.research.google.com/drive/1WkopgBp7cImVyLFvLar9zAsjbkSAXG_L#scrollTo=9A_5rSlKn2bT then we'd need some way of filtering data that isn't based on attributes (since the facilities within the new boundary may not share the same ZIP code, for instance, and selecting all represented ZIP codes would probably get us more facilities than we wanted)
I think there should be a "Neighborhood" region_type that takes REGISTRY_IDs as the region_values and uses these to look up program data.
In a notebook context, you would draw the neighborhood boundary, get the ECHO_EXPORTER data within that boundary, pull out the REGISTRY_IDs, and then uses those for selecting program data.
Alternatively, the region_values could be lat/long bbox values that could then be used against the FAC_LAT and FAC_LONG fields in ECHO_EXPORTER as well as the various MVIEWs. This is probably a more straightforward approach...
The text was updated successfully, but these errors were encountered: