[Feature Request]: make use of pmtiles for admin boundaries

[wadhwamatic]

Provide a clear and concise description of what you want to happen.

We are unable to load larger admin boundary files. Rather than attempt to load large geojson files which can contain more data than necessary, we should try to only load relevant data based on the users' zoom level and in-view bbox. We've determined that pmtiles will provide a good solution for this.

It's critical that we continue to maintain support for admin boundaries in the form of geojson, while adding support for admin boundaries using pmtiles

The change would touch many areas and that the following features still work using either admin boundary approach (json or pmtiles):

1. Admin level data layers continue to render correctly and tooltips display information as configured in layers.json
2. Go to feature displays admin level hierarchy and allows users to search for specific locations correctly
3. Multiple language support works as expected, with admin names reflected correctly in tooltip and analysis results
4. Running an analysis shows results by selected admin level
5. Population exposure analysis correctly aggregates by admin areas and renders tables with admin areas as rows
6. Layers with chart configuration correctly allow user to display charts in map view at admin levels 1 & 2
7. Admin ids configured in prism.json and layers.json are correctly used to fetch data in chart module
8. Selection of an admin area in the print feature masks non-selected areas

Is there anything else you can add about the proposal? You might want to link to related issues here, if you haven't already.

No response

[gislawill]

Heads up @wadhwamatic and @valpesendorfer, we're planning to approach this in the following way:

• We're going to start with a proof-of-tech branch with PMTile-powered admin borders
  • This will help us catch any lurking dependencies on the geojson admin layers which could bloat scope
    • Any interactions with the admin boundaries by way of MapLibre should work without updates
    • Any interactions with the admin boundaries geojson directly will need to be updated
  • We intend to share a surge deployment with this around the end of next week
• Then we'll set up the toolkit and documentation for generating and uploading PMTiles in the new repo
  • Aiming to have this ready the following week
• Polish up the prism pr and address any lurking dependencies on the geojson
  • Should be very quick but depends on what's discovered in the first proof-of-tech

[wadhwamatic]

Thanks @gislawill. The plan sounds good. One thing I'm thinking about is 'interactions with the admin boundaries directly will need to be updated'. My hope is that basic map interaction will 'just work'. I would expect that we'll have more challenges when we run zonal stats through PRISM's analysis features. I don't know enough about PMTiles for this type of use. Might need to consider alternatives in that scenario, while still keeping boundaries in sync between approaches.

cc @ericboucher

[gislawill]

@wadhwamatic, you're 100% right — that "zonal stats through PRISM's analysis features" is a really great callout.

One approach: Within PRISM's server, we could decode the PMTiles into a geojson that we can then use for zonal stats (as opposed to sending the geojson with the request, as we do now). It's moderately complicated functionality: Decoding only part of a global PMTiles file is definitely do-able but it'll be important write it correctly and maintain it well to avoid loading unnecessary data.

Alternatively, if the PMTiles are directly associated with a geoparquet in S3 (the direction we're moving in), our prism server can selectively query the relevant features and easily load just the necessary data. That query would be harder to screw up and easier to maintain. Plus, this better maintains a "one source of truth" approach.

I don't think this needs to be a blocker on this ticket it's is a good time to revisit if the PRISM api should run zonal stats or if we should move it to a shared service (@ericboucher and @valpesendorfer)

[wadhwamatic]

Sorry for the late follow up @gislawill. I think the geoparquet approach is more inline with where we'd want to go with this but let's hear from @valpesendorfer with his thoughts

[valpesendorfer]

Agreed, I don't think vector -> pmtiles -> vector is a desirable approach, using a geoparquet as reference for both sounds reasonable.