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

[Markus Metz]

On Tue, Jan 16, 2018 at 8:32 AM, Markus Neteler <neteler at osgeo.org> wrote:
>
> On Fri, Jan 12, 2018 at 10:42 AM, Markus Metz
> <markus.metz.giswork at gmail.com> wrote:
> > On Fri, Jan 12, 2018 at 8:58 AM, Markus Neteler <neteler at osgeo.org>
wrote:
> ...
> > 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 missing values.
>
> This is the source which was used:
> https://resa.planet.com/files/2014-06/Spectral_Response_Curves.pdf
>
> Maybe something went wrong?

I don't think so, there are just a lot of small values that can be ignored.

>
> markusN
>
> > In short, there are too many too small values in the rapideye filter
> > functions, causing numerical instability. This could be fixed upon
> > initialization.

This is fixed upon initialization in trunk r72072.

The results are still slightly different on different OS's (Debian,
Fedora), but fairly similar and now there are non-NULL results.

Markus M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180116/ecfe7df2/attachment.html>