Gate Changes

[krowvin]

Creating a Gate Change End Point - Issue #197

🗺 Top Level Roadmap

• Ask CWMS users/developers what they need in a gate change API
• Developers finalize a structure/standard for the various payloads, starting with JSON
• Create a development environment (+docker clone of a district database with gate changes) with basic GET / Read Only queries
  • Changes
  • Settings
  • Ratings
• Test development environment across pilot districts that actively have gate changes
• [ ] (OPTIONAL) Develop a client-side (HTML/JS/CSS) application that allows users to read gate changes using the GET functionality
• Append basic POST functionality for creation in the dev environment (Requires Authentication)
  • Changes
  • Settings
• Test creation against a narrowed down list of districts determined via the GET testing
• Append basic POST functionality for updating in the dev environment
• Implement a development environment with basic POST (or DELETE) functionality for deletion
• [ ] (OPTIONAL) Amend the client-side (HTML/JS/CSS) application to allow users to create/update/delete gate changes
• Create test sites on local district servers for them to LIVE test
  • Host Webinar on how to setup local district CDA instance
  • [ ] (OPTIONAL) Deploy client-side (HTML/JS/CSS) application for district use and testing
  • Set a pipeline for districts to report issues
• Announce first production release of CRUD functionality for the gate change endpoint

[adamkorynta]

Notes from Meeting 6/18/2024:

RMA under contract for data and metadata for gate settings.

• adding REST API support for outlet management and gate settings/changes to CDA
• adding java client API's for interacting with the REST API
• adding in cwms-python support for outlets and gate changed.
• Does not include integration into applications.

Information on gate/outlet representation in CWMS:

• Settings implemented as irregular time series (independent from normal ts tables). Coordination between all gates happen for each gate setting change. Includes pool/tailwater elevation and the opening. Also includes change reason codes.
• Currently gate changes are used through web interfaces and client applications. Need to be able to utilize CDA as JDBC access will go away.
• Outlet defined separate from gate changes/settings. Associated with a physical location (kind is OUTLET). Controlled/uncontrolled structures. Both associated with ratings using location groups. (uncontrolled elev;flow curve). Gate change settings are only for controlled outlets.

Location group and most extra pertinent data associated with outlets are already supported by CDA, but still need the outlets themselves.

Standard Naming - standard naming will be followed in order to standardize the approach to CWMS data objects.

• Some districts do not use sublocations for outlets. Is this constrained in CWMS? Need to investigate further.

In addition to gate settings, extra data (like algae) is collected. Gate, time, setting, code is input. Wind-speed, rain, etc is entered as well. Uses codes to associate this extra data. All numeric. Rain gage, evap, lockages, chloride check.

• gate change has reference elevation value and a notes field. notes field could be used with a JSON payload. Would likely need to widen
• better to store this as separate time series data (different parameter/version for each of these metadata)

Currently, districts are responsible for writing their own sites for data entry for gates and gate settings.