locations endpoint

[mdstanfill]

I'm trying to get a list of locations by responsibility, and am (currently) resigned to the limitation that the locations endpoint can only limit by office and names (with parameters for unit, datum, and format), so that I'll have to query all the locations for the office and sift through the results on the client side.

What I'm finding is that unless you specify a names parameter, and it's fairly restrictive, the endpoint returns a 500 error: "failed to process request". I've tried this with the 3.0 version, the 3.14rc3 version I was testing with, and the 3.14rc4 version I saw when I first went to GitHub to see if there were any notes on this. On the off chance that unit and datum limit the set of locations returned, I set those as well, but to no avail. E.g.:

curl -X 'GET'
'https://wm.nwp.ds.usace.army.mil:8243/nwdp-data-314rc4/locations?office=NWDP&unit=EN&datum=NGVD29'
-H 'accept: application/json;version=2'

returns:

{
  "message": "failed to process request",
  "incidentIdentifier": "-47285136831436488",
  "details": {}
}

as does the earlier version of the API:

curl -X 'GET'
'https://wm.nwp.ds.usace.army.mil:8243/nwdp-data/locations?office=NWDP&unit=EN&datum=NGVD29'
-H 'accept: application/json'

I do get something back if the names parameter results in few results, e.g., AB:

curl -X 'GET'
'https://wm.nwp.ds.usace.army.mil:8243/nwdp-data-314rc4/locations?names=AB&office=NWDP&unit=EN&datum=NGVD29'
-H 'accept: application/json;version=2'

but not, say, B:

curl -X 'GET'
'https://wm.nwp.ds.usace.army.mil:8243/nwdp-data-314rc4/locations?names=B&office=NWDP&unit=EN&datum=NGVD29'
-H 'accept: application/json;version=2'

[MikeNeilson]

If you doing any kind of searching on timeseries or location we strongly recommend the catalog endpoint. It has more query options, such as groups and categories. And the bounding office field.

That all said, you are going to have a hard time searching by "responsibility" by that name as that's not a concept that the CWMS Database Schema was designed around (though in hindsight clearly makes sense to have done so) but we did expose the bounding office field in the catalogs since it was being used that way.

[mdstanfill]

Thank you! This is a much better way of looking for what I want. I'll give e.g. catalog/LOCATIONS?office=NWDP&bounding-office-like=NWS a shot. We are using bounding-office as responsibility, it appears. I'd thought they were separate fields. We have several reports that break down on responsibility lines (so people can do QA/QC for their own projects and gauges), and this will help a lot.

[MikeNeilson]

Office and bounding office are different fields. But the intent of office honestly was never super clear, but bounding office was intended for geography.

Nothing wrong with what your district did, it was the tool at hand, but the "Responsible party" idea has a lot of merit and I think we should expand on it a little in the future, meta data like PoCs sounds really useful and we could then actually use bounding office as a geographic bounding.

Short term: keep using bounding office as "responsible party", we reverted a change in the next schema release to make sure we didn't break that.

Have someone on your team think about the need more fully and at a minimum we'll add a 3rd office column with that name, or we can create some more tables; already have an "entity" table for other agencies but we can add more data..... I now I realize I need to go make sure we're exposing those entities for use within CDA.

[mdstanfill]

I previously thought there were three fields: office (NWDP for us), bounding office (geographic), and responsible office (political). We must have labeled bounding office as responsible office externally to avoid confusion for users, and ended up causing confusion for developers. :-) The particular query I'm trying to replicate would additionally benefit from an "active" flag. We have a number of inactive locations for historical data and such, but we don't need to QA/QC them. I can filter them out once returned, of course, and will do so. I'm also going to try negative-lookahead regex matching to see if I can get the location-kind-type down to "not STREAM or BASIN", but I there are probably comparatively few of them, and I can also filter if that doesn't work.

Thanks again for the quick response.