Closed SarahGoslee-USDA closed 3 years ago
Hi @sgoslee thank you for this! I really appreciate your time in checking this. You also found the error perfectly. I had moved the -1 indexing to define.dates and forget to remove it from the getGridMet
url creation 🤦 . The last push should give the following:
library(climateR)
library(sf)
#> Warning: package 'sf' was built under R version 4.0.2
#> Linking to GEOS 3.8.1, GDAL 3.1.4, PROJ 6.3.1
# create an example point
data.frame(lon = -96.89999276, lat = 31.51999451) %>%
st_as_sf(coords = c("lon", "lat"), crs = 4326) %>%
getGridMET("tmax", startDate = "1979-01-01", endDate = "1979-01-02")
#> source lat lon date tmax
#> 1 gridmet 31.525 -96.89167 1979-01-01 268.8
#> 2 gridmet 31.525 -96.89167 1979-01-02 272.4
# Compare to your local results!
# X28854 X28855
# 268.8 272.4
Created on 2021-03-09 by the reprex package (v0.3.0)
Which matches your local results. Thank you again!
Mike
Thanks for your prompt fix! I can confirm that the current version matches my expectations for GridMET.
In getGridMET, the base date used in
d = define.dates(startDate, endDate, baseDate = "1979-01-01")
followed by subtracting 1 from the date.index inresults in a malformed url when trying to obtain the beginning of the dataset, and returns dates that are consistently off by one day in later time series.
This is not observed with getPRISM, which doesn't specify a base date, but does appear with other get functions.
Here is a reproducible example comparing the results of getGridMET() and data extracted from a downloaded NetCDF file in the working directory.