search

fdetsch / MODIS

Download and processing framework for MODIS imagery. The package provides automated access to the global online data archives LP DAAC, LAADS and NSIDC as well as processing capabilities such as file conversion, mosaicking, subsetting and time series.
Other
58 stars 27 forks source link

fix issue with gdal-warp #96

Closed mlampros closed 4 years ago

mlampros commented 4 years ago

First of all thanks for making this repository publicly available. This pull request fixes issues #93 and #92 The following is a reproducible example on Linux Mint 18.2


sp_path = ebirdst::ebirdst_download("example_data")
abd = ebirdst::load_raster(product = "abundance", sp_path)

mod_date = MODIS::transDate(begin = as.Date('2018-02-01'),
                            end = as.Date('2018-02-02'))

mod_tile = MODIS::getTile(x = abd)

tifs = MODIS::runGdal(product = "MODOCGA",
                      begin = mod_date$beginDOY,
                      end = mod_date$endDOY,
                      tileH = mod_tile@tileH,
                      tileV = mod_tile@tileV,
                      extent = mod_tile, 
                      job = "modis")

By running the previous code I received,


Error in sf::gdal_utils(util = "warp", source = gdalSDS, destination = ofile,  : 
  gdal_utils warp: an error occured

The error also revealed,


Output driver `79' not recognised or does not support

The output files in the temporary directory were all of type ".tif" (GTIFF driver).

The runGdal() function calls internally the sf::gdal_utils() function which takes params as input which normally should be a vector of parameters such as,


'-of'  'GTIFF'   etc.

however it actually is


'-of'  '79'   etc.

In the 'runGdal()' function the 'GTIFF' driver is assigned to the dataFormat variable which equals to


dataFormat = checkGdalWriteDriver(dataFormat)

The checkGdalWriteDriver() function calls internally the getGdalWriteDrivers() function which in my case returns,


'data.frame':   45 obs. of  7 variables:
 $ name     : Factor w/ 210 levels "AAIGrid","ACE2",..: 197 79 129 87 46 117 15 147 148 92 ...
 $ long_name: Factor w/ 209 levels "ACE2","Aeronav FAA",..: 201 68 126 43 36 95 121 152 153 93 ...
 $ write    : logi  TRUE TRUE TRUE TRUE TRUE TRUE ...
 $ copy     : logi  TRUE TRUE TRUE TRUE FALSE FALSE ...
 $ is_raster: logi  TRUE TRUE TRUE TRUE TRUE TRUE ...
 $ is_vector: logi  FALSE FALSE FALSE FALSE FALSE FALSE ...
 $ vsi      : logi  TRUE TRUE TRUE TRUE TRUE FALSE ...

Therefore the nms variable,


nms = getGdalWriteDrivers()$name

is of type factor and rather than returning the driver as a character string (i.e. 'GTIFF') it returns the level position,


 Factor w/ 210 levels "AAIGrid","ACE2",..: 197 79 129 87 46 117 15 147 148 92 ...

In this PR I converted the nms variable to a character string as the 'checkGdalWriteDriver()' function is called only once in the MODIS R package.

fdetsch commented 4 years ago

Marvellous, thanks for the PR. I'll merge into 'develop' and check back with those guys that encountered problems.

Out of interest, are you running R >= 4.0.0? I just want to rule out that this is related to recent changes in the default behavior of stringsAsFactors.

mlampros commented 4 years ago

Hi, I run the code of this PR in R version 3.6.3. Yes, you are right, a user having 4.0.0 installed will highly probable won't encounter this error as the default behaviour has changed to 


stringsAsFactors = FALSE
fdetsch commented 4 years ago

Right. Still, a highly valuable PR - I didn't realize this was related to format changes in sf::st_drivers() for different versions of R. Otherwise, I would have had to add R (>= 4.0.0) to Depends, which I figure isn't particularly desirable.