[GRASS-dev] i.atcorr produces 'nan' values for certain RapidEye bands

[Florian Detsch]

Dear all,

I am experiencing rather strange behavior when using RapidEye 
top-of-atmosphere (TOA) reflectances as input for i.atcorr. Here, some 
band-specific output solely contains nan values, whereas other 
atmospherically corrected layers look just fine.

For replication purposes, sample RapidEye Ortho Level 3A data. which is 
provided by third parties, is publicly available from GitHub 
(https://github.com/italocegatta/rapidr/tree/master/inst/extdata). 
At-sensor radiances, which show the same strange behavior as TOA 
reflectances, can easily be calculated therefrom through multiplying the 
digital numbers of all five bands by 0.01. The SRTM digital elevation 
model (DEM) and band-specific parameter files, that serve as additional 
input parameters for i.atcorr, are available from Dropbox 
(https://www.dropbox.com/sh/3j1nvveblrrp0z1/AABo5SPww63uX80hacpK4A59a?dl=0). 
Aerosol optical depth and mean elevation specified in the parameter 
files have been taken from MODIS (MOD/MYD08_D3, V006) and SRTM, 
respectively. The remaining parameters are either taken from the 
accompanying metadata file or inherit standard values as specified in 
the GRASS 7.2 i.atcorr manual 
(https://grass.osgeo.org/grass72/manuals/i.atcorr.html).

Now, when I run i.atcorr in GRASS 7.2 (Ubuntu 16.04.2 LTS, 64-bit or 
Windows 10, 64-bit - I have tested both) using the above parameter file, 
the atmospherically corrected image for band 1 looks as expected. The 
resulting image for band 2, on the other hand, contains nan values only. 
By contrast, when processing band 2, but specifying the paramter file 
for band 1 (i.e., band code is 88 rather than 89), the resulting 
atmospherically corrected image looks fine as well. The tool is operated 
using the above SRTM DEM as input elevation map and, since I am dealing 
with TOA reflectances rather than at-sensor radiances, flag "-r" 
enabled. But as said, nan values in band 2 occur for TOA reflectances 
and at-sensor radiances in a similar fashion.

I am quite aware that this is a well-known issue. Similar problems have 
been reported and partly discussed on GRASS-user 
(https://lists.osgeo.org/pipermail/grass-user/2011-May/060992.html), 
GRASS-dev 
(http://osgeo-org.1560.x6.nabble.com/i-atcorr-returns-nan-for-Landsat-5-TM-bands-1-and-2-td5106456.html), 
and they seem to appear outside the official GRASS communications 
channels as well (e.g. 
https://github.com/NikosAlexandris/i.landsat.atcorr). Although some 
older GRASS versions (when run under certain operating systems) or 
manipulating the time of observation in the accompanying parameter file 
seem to increase a chance of success, no consensual solution has been 
found on how to deal with such behavior appropriately.

Any help on this matter would be highly appreciated.

Best,
Florian

-- 
Dr. Florian Detsch
Environmental Informatics
Department of Geography
Philipps-Universität Marburg
Deutschhausstraße 12
35032 (parcel post: 35037) Marburg, Germany

Phone: +49 (0) 6421 28-25323
Web: http://www.uni-marburg.de/fb19/fachgebiete/umweltinformatik/detschf/index.html