How To Cost Module and Promethee Prioritization

[austinorr]

in this discussion i'll share some how to's about the cost module options and the promethee prioritization tool. Both have been drafted on the backend, and are ready to start implementation discussions for the front end.

@cnilsen and @acang-gs, just tagging you so you see this board and that's it different from issue tracking.

[austinorr]

Cost Module:

The backend now supports cost calculations for structural facilities with the following user input required:

• "capital_cost" (numeric)
• "om_cost_per_yr" (numeric)
• "lifespan_yrs" (numeric)
• "replacement_cost" (numeric)

And the following application-global variables:

• "planning_horizon_yrs" (numeric) default is 50 years
• "discount_rate" (numeric) default is 0.05; calculated as 0.08 expected return less inflation of 0.03

Test the stateless calculator here: https://dev.tacomawatersheds.com/docs#/costs/calculate_npv_api_rpc_calculate_net_present_value_post

tmnt_attr

The API supports adding these data to existing structural facilities via full or partial patch requests. https://dev.tacomawatersheds.com/docs#/tmnt_attr/tmnt_facility_attr_patch_tmnt_attr_api_rest_tmnt_attr__altid__patch
This means that the frontend UI can optionally handle setting these parameters with a separate database transaction from the edit & submit cycle of setting the modeling parameters.

global_setting

An entirely new CRUD has been built to handle application globals. https://dev.tacomawatersheds.com/docs#/globals
This is seeded on startup with the two default values above (if they're not already set) but a frontend UI could/should be built to allow City of Tacoma Admins to adjust these values.

ToDo with proposed assignee:

• peer review calculator and accompanying NPV calculation spreadsheet. (Christian) Please find the workbook on our server here: "...PNW0448_Watershed_Tool\Analyses_Technical\cost_module_npv\npv.xlsx"
• build UI to submit cost params (Adrian)
• determine how to report and compare costs. Do we want $/lb tss removed? Do we need $ /lb of every poc? (Christian)
• mock up UI for cost report and comparisons (Christian & Adrian)
• update backend as needed to support cost report and comparison decisions (Austin)

@cnilsen @acang-gs

[cnilsen]

I updated and checked the NPV spreadsheet to reflect capital costs spent in the year of construction.
Saved in the same folder: "...PNW0448_Watershed_Tool\Analyses_Technical\cost_module_npv\npv_cwn_updates.xlsx"
@austinorr @acang-gs

[cnilsen]

@austinorr @acang-gs We presented a spreadsheet mockup of the to cost module to Tacoma last week. I saved it on the server here: /data/Clients/Tacoma_City_of/Projects/PNW0448_Watershed_Tool
I started with @austinorr's npv calculator and added in the ability to use a different basis year for captial and O&M costs. @austinorr when you are working again, It would be great for you to review before Adrian starts developing the UI for this.

[austinorr]

Subbasin Prioritization Module

The subbasin prioritization module is 'complete' on the backend.
This required building proper subbasin result summaries which account for the total load running off of of each subbasin following our three treatment opportunity types (upstream controls like sweeping, structural facilities, and downstream controls like line cleanouts).
These subbasin summary results are available at a new endpoint documented here: https://dev.tacomawatersheds.com/docs#/subbasin

It's possible to retrieve results as a simple json table, or as a geojson, or by using the /{subbasin_id} route to get info for an individual basin.

Prioritization attributes

The actual attributes we are scoring are the equity index scores for each basin as computed by Tacoma GIS team for the census blocks which we have aggregated to each subbasin.
We also wish to score on the yield of each POC (including runoff volume) for each basin.
Our subbasin REST endpoint provides results for runoff volume (cuft), POC Load (lbs), runoff depth (inches), POC yield (lbs per acre).

It's recommended that we only allow users to score on area-normalized metrics (runoff depth and poc yield)

Prioritization Scores and API

The backend includes an RPC route to support users calculating a weighted promethee prioritization for the subbasins using the equity index and yield/depth results for each subbasin (per the 1980s modeling run results).
The user must select either "retrofit" or "restoration" as the wq_type to determine if the POCs are considered a 'cost' or a 'benefit' to the score, and the user must build up a list of weight & criteria pairs upon which to perform the scoring.

This API is documented here: https://dev.tacomawatersheds.com/docs#/subbasin/calculate_subbasin_promethee_prioritization_api_rpc_calculate_subbasin_promethee_prioritization_post

This action is stateless, and neither the results of prioritizations nor the inputs are stored by the database.

ToDo

• UI for users to configure and submit a new promethee scoring question/query with the current subbasin results
• UI for rendering/reviewing the scores
• add in concentration as criteria (Austin)

@cnilsen @acang-gs

[austinorr]

New access point(s) for Google's DataStudio and ANY 3rd Party Service or User

Authenticated users are given a new type of token to allow get requests (read only) to database resources, including subbasin results, treatment facility delineations, and anything else we'd like.

How it works:

• new field 'readonly_token' is added to the users table
• if this uuid is appended to a supported route, the route will work without requiring a login round-trip.
• the system is 'protected' in the following ways:
  • these routes are rate-limited and are meant to be pinged once by the service/user (not polled). Rate limit violations result in the ip address of the request being block for a period of time (typically 60 seconds). This helps prevent against malicious attacks that can run up server costs. This can be adjusted however we please as time passes.
  • the readonly token can be 'rotated' to re-issue a new token. This can be done periodically, which would require all downstream dependent users/services to update their routes, or it can be done in response to an incident that may indicate nefarious use or frequent polling.
  • this access is read-only, so no direct risks to data integrity
  • all tokens are unique to the user, so the server logs will reveal which token was used for each request.

This allows access within qgis, just add a vector layer with protocol:http and uri = https://dev.tacomawatersheds.com/api/rest/tmnt_delineation/token/?f=geojson and you can make a map like of the data. Below is an example with a choropleth of the subbasin modeling results of TSS yield (lbs per acre) and the areas treated by a structural facility.

@cnilsen @acang-gs