Update get_precis_forecast and get_historical functionality

[PaulMelloy]

Description

Updated get_precis_forecast.r to allow it to import forecast from xml files stored on the local machine. Updated get_historical.r so it will allow batch downloads using the lapply function by removing a stop() command and replacing it with a warning and returning data.frame with NA values. Changed internal_functions.R to allow xml import from a local origin

Example

Subset BOM stations by distance of 200km from latlon.

stations <- sweep_for_stations(latlon = c(-26.56, 151.93))
stations <- subset(stations, distance <= 200)
head(stations)

station_data <- lapply(stations$site, 
                       get_historical,
                       type = "max")

class(station_data)

AUS_XML <- c(
  "IDN11060.xml",# NSW
  "IDD10207.xml",  # NT
  "IDQ11295.xml",  # QLD
  "IDS10044.xml",  # SA
  "IDT16710.xml",  # TAS
  "IDV10753.xml",  # VIC
  "IDW14199.xml"  # WA
)
for(State in AUS_XML){
curl::curl_download(
  paste0("ftp://ftp.bom.gov.au/anon/gen/fwo/",State),
  destfile = file.path(tempdir(), State),
  mode = "wb"
)}

forecast1 <- get_precis_forecast(filepath = file.path(tempdir(),"/"))
head(forecast1)
forecast1 <- get_precis_forecast(filepath = file.path(tempdir())) # wrong filepath
head(forecast1)
forecastQ <- get_precis_forecast(state = "QLD", file.path(tempdir(),"/"))
head(forecastQ)
forecastQ <- get_precis_forecast(state = "QLD") # testing normal function
head(forecastQ)
forecast2 <- get_precis_forecast() # testing normal function
head(forecast2)

[jonocarroll]

An alternative approach would be to handle multiple stations inside get_historical, the result being a bind_rows of the individual station data.

[PaulMelloy]

Would bringing that functionality inside the function be preferable?

[jonocarroll]

It's just a thought - it would mean a single (nicely printed) result with a potential grouping variable. Mostly depends on what a user would most likely want to do with multi-station data.

[adamhsparks]

Yeah, I guess what @jonocarroll is suggesting is my default behaviour for GSODR. Internally it just puts everything into one large data.frame object and returns that to the user.

I think that is a cleaner way to do it, now that I think about it. Using lapply() and the like doesn't seem to offer much more utility that I can think of.

Do you want to change that, @melloy, or leave it with me?

[PaulMelloy]

I can add that functionality

[PaulMelloy]

I have updated the function so it can pull multiple data from multiple stations and return it as a bomrang_tbl data.frame. Users will be able to query historical data in multiple ways. HOWEVER I am getting an error when I call the object the data is assigned to. The data is downloaded and saved but when I want the data frame I get this error.

I thought the brains trust might know more about this error. I think it has something to do with the bind_rows and the bomrang_tbl class, specifically when it tries to bind the NA dataframes, which don't have the requested data and the successfully downloaded data. Any help would be much appreciated.

When the error is corrected I'll initiate a new pull request.

Error

Error in tools::toTitleCase(attr(x, "type")) : 'text' must be a character vector

Test code for package update

devtools::install_github("melloy/bomrang")
library(bomrang)

weather_data <- get_historical(latlon = c(-26.56, 151.93),radius = 100, type = "max")
head(weather_data)
weather_data <- get_historical(latlon = c(-26.56, 151.93), type = "max")
head(weather_data)
weather_data <- get_historical(stationid = 86307, type = "rain")
head(weather_data)
weather_data <- get_historical(stationid = 86307, type = "rain",radius = 100)
head(weather_data)
weather_data <- get_historical(stationid = 86307, type = "rain",radius = 100)
head(weather_data)

stationids <- subset(sweep_for_stations(latlon = c(-26.56, 151.93)),distance <= 100)
weather_data <- get_historical(stationid = stationids$site, type = "rain")
head(weather_data)

[PaulMelloy]

Also when it binds rows dplyr throws up warnings. If there is not a good idea to fix these, I'll suppress the warnings

[adamhsparks]

There should be no warnings in the package going to CRAN. We'll need to fix that.

I've spent the weekend working on GSODR updates, will try to have a look at this when I have time before I leave, @jonocarroll, feel free if you have time, but don't feel obligated.

[jonocarroll]

Fixes in #106 (and/or updating to development dplyr) seem to resolve bind_rows errors, in which case this PR would just need to wait for the new dplyr to hit CRAN.