A02.12 PWS CWMS Database Authorization dated 2025.02.25.docx

PERFORMANCE WORK STATEMENT

CWMS Database Authorization Updates

1.0 General

This is a non-personnel services contract to provide the United States Army Corps of Engineers (USACE), Hydrologic Engineering Center (HEC) with software enhancements for the Corps Water Management System (CWMS). The Government shall not exercise any supervision or control over Contractor employees, including subcontractors, performing the services herein. Contractor employees, including subcontractors shall be accountable solely to the Contractor who, in turn is responsible to the Government.

1.1 Description of Services/Introduction

The Contractor shall provide all personnel, equipment, supplies, facilities, transportation, tools, materials, supervision, and other items and non-personal services necessary to perform work on adding software capability as defined in this Performance Work Statement (PWS) except for those items specified as government furnished property and services. The Contractor shall perform to the standards in this contract.

1.2 Background

The mission of the Institute for Water Resources, Hydrologic Engineering Center (HEC) is to serve as the United States Army Corps of Engineers (USACE) Center of Expertise in the technical areas of surface and groundwater hydrology, river hydraulics and sediment transport, hydrologic statistics and risk analysis, reservoir system analysis, planning analysis, real-time water control management and a number of other closely associated technical subjects. HEC's primary goal is to support the nation in its water resources management responsibilities by increasing USACE’s technical capability in hydrologic engineering and water resources planning and management. In addition to supporting USACE along with Division and District Offices, HEC provides technical support to the Corps overseas. Additionally, HEC provides services to other Federal, state, local and international agencies engaged in these technical areas.

The primary way HEC accomplishes this mission is by developing state-of-the-art software tools bringing them to state-of-the practice that are reliably used by water resources engineers and planners. Since its inception in 1964, HEC has been developing and integrating software tools that support the water resources computing requirements for Corps field offices, headquarters, laboratories, and other Federal, state, and international agencies.

The Corps Water Management System (CWMS) is the Army Information System (AIS) that supports and enhances the decision-making process for the USACE water management mission. USACE is responsible for round-the-clock monitoring and operation of approximately 600 reservoir, lock and dam, and other water control projects. This responsibility also expands, during flood control operations, to approximately 120 additional Section 7 (Non-USACE) projects.

CWMS provides critical information for making decisions that are fundamental in achieving the full range of benefits of the authorized purposes of USACE projects. CWMS integrates real-time data acquisition, database storage, flow forecasting of watershed runoff, reservoir operation decision support, river profile computation, inundated area determination, consequence analysis, and information dissemination into a comprehensive software package. CWMS and associated software underpin the USACE Water Management Enterprise System (WMES) by acquiring, processing, and reporting the hydrometeorological data required to manage USACE water resources projects under routine and emergency conditions. CWMS incorporates state-of-the-art modeling techniques such as spatially distributed rainfall-runoff flow forecasting, rule-based reservoir systems operation, steady and unsteady-flow water surface profile analysis, 2-D flow analysis, event-by-event flow impact for damage and life-loss estimation. In addition to determining reservoir operations, current and forecasted river water surface elevation/profiles and inundated flood area information can be utilized for flood fight decisions, flood evacuation warnings, and transportation interruption alerts.

The focus of this contract is on the database and API components of our CWMS system. CWMS is currently going through a transition from maintaining 32 independent, and geographically isolated systems, that feed into a public only central database, to a "single" cloud-based system that will contain all data, both public and private. Part of this transition is merging the multiple District databases into an Oracle RDS instance with an HTTP REST API called CWMS-Data-API (CDA). Previous to this decision, much of the data authorization was done within each individual database so that appropriate data constraints could be implemented while allowing District applications to access Oracle directly. The CWMS Database Schema (CWMS DB) has thus made heavy use of session contexts and the Oracle Virtual Private Database (VPD) system to provide appropriate authorization. It is clear to us that this will not be sufficient going forward, and a more appropriate model of authorization needs to be adopted. While CWMS DB is currently using Oracle, is it likely the CWMS DB will migrate the data to various forms of storage appropriate to the type of data and its usage. As such, HEC believes it is most appropriate to focus our updated access control efforts on CDA, the API through which data will be accessed. CDA is a Java-based REST API using "javalin.io" as the underlying platform. The current Javalin Access Manager has changed from its initial implementation over time and will adapt to future requirements as needed.

1.3 Objectives

The Contractor is to review current database and API functionality and help formulate a plan for implementing an authorization scheme granting and restricting access to specific records. Our current data model utilizes 32 individual databases by USACE Water Management Offices. Each office defines the times series ID that they determine to be public. Those specific public time series values are then replicated using Goldengate into a single public database where the public has access to the data either through our API or a public website. Our current database and API model allows public access to all data in the database. We are migrating to a data model where data from all 32 offices will be in a single database. This includes both public and private data. A capability is necessary to restrict access to data either within the database or through the API based on the user. Public and private data can both reside in a single table or view in Oracle and would be restricted based on the identifying ID of that object and possibly time.

The objective of this contract is to develop a detailed plan on how to implement the Authorization Scheme into the CWMS Data API and then implement the created plan. This will include a review of our current data Schema and API to determine the best path forward. After the initial review, the following objectives will be required for the accomplishments of this contract.

1. ability to authorize read permissions to data objects in the database

1. ability to authorize write permissions to data objects in the database

1. ability to authorize delete permissions to data objects in the database

1. ability to authorize create permissions to data objects in the database

1. ability to authorize update permissions to data objects in the database

1. ability and platform for data administrators to assign the above permissions to users as appropriate For read access it is desired to have multiple categories, that data objects can be part of, to determine what data users are able to view. Possible read authorization categories include the following:

· Public - data that everyone will have access to view

· Limited Distribution - a subset of public users have access to view, or must be time restricted (e.g. data cannot be public until 10 days after sample time of value/first storage)

· Private - data that would only be available to view by internal users and would be granted by the office who owns the dataset

· Private Limited - data that would only be viewed by a subset of internal users and would be granted by the office who owns the dataset The root data element for most CWMS data is the "Location" which contains metadata related to a physical or possibly virtual site, such as a stream flow gauging station or precipitation gauge that provides data. While Location is the root data element for CWMS data, the primary data objects being viewed are time series. Each time series is associated with a Location. Other objects that could possibly be restricted for read access include Rating Tables and Location Reference Metadata. While it might be possible for a Location and all the associated objects to be set as private, it would be rare for a location and all of its associated objects to be set as public. A more refined designation to the individual objects themselves will be needed.

Possible objects that would also be restricted include:

· Location - Primary Location, metadata related to a primarily physical or possible virtual site. Other objects are assigned to a Location.

· Time Series - Numeric, Text, and Binary lists of data based on a sample time, version time, value, and quality marker.

· Rating Tables - Lookup references of Input Parameter(s) → Output Parameter.

· Location Reference Metadata (the name Location Level is used in the database and API) - this data may be static or dynamically generated.

In addition to read access, the ability to restrict and/or grant write/delete/create/update access to all data objects will be needed. For each data type, or some meaningful grouping of each data type, data administrators (e.g. Not IT Admins) will need to be able to grant and revoke the following appropriate access:

· ability to give write permissions to a specific object or group of objects; similar to the read access users would be restricted to being able to write to on a subset of objects

· restrict/grant ability to write to specific types of objects; i.e. time series values only, time series and locations, time series, locations, and ratings

· restrict/grant ability to create a new data object

· restrict/grant ability to delete data objects

· restrict/grant ability to update data objects Finally, a platform for individual office administrators to assign and revoke read/writer/create/delete/update access to individual users or groups of users will be required. This system will most likely be in the form of a web-based application to give administrative users access to user permissions. CDA provides multiple forms of identifier/token for Authentication; however, each token is directly tied to a user account. Such tokens could be used for access from external systems and users should be able to further restrict authorization per token to reduce attack surface.

The implementation of these objectives will be refined and adjusted based on recommendations from the Contractor. They are provided as a starting point to discuss possible solutions. Given the list of requirements, HEC needs to update the current method of simple Role Based Access Control to something that can better handle current and future use-cases. The new method should be robust enough to handle all of our data types, but easy to manage by Water Management staff.

1.4 Scope

Services to be performed include:

· Review of current data schema and access code

· Meeting participation and notes

· Development of possible solutions that implements an Authorization Scheme/Access Control Methodology to the current data model

· Present solutions to stakeholders

· Recommendation of final Authorization Scheme

· Development of detailed work-plan for authorization scheme

· Implement detailed work plan for authorization scheme

1.5 Terminology

· Authorization and Access control are used interchangeably throughout this document.

· USACE Staff and District Staff are used interchangeably through this document.

2.0 Specific Tasks

Technical Resources Note these relevant public Technical Resources:

· https://owasp.org/www-project-top-ten/

· https://github.com/USACE/cwms-data-api/

· https://github.com/HydrologicEngineeringCenter/cwms-data-api-client/

· https://www.hec.usace.army.mil/xmlSchema/cwms/

· https://bitbucket.hecdev.net/projects/CWMS/repos/cwms_database

· Docker images available

· registry-public.hecdev.net/cwms/database-ready-ora-23.5:latest-dev (a temporary instance with schema installed based on oracle-free database image)

· We plan to move the database source to a public repository at github.com/HydrologicEngeeringCenter. the timing of this is not known.

Functionality Functional requirements for all work under this PWS include:

· A report describing possible Authorization control methods that recommends a specific method or set of methods with supporting evidence.

· A web UI to allow technical or non-technical users to set appropriate access control on CWMS Database objects. CWMS developers currently use the React Framework to implement interfaces.

· Code changes to CDA to perform the appropriate authorization checks as defined by the users.

· Code changes to other components as identified to support authorization checks.

Work Unit A unit of work for this contract consists of at least one of the following:

1. Document addition or major edits that improve clarity

1. Meeting notes as described in Task 1

1. Code changes through pull requests that may be

2. Skeleton/strawman test code

2. Working test code (for example, code created to analyze a user reported issue that was not already covered and should be submitted as an additional regression test)

2. New code to implement a required feature or portion of feature, with appropriate tests

2. Refactoring code changes to improve functionality, with new tests if functionality is not already covered

3. New tests are not required for refactoring if the behavior is already covered under test

2. Tests, or proof that existing tests cover changes, are required for code changes.

Source Code Updates and Automated Tests Updates to source code and build scripts must also include necessary updates to existing automated testing processes to proceed successfully. For example, new arguments in a function call might require updates to a related unit test, or a change in dependencies could require updates to a Docker container. This requirement applies to existing tests that require only minor updates for compatibility with the new improvements. Automated integration tests are required for authentication and authorization code. There is a central build system that runs the integration tests and the CWMS-Data-API and CWMS Database integration tests are structured in such a way to allow local running in one of three ways:

1. Using Docker, through the testcontainers-java library, the ready-database (as described in Technical Resources) is started, and the tests are run.

1. Using Docker, through the testcontainers-java library, a new database is created, the schema installed, and tests run. The schema will be reinstalled for each run.

1. The tests can be pointed at an existing Oracle database for faster cycling. NOTE: The tests assume they can do anything they want to that database; this method should not be used against a shared database.

Data should be loaded as appropriate at the start of the test. It is expected that new tools and helpers will be required as additional endpoints for data are constructed. The Contractor should follow the existing design patterns where appropriate; deviations should be coordinated and are appreciated when necessary.

A specific, individual test for each element developed is not required. The goal of tests is to:

1. provide as-built style documentation

1. verify operation during refactoring and addition

1. guide development so at least one initial usage is seen and used

1. prevent future regressions by documenting user issues that have been resolved Tests should be designed in a way that shows natural usage of the API. The project goal is to have tests that cover all endpoints, not one test or test set per endpoint. If for any given set of controllers, it appears better to create a test or set of tests that covers both at multiple data sources, then this is preferred.

The Junit5 platform and REST Assured are currently used for tests against the API.

At minimum, tests must exist to demonstrate that the access control implemented both succeeds and fails correctly. The preferred test locations, in order, are with the existing junit5 unit tests, the junit5 integration test suite, anything repeatable locally, and anything repeatable by the build server (currently TeamCity, actively being migrated to GitHub actions.)

The integration tests use the testcontainers-java library to create, or use, an instance of a CWMS Oracle Database. An extension was created that the tests use. If additional services are required for implementation of the access control methods, then the starting of such services for the integrations should be added to the existing extension or a new extension as appropriate.

Security The Contractor is encouraged to operate the OWASP Zap tool on changes regularly. HEC staff will do this regularly. Software developed under this contract MUST be resilient to cyber-attacks such as SQL injection, parameter poisoning, cross-site scripting, and cross-site request forgery. Developers should regularly review the information provided at the OWASP Top Ten link in the technical resources section.

Coordination Some of this effort requires collaboration and coordination with HEC staff performing concurrent work regarding CWMS-Data-API or CWMS database. Some work under these tasks requires the Contractor to consult with HEC regarding certain design choices. This consultation, collaboration, and coordination must occur as part the ordinary course of software development for HEC.

All work necessary to complete a task is considered in scope of the task itself, including if the work is outside the primary source. For example, if it is determined that CWMS-Data-API code cannot function correctly without a correction to the CWMS Database Schema code, then a correction of the CWMS Database Schema code is part of the work needed to complete the task. Proper corrections to the Database Schema or other element are preferred; however, it is understood that this is not always immediately practical.

Since development of the CWMS-Data-API and CWMS database is being carried out by the Contractor, HEC, other USACE Staff, and other vendors, the Contractor should contact the Contracting Officer's Representative and Technical PoC if they think external changes have interfered with work in an unreasonable way.

Reviews and Work Acceptance For implementation work, HEC expects the Contractor to submit small units of work to be reviewed regularly as development progresses.

To support the review of small work units, HEC will maintain the following deliverable review schedule (days refer to business days):

· Meeting notes, 1 day

· Up to three source files or 200 lines of code changed or added, 3 days

· Up to ten source files or 500 lines of code changed or added, 5 days

· More than ten files or more than 500 lines of code changed or added, 10 days Acceptance of work by HEC will be noted in one of three ways:

· Marking a pull-request approved

· Approval text or label within a GitHub or Jira Issue

· Agreement in a comment that the work was performed but “overcome-by-events” for closed pull-requests or closed pull-requests not merged for valid reasons, such as waiting on staged work or waiting on updates from feedback.

HEC or District staff may review and provide comments on submissions.

2.1 Tasks

Task 1a - Authorization Plan Development Meetings There will be 6 hourly meetings, with meetings scheduled every two weeks to track progress and discuss bottlenecks or other impediments related to the completion of Task 2. Meetings may include up to three Contractor staff relevant to the current work. It is expected to take two hours to create and upload appropriate notes, create new issues, and update existing issues.

Task 1a Deliverables: The Contractor will provide meeting notes within 1 business day. Meeting notes must include at least one of the following:

· Typed minutes in Confluence

· Jira/GitHub issues (new or updated)

· Jira Epics or GitHub Milestones documenting intent from the meeting

· Skeleton pull requests with initial test names and descriptions Period of Performance for Task 1a - 90 Days from the Award of this PWS

Task 1b - Development Meetings - There will be 12 hourly meetings, with meetings scheduled every two weeks to track progress and discuss bottlenecks or other impediments related to the completion of Task 3. Meetings may include up to three Contractor staff relevant to the current work. It is expected to take two hours to create and upload appropriate notes, create new issues, and update existing issues.

Task 1b Deliverables: The Contractor will provide meeting notes within 1 business day. Meeting notes must include at least one of the following:

· Typed minutes in confluence

· Jira/GitHub issues (new or updated)

· Jira Epics or GitHub Milestones documenting intent from the meeting

· Skeleton pull requests with initial test names and descriptions Period of Performance for Task 1b - 180 Days from completion of task 1a

Task 2 Develop Authorization Plan- The Contractor will review the existing database schema (CWMS DB), REST API (CDA), use cases presented, supporting information in the Technical Exhibits, and interviews with HEC and District staff. Given this information, the Contractor will determine at least two appropriate authorization access models and a method of management of each authorization model, such as User Experience guidelines, and performance considerations at application run-time. For the purpose of this contract, all access to data will be through CDA.

Task 2 Deliverables: The Contractor will provide a report documenting:

1. At least two proposed methods of access control using our provided requirements.

1. An outlined plan for each proposed method.

1. A NIST Risk Management Framework suitable threat model analysis of each authorization model.

1. A comparative analysis of each method and a recommendation on which would be best given our current and known future requirements.

3. Specifically, challenges of implementation and configuration.

3. A brief analysis of runtime costs of access control checks and ways to mitigate possible performance issues.

1. A detailed plan for implementing the selected method within CDA and the CWMS Database Schema.

1. A detailed plan for implementing user interfaces for the selected method.

Period of Performance for Task 2 - 90 Days from the Award of this PWS

Task 3 Implementation for Authorization Plan - NTE - $184,775 The Contractor will implement the access control method selected by HEC by updating CDA, CWMS DB Schema, and other required systems as needed to handle the new access control method. HEC will select the access control method within 10 days of the completion of Task 2. In addition, the Contractor will create a web application to allow Water Management data managers to assign appropriate permissions to data objects based on the chosen access control method.

Task 3 Deliverables: - The Contractor will submit appropriate code, documentation, test code, and discussion notes continuously through the allotted period of performance. Each submission of work shall be complete for the definition of "Work Unit" provided above. The minimum successful product is an interface to manage access control, the access control method working for time series data, and the documentation and training materials.

Items to be implemented:

· Changes to CDA and other related projects to support the access control method selected.

· A web-based user interface suitable for individual and bulk manipulation of permissions by technical and non-technical users.

· Documentation and training materials for the selected method.

Period of Performance for Task 3 - 180 Days from completion of task 2 Technical Exhibit 1 - General Guidelines, Intent, and the Future All descriptions below, unless explicitly stated otherwise, are a statement of how things currently work, or how we are considering they should work in the future – it is the best information we have now. HEC remains open to improved methods of operation and design.

The main assumption for this effort is that all access to the database will be through the CWMS-Data-API. However, it should be known that at this time we allow direct access to the database using a combination of Oracle's VPD mechanism and some custom checks within our PL/SQL procedures. If it makes sense to use database features then they should be used, but if it is known not to be supported in other systems then there should at least be some documentation of how to replace that usage when the time comes.

We are also looking to migrate away from Oracle, possibly to a combination of data stores such as, but not limited to Object Storage and PostgreSQL. This will not happen before our cloud migration efforts are finished; we state this in case it informs any choices in implementation of the new access control model.

The CWMS AIS combines with District-controlled efforts which are effectively microservices. While the majority of these components may just rely directly on CDA and take advantage of new access control methods that way; it is possible that some of these services will contain their own specific data.

Vendors should assume that there exists a database shared by all Districts. Merging of the databases is a separate and on-going effort and not the responsibility of awardee of this contract. If work in this contract interferes with on-going on-premise operations, then HEC will take responsibility for managing those issues. Additionally, we can either host instances of databases on test infrastructure or vendors will have sufficient access, if not already made public, to the tools necessary to install a "raw" CWMS Schema into an existing oracle database for development and local testing.

Technical Exhibit 2 - Database Schema Entity Relationship Diagrams (not-complete)

Figure 1: Time Series Schema Entity Relationship Diagram Table 2: Rating Schema Entity Relationship Diagram Figure 2: Rating Schema Entity Relationship Diagram

Figure 3: Location Level Schema Entity Relationship Diagram Technical Exhibit 3 - Users The names used here are an example and not intended to be prescriptive names used in the final product if a superior name is discovered.

Would be able to store data related to model runs performed locally.

E.g. Perform data corrections, delete extraneous data on appropriate time series

NOTE:

1. It is possible for a single individual to be a Water Manager and a Data Manager.

1. It is possible for a single automated system user to perform Collection and Processing.

1. External Cooperators are not currently supported and are not a firm requirement.

Technical Exhibit 4 - Use Cases Raw Data Raw data is anything that comes in from an automated system. Examples are

· GOES data processed by our instances of the OpenDCS Application.

· Data scraped from partner/agency websites.

· Data from SCADA systems that is automatically pushed.

Automated systems are allowed to write, but not overwrite, raw data in time series. A general user should never be able to write to these time series.

Data Quality Assurance and Control Some staff are responsible for verifying the correctness of data. Automated systems will perform various checks, flag specific values if needed and copy this information to an intermediate time series.

Data QA staff will then review these time series using various tools and knowledge of the site's physics and hydrology to make corrections to the data. This could be filling in small gaps of missing data or removing spikes that are known to be erroneous, such as from known sensor bugs or maintenance.

Facilities Staff Staff at Dams and Locks are required to manually input data related to certain equipment that is not easily automated. These staff have limited need for data outside their area of operations and write to specific time series, usually gate settings and lake elevations. Other data may include manual precipitation gauges and related data.

Partners While we usually pull data from partner agencies and cooperators, it is possible it could make sense to allow direct writes by these users given appropriate authentication. Support of this is not required for successful implementation of the contract and is only mentioned to inform design choices.

Guest/General Public Guest is the name we are using for anyone not specifically authorized. With specific exceptions, CWMS provides data to the general public by law. Specifically, any data used to make an operational decision should be provided. Additionally, some Districts are more flexible with the public nature of the data collected. Data collected by the USGS, or through the GOES system are public by definition. To strike a balance, a time series should be restricted from the public by default unless it can be readily known it should be public; e.g. GOES is embedded in the time series name or other available metadata.

Restricted Data Districts sometimes require data from private entities to perform operations. Additionally, others access private data from entities that require it not be shared. Sometimes the restricted data can be made public after a time delay or if the data is processed as a cumulation/summation. For example, some dams in the Sacramento District require information from upstream dams owned by private power companies. By agreement, the power company allow the sum of storage to be shared, but not the individual storage values. In the same District, another private dam that shares data requires that sharing of the data be delayed to the public by 10 days except in flood conditions. Flood conditions does not necessarily mean actual damage and is more in line with the weather service usage of "monitor" and "flood" stages to indicate points of criticality.

· Any data that is private would not be seen in other table calls/endpoint lookups using CDA. For example, if a time series is defined as private then any reference to that time series in other lookups, such as the time series catalog, would exclude that time series from the output for any public user.

Legal Holds A least one District has had a time series put on a legal hold that prevents them from changing values even if it is known they are wrong. This would override the ability of the Data QA staff mentioned above to alter data. Such holds should allow for appropriate time (of the data values) restrictions so that live operations can continue; however, given the way legal operations work, specification of time should not assume only a fixed end date.

Records Some data will become part of a "RECORD." This is an official record of all data used to make a particular decision, such as the release from a dam, and may be requested by anyone who was affected by that decision. At this time, given the complexity of RECORDS, it is our assumption that actual records will be generated and stored in a separate system; however, this is not final and will likely be informed by the results of this contract.

Technical Exhibit 5 - Authentication Methods Authentication for CDA is provided by the following methods:

No other methods are planned for or expected at this time; however, any additional method would include sufficient information to be tied to a specific user.

In either case, API Token or OpenID Connect Token, the token itself or the information in the token is used to create a javax.security.Principal object that is set on the HttpRequest. If a session (e.g. session tied to a cookie) is used, this principal will have been saved as part of the session and contain at least the username and any application defined roles.

For OpenID Connect, the primary source will be a self-hosted Keycloak instance in which we can create roles and clients if needed. Login.gov is an option we are not currently using; we have no immediate plans, but it does remain on the table as something we may use in the future. Usage would be for the external cooperators discussed above. All employees authorized to use this system will have a valid DoD CAC that the self-hosted Keycloak will verify.

Identity management is outside the scope of this contract. The CDA docker-compose file provides an example of how a test Keycloak instance is used for development when needed:

Technical Exhibit 6 - Who Will be using this to Control Data Access The users who will be setting authorization for given data are from varying backgrounds. We have computer scientists, IT admins with security training, hydrologists, ecologists, civil engineers, and others that may need to understand or control who can use, see, alter, or delete a given piece of data.

Any interfaces should be reasonably easy to use for non-technical users while allowing advanced users to engage more directly with the access control configuration.

Technical Exhibit 7 – Sample Data Here is a sample query and the resulting timeseries for use in the evaluation criteria.

Request

· no authorization in this request, would be present in “Authorization” header if required

· The END date for this request defaulted to “now” at the time the request was made, around 2:45 PM Pacific Time on 2025-01-29.

curl -X 'GET' \ 'https://cwms-data-test.cwbi.us/cwms-data/timeseries?name=Black%20Butte-Pool.Stor.Inst.1Hour.0.Calc-val&office=SPK&unit=ac-ft&begin=2025-01-27T00%3A00%3A00-00%3A00&trim=false' \ -H 'accept: application/json;version=2'

Response:

The Date-time column is milliseconds since unix epoch utc.

"begin": "2025-01-27T00:00:00Z", "date-version-type": "UNVERSIONED", "end": "2025-01-29T22:45:05.79Z", "interval": "PT1H", "interval-offset": 0, "name": "Black Butte-Pool.Stor.Inst.1Hour.0.Calc-val", "office-id": "SPK", "page": "MTczNzkzNjAwMDAwMHx8NzF8fDUwMA==", "page-size": 500, "time-zone": "US/Pacific", "total": 71, "units": "ac-ft", "value-columns": [ "name": "date-time", "ordinal": 1, "datatype": "java.sql.Timestamp" "name": "value", "ordinal": 2, "datatype": "java.lang.Double" "name": "quality-code", "ordinal": 3, "datatype": "int" "values": [ 1737936000000, 38026.99884244786, 1737939600000, 38026.99884244786, 1737943200000, 38047.998841808614, 1737946800000, 38067.998841199806, 1737950400000, 38108.99883995176, 1737954000000, 38129.99883931251, 1737957600000, 38129.99883931251, 1737961200000, 38129.99883931251, 1737964800000, 38170.99883806446, 1737968400000, 38150.998838673266, 1737972000000, 38191.99883742521, 1737975600000, 38150.998838673266, 1737979200000, 38211.99883681641, 1737982800000, 38232.99883617716, 1737986400000, 38232.99883617716, 1737990000000, 38253.99883553792, 1737993600000, 38294.998834289865, 1737997200000, 38294.998834289865, 1738000800000, 38294.998834289865, 1738004400000, 38294.998834289865, 1738008000000, 38356.99883240257, 1738011600000, 38377.998831763325, 1738015200000, 38377.998831763325, 1738018800000, 38397.99883115452, 1738022400000, 38418.99883051527, 1738026000000, 38439.99882987602, 1738029600000, 38460.99882923678, 1738033200000, 38480.99882862798, 1738036800000, 38501.998827988726, 1738040400000, 38522.99882734949, 1738044000000, 38543.99882671024, 1738047600000, 38563.99882610143, 1738051200000, 38584.998825462186, 1738054800000, 38605.99882482294, 1738058400000, 38605.99882482294, 1738062000000, 38647.99882354445, 1738065600000, 38647.99882354445, 1738069200000, 38667.998822935646, 1738072800000, 38688.9988222964, 1738076400000, 38688.9988222964, 1738080000000, 38709.99882165715, 1738083600000, 38730.99882101791, 1738087200000, 38730.99882101791, 1738090800000, 38751.99882037866, 1738094400000, 38771.998819769855, 1738098000000, 38792.99881913061, 1738101600000, 38792.99881913061, 1738105200000, 38792.99881913061, 1738108800000, 38813.99881849137, 1738112400000, 38792.99881913061, 1738116000000, 38792.99881913061, 1738119600000, 38813.99881849137, 1738123200000, 38792.99881913061, 1738126800000, 38792.99881913061, 1738130400000, 38792.99881913061, 1738134000000, 38792.99881913061, 1738137600000, 38771.998819769855, 1738141200000, 38771.998819769855, 1738144800000, 38771.998819769855, 1738148400000, 38751.99882037866, 1738152000000, 38730.99882101791, 1738155600000, 38730.99882101791, 1738159200000, 38730.99882101791, 1738162800000, 38709.99882165715, 1738166400000, 38709.99882165715, 1738170000000, null, 1738173600000, null, 1738177200000, null, 1738180800000, null, 1738184400000, null, 1738188000000, null, image1.png image2.png image3.png