You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a fundamental design discussion we should have about protecting the user against potentially impossible requests. The main reason era5cli exists is to facilitate a data request easily in a workflow, not to make sure a request is solid. There are various checks on the call done at the moment, but they are diffuse and scattered throughout the tool. We could take this two ways:
We implement a single "request checker" that applies all checks (i.e. are the variables correct; are variables possible given the time frame of hourly or monthly; are there no impossible combinations of flags, etc) in one place, so a clear overview gets created and checks are not duplicated or missed.
We do not wish to validate a request but simply translate a quick CLI call into an API request, and let CDS determine whether this results in data or not. This means we will keep the checks inside the tool to a minimum.
There are middle grounds here and combinations, of course, but this is a fundamental conversation we should have that will inform further development.
The text was updated successfully, but these errors were encountered:
There is a fundamental design discussion we should have about protecting the user against potentially impossible requests. The main reason era5cli exists is to facilitate a data request easily in a workflow, not to make sure a request is solid. There are various checks on the call done at the moment, but they are diffuse and scattered throughout the tool. We could take this two ways:
There are middle grounds here and combinations, of course, but this is a fundamental conversation we should have that will inform further development.
The text was updated successfully, but these errors were encountered: