[GRASS-dev] i.atcorr produces 'nan' values for certain RapidEye bands
markus.metz.giswork at gmail.com
Fri Jan 12 01:42:02 PST 2018
On Fri, Jan 12, 2018 at 8:58 AM, Markus Neteler <neteler at osgeo.org> wrote:
> Hi Florian,
> On Tue, May 23, 2017 at 11:45 AM, Florian Detsch
> <florian.detsch at staff.uni-marburg.de> wrote:
> > Hi Markus,
> > Thanks for your suggestion. I've installed the latest version of "trunk"
> > (code revision r71101, build date 2017-05-22). However, while at least
> > of the two bands that I included in my initial example seemed to work at
> > that time using GRASS's release version, now with "trunk" both bands
> > 'no data' values only after running i.atcorr.
> Recently Markus Metz has identified internal precision problems in
> i.atcorr on certain systems which have been addressed in GRASS GIS
> 7.4.0RC2. Perhaps some more improvements are needed but probably also
> your problem is already solved.
> Please consider to update to GRASS GIS 7.4.0RC2 (the final 7.4.0 will
> be out soon, your feedback would be interesting before that release).
The spectral filter functions for RapidEye in i.atcorr are strange. E.g.
band 2 (green) is supposed to cover the range 520 - 590 nm, but in
iwave.cpp this band covers the range 424 - 876 nm. Further on, the file
rapideye.csv and the values in IWave::rapideye() do not match, a lot of
0.001 values have been inserted where there should be zero. In
rapideye.csv, there are gaps in filter functions, e.g. for green from 598
to 763 nm, then again from 773 to 876 nm. In the range 424 - 508 nm, there
are also a few small blocks with values > 0 separated by large blocks of
In short, there are too many too small values in the rapideye filter
functions, causing numerical instability. This could be fixed upon
> grass-dev mailing list
> grass-dev at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the grass-dev