Allow NWW, NWS, and NWP to be used as the "office" string within CDA

[david-a-ries]

As it stands, in order to interact with NWW data on CDA, the office string "NWDP" needs to be used as the office string. I noticed in the catalog endpoint, if the primary office is set to NWDP, I am able to set the bounding office to NWW and get a list of only the gauges that are utilized by NWW (https://cwms-data.usace.army.mil/cwms-data/catalog/TIMESERIES?office=NWDP&bounding-office-like=NWW).

I was wondering if there would be a way to make it so putting NWW in the office field will directly filter NWW bounding office data from NWDP as both internal and external users might not know to search under NWDP? The example I looked at is that SPA is under the SPD division but you can access SPA data specifically without having to include a “bounding-office-like” field

[MikeNeilson]

For your SPA example, that's because while SPA is logistically under the SPD division, the data is owned by SPA and thus office id is SPA.

NWDP and NDWM are the only division that combine all the districts data under a single division. Though getting all data under a division office is certain something with a lot of merit; I could see that being fairly useful.

However as it stands the office-id (we refer to it as the "owning office") and the bounding-office (which apparently was supposed to be a geographic bounding but well, you've seen your data) is more "who's responsible for the location."

So there isn't really a generic way to handle that situation. However, just using NWW in the bounding office should work. If not we would need to update the query. But I can't see a way to handle your request without breaking the current logic of the columns (well, as designed anyways.)

[JeremyDKellett]

Adding this as the predicate should do it:Case when :office_id in (‘NWW’,’NWS’,’NWP’) then db_office_id = ‘NWDP’Else db_officeid = :office_id endAndCase when :office_id in (‘NWW’,’NWS’,’NWP’) then Bounding_office_id = :office_idElse bounding_officeid = :office_id endExcuse the mobile device pseudocode. On Jun 27, 2024, at 11:17 AM, Mike Neilson @.***> wrote: For your SPA example, that's because while SPA is logistically under the SPD division, the data is owned by SPA and thus office id is SPA. NWDP and NDWM are the only division that combine all the districts data under a single division. Though getting all data under a division office is certain something with a lot of merit; I could see that being fairly useful. However as it stands the office-id (we refer to it as the "owning office") and the bounding-office (which apparently was supposed to be a geographic bounding but well, you've seen your data) is more "who's responsible for the location." So there isn't really a generic way to handle that situation. However, just using NWW in the bounding office should work. If not we would need to update the query. But I can't see a way to handle your request without breaking the current logic of the columns (well, as designed anyways.)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[MikeNeilson]

As a counter point, if we implement that, admittedly simple, edge case every one is going to want an edge case somewhere, which is not sustainable.

[JeremyDKellett]

I forgot a NVL on both sides of the last line. will clarify it when in front of a computer.  On Jun 27, 2024, at 1:51 PM, JEREMY KELLETT @.> wrote:Adding this as the predicate should do it:Case when :office_id in (‘NWW’,’NWS’,’NWP’) then db_office_id = ‘NWDP’Else db_officeid = :office_id endAndCase when :office_id in (‘NWW’,’NWS’,’NWP’) then Bounding_office_id = :office_idElse bounding_officeid = :office_id endExcuse the mobile device pseudocode. On Jun 27, 2024, at 11:17 AM, Mike Neilson @.> wrote: For your SPA example, that's because while SPA is logistically under the SPD division, the data is owned by SPA and thus office id is SPA. NWDP and NDWM are the only division that combine all the districts data under a single division. Though getting all data under a division office is certain something with a lot of merit; I could see that being fairly useful. However as it stands the office-id (we refer to it as the "owning office") and the bounding-office (which apparently was supposed to be a geographic bounding but well, you've seen your data) is more "who's responsible for the location." So there isn't really a generic way to handle that situation. However, just using NWW in the bounding office should work. If not we would need to update the query. But I can't see a way to handle your request without breaking the current logic of the columns (well, as designed anyways.)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[krowvin]

every one is going to want an edge case somewhere

makes me think of

• 393

As a district having no idea how their site is setup I was trying to call NWP and only get ~17 locations back on the catalog. I was fairly confused. IMO they need something soon.

Because what David said:

both internal and external users might not know to search under NWDP

Happened to me!