CWMVUE-634 Implements Access To Water Endpoint

[rma-bryson]

No description provided.

[adamkorynta]

"type" is a bit ambiguous, especially that is is describing the type of parameter (but not to be confused with parameter type inst/ave/const/etc). otherwise the structure looks good. I'd probably prefer parameter even if it doesn't exactly match the parameter in the time series identifier.

[MikeNeilson]

I don't hate it, but it's not giving me any warm and fuzzies for the future either.

@jeffsuperglide, @adamscarberry can you grant @rma-bryson and @adamkorynta at least read access to the access to water repositories to see how you're using the various A2W tables. I don't recall the usage being super high. But since this particular interface and objects will be new to everyone it's a good time to at least consider changes to how the data is presented and I'm not involved enough on the A2W side to say if the proposed design will be sensible.

It may just be that these new endpoints are only used for the district level control of things and it may not matter, but better to get a conversation started sooner rather than later.

@rma-bryson I would suggest also considering the following scenario to provide a little more insight:

• 3 dams from different districts
• at least 3 different elements of data for each.

The current example and test has one, which isn't a good sample size for something that could be rather foundational to our various operations.

[adamscarberry]

@MikeNeilson Invites sent to @rma-bryson and @adamkorynta to join a2w-readonly team.

You will find the majority of the sql here: https://github.com/USACE/a2w-api/blob/60558999c32d3ea4c0f477812cb5dc53e77e267f/api/models/locations.go#L83-L358

or here: https://github.com/USACE/a2w-api/blob/develop/api/models/timeseries.go

@jeffsuperglide is the POC for the a2w-api

[rma-rripken]

If I'm understanding these changes I'm not loving them. I picture CwmsId as a lightweight {office,id} pair. If I'm understanding this PR CwmsId now has an additional map of additional properties that it carries with it. Properties are added/removed per instance at runtime and properties can be "required" at runtime. Why are we changing every CwmsId across the application instead of creating a new class that can be used where this is needed? Why even do it dynamically like this? Wouldn't explicitly naming the fields be better, not just for CDA but for documenting the input/output and for our code-gen clients. Whats the performance overhead of this? If I'm reading this right both collections are instantiated whether they are used or not. I think I need to be convinced b/c right now this is a nope from me.

[MikeNeilson]

Perhaps this was written before we had better established the required parameter validation.

But coming back to it a few months later I'm just as confused. We did add, or at least discuss, some flexible properties fields, but there's clearly isn't that even though it read that way on first glance -- until I saw the required and validation everywhere.

[rma-bryson]

Yeah, I don't remember the exact discussion that lead to the properties map, but I don't love it looking at it now. Doesn't that defeat the whole purpose of having a well-defined schema?

If we want an "id" object that contains kind and bounding office id, then I would think we just make a new ID object that contains those?

[krowvin]

Could help out with
#956

Talked about this on 05/18/26 CDA call.

[krowvin]

I do not agree with continuing to name things "accesstowater". Access to water does not name things access to water still (afaik). This goes for endpoint name and class names.

Perhaps this ties into "BEST"? (Sidebar in call With Peter and Eric N about standard naming)

/catalog/{ONESUBNAMETORULETHEMALL/{location-id}/{type}?office=SWT

/catalog/{ONESUBNAMETORULETHEMALL}?location-id=SWT&office=SWT&type=elev

Some sidebar about alias and whether or not "best" is what this should even be called.

Right now not everyone names their TSID version "best"

TBD