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

time argument of get_pvol could be more flexible #2

Open
bart1 opened this issue Oct 14, 2024 · 3 comments
Open

time argument of get_pvol could be more flexible #2

bart1 opened this issue Oct 14, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@bart1
Copy link
Collaborator

bart1 commented Oct 14, 2024

currently time should be a POSIXct rounded to 5 minutes we might consider also allowing for intervals and multiple timestamps. The individual functions now only download one file at a time and do not parallelize requests.

@bart1 bart1 mentioned this issue Oct 14, 2024
@bart1 bart1 added the enhancement New feature or request label Oct 15, 2024
@peterdesmet
Copy link
Member

  • For internal functions, I would pass POSIXct in UTC.
  • For user facing functions, I would allow POSIXct and ISO strings, which are then converted with lubridate
  • Would be good to support intervals, as lubridate or base durations
  • There should be a translation from user-provided timestamp/interval, to closest matching precision (e.g. 5 min)
  • Parallelisation will be useful/necessary at some point

@bart1
Copy link
Collaborator Author

bart1 commented Oct 15, 2024

We tend to refer to the volume radar data in 5 minutes intervals but I think sometimes there is a bit of ambiguity to what time the radar data refers. The time in the data for in cz is for example 4 minutes after the reference time. Although the scans start pretty much directly at the reference time. I would need to look a bit more into this

require(getRad)
#> Loading required package: getRad
pv<-get_pvol("czska",t<- as.POSIXct(Sys.Date())+lubridate::hours(3))
t
#> [1] "2024-10-15 03:00:00 UTC"
pv$datetime
#> [1] "2024-10-15 03:04:12 UTC"
bioRad::attribute_table(pv, select=c("where.elangle","what.endtime","what.starttime"))[,-4] 
#>    what.endtime what.starttime where.elangle
#>          030412         030345           0.1
#> 1        030343         030316           0.5
#> 2        030314         030251           0.9
#> 3        030250         030227           1.3
#> 4        030225         030202           1.7
#> 5        030201         030138           2.2
#> 6        030136         030114           3.2
#> 7        030112         030100           4.5
#> 8        030058         030045           6.3
#> 9        030041         030030           8.7
#> 10       030027         030016          13.7
#> 11       030013         030003          21.6

bart1 pushed a commit that referenced this issue Oct 16, 2024
@bart1
Copy link
Collaborator Author

bart1 commented Oct 16, 2024

Now time can be a vector rounded to the nearest 5 minutes and is checked, parallelization / request optimization I will leave for later

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

No branches or pull requests

2 participants