As a user, I want to clarify that WRES reads data from NWIS in json format, not waterML

[epag]

---

Author Name: Hank (Hank) Original Redmine Issue: 129481, https://vlab.noaa.gov/redmine/issues/129481 Original Date: 2024-04-30 Original Assignee: James

---

I've posted an email, below, from one of the "product owners" of USGS water services. Please review. I believe the WRES reads WaterML from USGS NWIS, but I could be wrong. Apparently, they offer a JSON version which will not be impacted, so we should switch to that.

If I'm wrong about us reading the WaterML from USGS NWIS, please let me know and I'll reject this ticket. Thanks,

Hank

==========================================================

I am reaching out today in regards to “legacy” Water Services as you know it to exist at https://waterservices.usgs.gov/. Recent security related updates to MySQL and other dependencies have impacted legacy Water Services ability to serve IV data in WaterML format and GW Levels data in RDB formats. We no longer have the technical ability in house to refactor these endpoints to conform to the changes in the dependencies. This security patching has only been done on an internal development environment and has not been released to the public. However, due to security requirements we will need to push the patched build of Water Services to public production by the end of FY24Q3.

So, we are in a position that we will need to release a version of Water Services that is no longer able to return IV and GW Levels data in all combinations previous formats. The JSON return types for IV and GW Levels data still function and perform as expected. No other data types are effected at this point (to our knowledge). This impaired form of legacy Water Services will have to suffice until “modernized” Water Services replacement comes on line in FY25.

[epag]

---

Original Redmine Comment Author Name: Hank (Hank) Original Date: 2024-04-30T11:21:10Z

---

I'm going to up the urgency on this one. We need the change in place ASAP and no later than by the end of this quarter (i.e., the end of June).

James: When you have some spare time, can you provide a time estimate for this work? I think it will need to be either you or Evan, though there is a chance that I could find some spare time soon. Regardless, I think you are in the best position to provide that initial time estimate.

Thanks,

Hank

[epag]

---

Original Redmine Comment Author Name: James (James) Original Date: 2024-04-30T11:50:55Z

---

I will double-check, but I am pretty sure this is just a nomenclature issue. It currently reads json for sure. We read uris like this:

https://nwis.waterservices.usgs.gov/nwis/iv?endDT=2019-01-01T00%3A00%3A00Z&format=json&parameterCd=00060&sites=02420000&startDT=2018-01-01T00%3A00%3A01Z

Note @format=json@.

I think what happened is that the original classes were named incorrectly on the basis that "waterml" is a standard across formats, but it isn't AFAIK, it is built on XML. Now is probably a good time to rename them, so my estimate for this ticket would be something like "2" bananas :)

Let me double-check, but I distinctly remember being confused about the original choice of naming when refactoring these classes to adhere to the new pull-driven api.

[epag]

---

Original Redmine Comment Author Name: James (James) Original Date: 2024-04-30T11:53:31Z

---

Yeah, there are some tell-tale signs, like @DataDisposition.JSON_WATERML@.

[epag]

---

Original Redmine Comment Author Name: James (James) Original Date: 2024-04-30T11:56:26Z

---

Other than the code itself (@NwisReader@)...

urlParameters.put( "format", "json" );
</code>

...I think #93486 is the smoking gun. Just need to rename to avoid confusion.

[epag]

---

Original Redmine Comment Author Name: Hank (Hank) Original Date: 2024-04-30T12:40:55Z

---

Got it. Yes, the use of "WaterML" was confusing, since I thought that was XML by definition, not JSON.

Hank

[epag]

---

Original Redmine Comment Author Name: James (James) Original Date: 2024-07-01T10:00:21Z

---

Will probably use this one to test the github workflow shortly as it's a small ticket and would be simpler to fix than migrate.

[epag]

---

Original Redmine Comment Author Name: Evan (Evan) Original Date: 2024-07-02T13:25:24Z

---

Moving to 6.25 as im deploying 6.24 now

[epag]

---

Original Redmine Comment Author Name: James (James) Original Date: 2024-07-26T11:56:18Z

---

Oh well, didn't complete in time, so migration to github needed.