ropensci / FedData

Functions to Automate Downloading Geospatial Data Available from Several Federated Data Sources
https://docs.ropensci.org/FedData
Other
97 stars 22 forks source link

errors with nc_open #27

Closed jsocolar closed 7 years ago

jsocolar commented 7 years ago

If I run exactly the code given in the example page for the DAYMET data, I get an error:

library(FedData)
library(magrittr)

testDir <- "~/FedData Test"
dir.create(testDir, showWarnings=F, recursive=T)
setwd(testDir)

vepPolygon <- polygon_from_extent(raster::extent(672800,740000,4102000,4170000), + proj4string="+proj=utm +datum=NAD83 +zone=12")

NED <- get_ned(template=vepPolygon, + label="VEPIIN")
Area of interest includes 2 NED tiles.
(Down)Loading NED tile for 38N and 109W.
Downloading file: https://prd-tnm.s3.amazonaws.com/StagedProducts/Elevation/1/ArcGrid/n38w109.zip
(Down)Loading NED tile for 38N and 110W.
Downloading file: https://prd-tnm.s3.amazonaws.com/StagedProducts/Elevation/1/ArcGrid/n38w110.zip
Mosaicking NED tiles.

raster::plot(NED)

# So far so good, but then:

DAYMET <- get_daymet(template=vepPolygon, + label="VEPIIN", + elements = c("prcp","tmax"), + years = 1980:1985)
Area of interest includes 1 DAYMET tile(s).
(Down)Loading DAYMET tile 11376

Error in { : 
  task 1 failed - "task 1 failed - "Error in nc_open trying to open file /Users/TingleyLab/FedData Test/RAW/DAYMET/11376/1980/prcp.nc""

Note that the relevant .nc files do show up in the expected directory on my computer. When I try to open them with ncdf4::nc_open(), I get an error: "Error in R_nc4_open: NetCDF: Unknown file format" followed by the same error shown above, beginning from "Error in nc_open..."

sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.11.6 (El Capitan)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] magrittr_1.5  ncdf4_1.15    FedData_2.3.2 rgdal_1.2-4   rgeos_0.3-21  raster_2.5-8  sp_1.2-3     

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.7       lattice_0.20-33   codetools_0.2-14  lubridate_1.6.0   assertthat_0.1    foreach_1.4.3    
 [7] grid_3.3.1        stringi_1.1.2     curl_2.3          data.table_1.9.8  doParallel_1.0.10 iterators_1.0.8  
[13] tools_3.3.1       readr_1.0.0       stringr_1.1.0     compiler_3.3.1    parallel_3.3.1    tibble_1.2
jsocolar commented 7 years ago

I may have figured it out... If I point my browser to, for example, http://thredds.daac.ornl.gov/thredds/fileServer/ornldaac/1328/tiles/1980/11207_1980/tmax.nc

I see: "ORNL DAAC Outage The ORNL DAAC is currently unavailable due to a planned hardware upgrade. We should be back shortly. Please try back later. We apologize for the inconvenience. In the mean time, you may browse our data at earthdata.nasa.gov."

Of course I can't know if this was the problem from the very beginning, but it seems like a good possibility.

Cheers Jacob

bocinsky commented 7 years ago

Seems reasonable! Thanks for letting me know, and I'll have a look in the morning to see if the issue is still occurring.

Best, Kyle

Sent from my mobile; please excuse my brevity.

On Dec 12, 2016, at 20:58, Jacob B. Socolar notifications@github.com wrote:

I may have figured it out... If I point my browser to, for example, http://thredds.daac.ornl.gov/thredds/fileServer/ornldaac/1328/tiles/1980/11207_1980/tmax.nc

I see: "ORNL DAAC Outage The ORNL DAAC is currently unavailable due to a planned hardware upgrade. We should be back shortly. Please try back later. We apologize for the inconvenience. In the mean time, you may browse our data at earthdata.nasa.gov."

Of course I can't know if this was the problem from the very beginning, but it seems like a good possibility.

Cheers Jacob

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

bocinsky commented 7 years ago

Hi Jacob. Looks like THREDDS is still down. I’ll give it one more day, otherwise I’ll look for other options for getting the data (e.g., earthdata.nasa.gov http://earthdata.nasa.gov/).

Cheers, Kyle

On Dec 12, 2016, at 9:08 PM, R. Kyle Bocinsky bocinsky@gmail.com wrote:

Seems reasonable! Thanks for letting me know, and I'll have a look in the morning to see if the issue is still occurring.

Best, Kyle

Sent from my mobile; please excuse my brevity.

On Dec 12, 2016, at 20:58, Jacob B. Socolar <notifications@github.com mailto:notifications@github.com> wrote:

I may have figured it out... If I point my browser to, for example, http://thredds.daac.ornl.gov/thredds/fileServer/ornldaac/1328/tiles/1980/11207_1980/tmax.nc http://thredds.daac.ornl.gov/thredds/fileServer/ornldaac/1328/tiles/1980/11207_1980/tmax.nc I see: "ORNL DAAC Outage The ORNL DAAC is currently unavailable due to a planned hardware upgrade. We should be back shortly. Please try back later. We apologize for the inconvenience. In the mean time, you may browse our data at earthdata.nasa.gov http://earthdata.nasa.gov/."

Of course I can't know if this was the problem from the very beginning, but it seems like a good possibility.

Cheers Jacob

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bocinsky/FedData/issues/27#issuecomment-266634486, or mute the thread https://github.com/notifications/unsubscribe-auth/AH8pM-uihmPtOwbrNK5mnD5xA0IQXqjLks5rHhfKgaJpZM4LLSNS.

jsocolar commented 7 years ago

THREDDS is back up!