mroberge/hydrofunctions

redundant HydroUserWarning

Closed this issue · 2 comments

cheginit commented
  • HydroFunctions version: 0.1.8dev
  • Python version: 3.7.3
  • Operating System: Ubuntu

Description

When I use bBox to find a station I get a warning about frequency being set to zero. I think this warning is not relevant for this type of inquiry.

On another note, I noticed that if I use a number with more than 7 decimal figures for the lat and long, say -121.74788222 instead of -121.74788 in the following example, it throws an error (JSONDecodeError: Expecting value: line 1 column 1 (char 0)). It is a limitation with the query that is sent to USGS service. So I think it would be a good idea to round the lat and long up to 7 decimals before sending the inquiry.

A small note on the error, there is a space missing between frequency and for (frequencyfor).

What I Did

import hydrofunctions as hf

hf.NWIS(bBox=[-121.74788, 47.38594, -121.54788, 47.58594])

....hydrofunctions/hydrofunctions/hydrofunctions.py:100: HydroUserWarning: It is not possible to determine the frequencyfor one of the datasets in this request.This dataset will be set to a frequency of 0 minutes
mroberge commented

@taataam Thank you for filing this issue! That is great that you are using the 'development' version of hydrofunctions. Any feedback I can get right now is really useful. Have you tried using the NWIS.df('q') selectors yet?

  • This new version of HF tries much harder to figure out the frequency of the measurements in a time series. Unfortunately, I don't have a way of dealing with requests to the USGS for the most recent data. Right now my approach is to set these with a frequency of <0 Minutes>. I can eliminate the warning for this situation, but I'm concerned about what happens if this situation is triggered by accident...?

  • I like the idea to round off the lat/long inputs. Since this is a bounding box, it doesn't make much sense to use more than a couple of digits past the decimal. I'll look more carefully into the source of the JSONDecodeError. It may just be that JSON can only handle up to double precision floats? IDK. I guess a note should be made somewhere in the docstring or the manual telling the user the maximum number of allowable digits. If the software rounds off the number without telling the user, that might cause some people to waste their time with digits that silently get removed.

  • I'll fix the spacing error.

cheginit commented

@mroberge Is it a new stations selector?

I didn't mean that the warning is redundant altogether, I meant that for selecting a station that frequency is irrelevant having this warning is not necessary. It's a useful when a user is requesting for actual data. I was thinking if in the arguments bBox is not None then you can even skip checking for frequency because the out put would be only the station IDs.

Regarding the decimal places, it is a limitation related to the final produced link. Here's an excerpt from USGS guidelines for REST service:

Use decimal degrees rather than degrees, minutes and seconds. Decimals are not required, but only six decimals of precision will be used

and this is the link(you can click on the question mark beside the lat-lon Box to see this explanation. So I think it is safe to round lat and long since it doesn't affect the results anyway.

The reason I stumbled upon this error is that I had x, y of a point in a watershed and then converted into lat and long with reprojection so the results had more than 7 decimals. That's when I got that error and found out the cause of this error.