Force runGdal to not authenticate the earthData login?

[CCheCastaldo]

I have downloaded some hdf4 files locally and am trying to work with them using MODIS::runGdal. However, despite telling MODISOptions to not check my earthdata login:

MODISoptions(
  localArcPath = path.expand("~/Downloads/MCD19A2_hdf"), 
  outDirPath   = path.expand("~/Downloads/MCD19A2_tiffs"),
  check_earthdata_login = FALSE
)

and also telling runGdal that the files are already downloaded:

MODIS::runGdal(
  product    = "MCD19A2",
  collection = "061",
  tileH      = 23,
  tileV      = 16,
  begin      = "2011012",
  end        = "2011012",
  SDSstring  = SDSstring,
  job        = "MAIAC_AOD_WV",  
  overwrite  = TRUE,
  download   = FALSE,  
  outProj    = "EPSG:3031",
  outFormat  = "GTiff",
  resampling = "near",    
  datum      = NA  
)

runGdal still errors out like this:

########################
outProj          =  +proj=stere +lat_0=-90 +lat_ts=-71 +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs 
pixelSize        =  asIn 
resamplingType   =  near 
Output Directory =  /Users/wintermute/Downloads/MCD19A2_tiffs/MAIAC_AOD_WV 
########################
Error in .local(product, ...) : 
  Earthdata Login credentials could not be verified.
Please run MODISoptions(check_earthdata_login = TRUE) (default) and re-try.

Unfortunately, check_earthdata_login = TRUE always fails now since the API requires a token and not the password and MODIS seems unable to handle that. Is there a way to force runGdal and other MODIS functions not authenticate the earthdata login when working with local files?

[fdetsch]

Thanks for bringing this to my attention! With the recent changes in server-side authentication, I agree the minimum goal should be to maintain a stable, working version of all functions that do not require authentication – including runGdal().

I will need some time to assess what this would entail and determine a sensible path forward. Feel free to keep an eye on the thread for updates!

[CCheCastaldo]

Perhaps the "easiest" thing to do would be to update the authentication bug so it accepts an earthdata token as opposed to user password. Then all your functions that rely on this would continue to work as normal and not need tweaking.

[fdetsch]

Good point. A rewrite would likely involve backward-breaking changes, but given that the package isn’t on CRAN, I don’t see that as a major issue – we have more flexibility there.

That said, I kind of like the idea of tagging or maintaining a "last stable" version that still uses the now-defunct Earthdata login mechanism, just for archival or reference purposes – even if it no longer works due to NASA’s deprecation. From there, we can move forward with a clean slate and implement API key-based authentication without trying to preserve broken functionality.

[fdetsch]

Support for single .hdf files stored locally has been enabled with b0cdc17. Earthdata authentication is skipped in this case. I’ll dig a bit deeper into batch processing of 2+ files.