would like to hear your thoughts on the layer type question (point 4 in the description) @ericboucher

I believe we could keep the same layer type but add a config flag.

It might be worth thinking about a specific tab design for the composite layers so that we don't have to duplicate the layer in the table? Maybe a toggle or something like that could be sufficient?

@ericboucher do you have any maxims you use to determine when to define a new layer type vs when to add to an existing layer type?

We're facing a similar question in #1332 in which we need to add a collection of geojson polygons to the map. It's technically straightforward but determining how it fits into our layer taxonomy is less so.

Based on my reading of hip/analysis/analyses/drought.py, I don't believe that zonal stats are already supported by q_multi. We could update our hip-service endpoint to perform the zonal stats and return admin level data instead of point level data.

Alternatively, what would you think about handling this in the Analysis panel? Currently, only raster types and polygons are support but we could add support for point data like these? I believe that would better match our current approach to running zonal stats based on admin level.

Thanks for looking into it @gislawill. I had thought about using the analysis panel for this. It's a departure from how that is currently built though as it introduces a hazard layer which needs to be computed first. I think it might be simpler to have a separate layer instead, but it would be good to understand which would be easier to maintain.

My understanding of the analysis panel is still somewhat limited so I'm not sure I understand the difference between a "hazard layer" and any other layer we have in PRISM?

The two options I see are:

1. Optionally run zonal stats in hip-service for q_multi requests
2. Run zonal stats in PRISM API for composite layers

I lean towards the second option for a couple reasons:

• It's new functionality that would be usable by any point layers
  • a comment in the code notes that we should add that eventually
  • compared to option 1 which would only be reusable for other q_multi layers
• It's not building upon hip-service
  • which Valentin wants to move away from

I think one of the most important factors though is the UX that Jordan users would find intuitive. If going through the analysis panel would make it less useful for them, we can create a new layer and add this functionality into hip-service

Following up based on Slack conversation with @wadhwamatic:

• We're going to build this aggregation functionality into hip-service under a new endpoint
  • We're hesitant to do so because we know hip-service's days are limited but it's the best option today
• The alternative would be to use PRISM python API to do this aggregation via the analysis tab
  • But requiring users to navigate through the analysis tab every time is a poor user experience