Propose new function: `download_vpts()`

[PietrH]

Recently we needed to get a bunch of vpts files locally with some date filtering. I modified get_vpts() to help me do this.

I think it would be useful (to future me, and hopefully others) to have a dedicated exported function for this: download_vpts() that is called by get_vpts() internally.

I've already done a bit of work on this, but will need some time to polish and integrate into get_vpts().

The function would accept the following arguments:

• radar
• datetime
• source
• path

And would invisibly return the paths of the downloaded files. Alternatively, the directory path of where the files were stored. This path could then be fed to future calls of get_vpts() so files don't need to be downloaded again.

What do you think?

[bart1]

This might also link to adokter/bioRad#781 . It is a use case I do not have frequently but seems to be more common. For me I generally have good internet and it would fill up my disk.
I think the same concerns exist for vpts and pvol. i.e. do we want to store original files or write files from memory? Do we want to store as rds or csv/h5?

[PietrH]

I think the current behavior of get_vpts() and get_pvol() is alright, but offering the option to store the files without parsing them at all is useful to me.

In this case I was regenerating the monthly summary files. But there are other use cases as well I'm sure. We could limit it to baltrad initially if that is more future proof?

[bart1]

Ok, Ideally I avoid functionality that does not work for all sources/generally. It is already tricky enough to see what is supported in the package. To save data without parsing would require updates/maintenance to all source specific functions. That is an option but would be good to not take too lightly.

[bart1]

Ideally I would wish to provide users with a good round trip experience if we provide a download option. This would be a simple similar interface for download like the get_* functions. But also a good way to load the data later on.

I'm not sure if people are more interested in I see a few use cases:

• a local cache for when they are offline
• a local cache for repeated access
• processing the files in an other program
• options to explore the raw/ unprocessed files

[PietrH]

I'm personally more interested in the latter two options, less in local caching. But I may not be a typical user.

I wouldn't load files with the download_vpts() function, but merely download them and output the path

[bart1]

I guess get_vpts currently has the option to use the path argument that should help read back the data. If you download data it should be easy to read it that way.

For the first two use case options we could work on the cache mechanisms and add a cache argument that would however not help you. I would say it is good to see what people would use it for @adokter I guess your use cases would fall in the first to options? Do we have other users with similar requests?