API for creating scenarios, wallpapers, etc (scenario CRUD)

[davemfish]

An example of scenario metadata required by the frontend:

scenarioID: {
  name: 'project pecan',
  features: {
    0: {
      id: 0,
      table: {
        forest: 23,
        orchard: 50,
        housing: 12,
        commercial: 32,
      },
      action: 'wallpapered with pattern {patternID}',
    },
    1: {
      id: 1,
      ...
    }
  },
  bbox: '[...]', // i.e. of all the features.
  lulc: 'some ref to the lulc created for this scenario',
  base_lulc: 'a ref to the baseline lulc, which could be another scenario's lulc',
},
scenarioID: {
  ...
}

[davemfish]

Here's a number of communication endpoints we envision.

Create a session:

Send: Receive:

• session ID

Make a scenario:

Send:

• scenario name & description
• session ID

Receive:

• scenario ID

Update scenario:

Send:

• scenario ID
• name & description, etc (all the fields to update)

Receive:

• status

Delete scenario:

Send:

• scenario ID

Receive:

• status

Get scenario

Send:

• scenario ID.

Receive: see example in top post

• name
• description
• WKT string for bounding box (extent of all features in the scenario)
• reference to LULC
• reference to LULC this one was derived from
• list of features
  • parcel ID (we'll want to highlight the parcels on the map)
  • summary table of lulc category pixel counts in feature

Get all scenarios

Send:

• session ID

Receive:

• list of all scenario names mapped to their IDs

Create wallpaper pattern:

Send:

• WKT string for the geometry (i.e. a box under which to extract a pattern of LULC)
• description/label for the pattern

Receive:

• job ID
• pattern ID

Get wallpaper pattern catalog

Send: (I think the pattern catalog is a global database available to all users. So no data in request)

Receive:

• A list of existing patterns, each pattern might be like:

  {
  id: 0,
  label: 'medium density residential',
  }

Do Wallpapering:

Send:

• geometry (if a parcel DB ever exists on the server, we could send parcel ID instead)
• pattern ID (which pattern to use)
• which LULC is the baseline I think the scenario ID might contain the info needed about the baseline LULC. All scenarios have an LULC associated.
• scenario ID

Receive:

• job ID

Get Results of Wallpapering:

Send:

• job ID

Receive:

• url of COG (or whatever) for the new lulc
• summary table of new lulc in parcels (counts per type)

Get Status of job: (job could be wallpapering, invest run, etc)

Send:

• job ID

Receive:

• status

Get LULC table for a parcel not yet in a scenario:

Maybe it's better to do this on the client actually This returns data similar to Get Results of Wallpapering, but it's for the case where we haven't yet created a scenario, but want to select a parcel and see the baseline LULC values in that parcel. Send:

• parcel geometry

Receive:

• summary table of baseline lulc in parcel (counts per type)

[davemfish]

I just added a missing endpoint for getting all the metadata for saved scenarios. So we can populate the UI when a session loads. In essence I think that boils down to sending the client the data described in the first post of this issue.

[davemfish]

@dcdenu4 and @phargogh I just added another endpoint - Create wallpaper pattern after a conversation with @emlys .

We're building a widget for the user to select an area from the baseline LULC (on the webmap) to use as the wallpapering pattern. We think that extracting the pattern from the raster will be a backend operation. And we envision storing that pattern in a database so it can be used by Do Wallpapering. And as a side-effect we build up the catalog of patterns that people can reuse!

See also #17

[davemfish]

Get LULC table for a parcel not yet in a scenario: Maybe it's better to do this on the client actually This returns data similar to Get Results of Wallpapering, but it's for the case where we haven't yet created a scenario, but want to select a parcel and see the baseline LULC values in that parcel. Send:

parcel geometry Receive:

summary table of baseline lulc in parcel (counts per type)

@dcdenu4 I've gone back and forth on this, but I think I'm concluding that this is best as a server-side operation. There is no "zonal stats" in the OpenLayers API and that's essentially what this is. It's easy enough to get a raster value at a single point, but that's not really adequate for this. Plus it will only work when the raster is visible and I want people to be able to get the landcover summary for a parcel they click even when they're viewing some other basemap besides the landcover raster.

The only catch is that I'm not sure if this would need to go into the job queue, or if it's possible to just await the response. Maybe it doesn't really matter.

[dcdenu4]

The only catch is that I'm not sure if this would need to go into the job queue, or if it's possible to just await the response. Maybe it doesn't really matter.

This should be a quick enough operation that we can just await a response. I'm not sure if you'd see any lag if say, 20 other people were trying to make requests. But, we can also throw it onto the PriorityQueue with highest priority too. We still have a bit of work to do to think out the Queue, Job, Worker pipeline.

[dcdenu4]

Updating the endpoint for receiving Wallpaper results:

Get Results of Wallpapering:

Send:

• job ID
• scenario ID <---- added for backend simplicity. It wasn't apparent how to properly connect job_id to a Scenario

Receive:

• url of COG (or whatever) for the new lulc
• summary table of new lulc in parcels (counts per type)

[davemfish]

I think this issue served it's purpose. We development these endpoints following this design, more or less.