PBR Explorer Report

[philipbaileynar]

Goal: Develop a proof concept report demonstrating that we can incorporate PBR Explorer data into our report platform.

Background: We have had at least two inquiries from researchers wanted to access PBR data. I responded with [documentation on the API](https://docs.riverscapes.net/products/pbr-explorer/api), but it would be more accessible if folks could use the reporting platform.

Concept 1 - PBR Public Project Scrape

• Can we produce a data scrape "report" of public PBR projects? This would be akin to the [IGO scraper](https://staging.reports.riverscapes.net/report/igo-scraper).
• User provides lasso and they get scrape of all the public projects in that area:
  • pick
    • HUC2,4,6,8
    • US States
    • Counties
  • draw
  • upload
• The PBR data are somewhat relational and easiest to serve in JSON, maybe SQLite (either as 5th normal form or as a single table with the key properties and then the metadata as JSON fields). Probably best to avoid CSV.

Concept 2 - Formatted Report

Perhaps we produce a formatted report and data dump (like we do for riverscapes inventory)? I don't have a specific design (what a surprise), but I am envisioning the following elements:

• Map of points.
• Table of projects (one row per project with a few key fields as columns),
• Repeating sections for each project. This is a summary report, so we don't need every field and certainly don't need photos etc. But a fairly compact "card-like" layout of project properties, perhaps indexed to the aforementioned table. (If folks want a detailed report of a single project we should fulfill that through the PBR site with print CSS.)

Notes

• You will need to research whether the report Python queries the PBR explorer directly or if there is some value in streaming PBR data to Athena and querying it from there.
• The above concepts specify public projects only. It would be better if the report process can know who is generating the report and use that information to include all the projects that they can see. The report still has utility if this is impossible or too hard, or we have to continue to direct folks to the API for this. It just means that we will still need to respond to inquiries for private data.
• There are PBR projects in France, UK and soon to be NZ. There should be no geofence on this report.
• The data are lightweight points and some metadata. It should not be volumnous. We should support entire CONUS lasso, or France, or NZ etc. We should investigate what happens at zoom 0 and people try to lasso the world.

FYI @MattReimer

[MattReimer]

It would be better if the report process can know who is generating the report and use that information to include all the projects that they can see. The report still has utility if this is impossible or too hard, or we have to continue to direct folks to the API for this. It just means that we will still need to respond to inquiries for private data.

It's hard. PUBLIC projects only for starters is far preferable. Otherwise we would need to pass the user's auth token to cybercastor and there are loads of issues with doing that see #161 for notes about that.

Allowing this in a correct way would mean reworking the PBR API endpoints and resolvers to allow delegated queries (which we currently do not). A delegated query is like saying "I'm cybercastor and an admin but I want you to make this query as if I was someone else". Not out of the question but it means opening the hood on PBR and yanking some guts out. Happy to quote further if this is something we need.

Even if we do this route we'd need a secure handoff so that the Reporting API resolvers can verify that the user being used as the delegate is the same as the person making the query.

Athena

Currently we do not load any PBR Data into Athena. There is a convenience in doing this but mirroring all of PBR just for this seems like a lot of trouble when all the data can just be collected using the API. The graphql API is already pretty fast. Certainly fast enough for reports.

Lasso and AOI selection

A lasso is not currently possible but SearchTermsInput does allow a bounding box so we can search on any of the following:

    const searchTerms: SearchTermsInput = {
      bbox: undefined,
      continent: 'North America',
      country: 'United States',
      orgAffiliateId: undefined,
      provState: 'Utah',
      textSearch: textSearch,
    }

If you're dead-set on the lasso you could use the bounding box of your lasso/AOI to over-select and then filter out the extra projects in python later using python + OGR.

[philipbaileynar]

We should avoid mirroring PBR data in Athena unless there is absolutely no other way to accomplish the report.

Public projects via the API is the V1 MVP.

[weblorin]

Ver 1 MVP is ready for review.
https://staging.reports.riverscapes.net/report/rpt-pbr-explorer

This feels like this is very similar to the "report" the PBR explorer provides for Regions or Organizations for example, but for custom polygons.

BTW We do not have counties as a pick layer, @philipbaileynar please create new issue to add that to our warehouse and tileset if it is really needed.

Example reports, good for 7 days
Pacific Northwest USA: html zip
Southern France: html zip