Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read KNMI files locally #90

Closed
martinvonk opened this issue Feb 6, 2023 · 4 comments · Fixed by #139
Closed

Read KNMI files locally #90

martinvonk opened this issue Feb 6, 2023 · 4 comments · Fixed by #139
Assignees
Labels
enhancement New feature or request question Further information is requested

Comments

@martinvonk
Copy link
Collaborator

I would like a feature where we can read KNMI observations (to an Obs(Collection)) from a local file. I know we already do this internally so it should not be that hard to implement right?

@martinvonk martinvonk added enhancement New feature or request question Further information is requested labels Feb 6, 2023
@martinvonk martinvonk changed the title Read KNMI files Read KNMI files locally Feb 6, 2023
@martinvonk martinvonk self-assigned this Feb 6, 2023
@OnnoEbbens
Copy link
Collaborator

Yeah good idea! The functions get_knmi_daily_rainfall_url and get_knmi_daily_meteo_url need to be modified slightly to allow this.

@OnnoEbbens
Copy link
Collaborator

OnnoEbbens commented Feb 7, 2023

some extra wishes:

  • read all parameters from a knmi file as an ObsCollection
  • add normalize_index to all timeseries
  • make parameters more consistent. start, tmin, startdate are all interchangeable

@OnnoEbbens
Copy link
Collaborator

Another wish: merge the from_knmi, from_nearest_xy, from_obs and from_knmi_file to one single method. Move all the logic to the io_knmi module

@martinvonk
Copy link
Collaborator Author

Another wish: merge the from_knmi, from_nearest_xy, from_obs and from_knmi_file to one single method. Move all the logic to the io_knmi module

We could also rename from_knmi to from_station and let from_knmi autodetect whether the first argument is a tuple with x and y (call from_nearest_xy), is an int (call from_station), is a str (call from_kni_file) etc. Then we can also leave the other methods intact at this place?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants