[GRASS-dev] Re: [GRASS-user] low radiance values after i.atcor and i.topo.corr

[Glynn Clements]

Markus Neteler wrote:

> >> > Thanks!  Multiplying by 1000 with r.mapcalc gives better results.  Any
> >> > chance adding floating points (FCELL) to i.cluster?
> >>
> >> I had a brief look at the code[1], and cannot see any obvious reason
> >> why the values would need to be integers, so I'm assuming that it's
> >> just a legacy of the days before FP support was added.
> >>
> >> [1] Most of the code is actually in the lib/imagery/c_*.c files. That
> >> should either be made part of i.cluster (nothing else uses it), or at
> >> least split into a separate library.
> >
> > I have committed these changes (splitting the cluster code off to a
> > separate library, and changing it to use DCELL instead of CELL) to the
> > SVN trunk.
> >
> > I would appreciate it if someone who understands i.cluster could test
> > the current version.
> 
> (I have backported the changes to 6.4.svn for easier testing for me).
> 
> The i.cluster continues to work for CELL maps.
> 
> Here a test with the NC data set for FP maps:

> Maybe my example is nonsense?

Well, I don't actually understand what i.cluster does, so I couldn't
tell "sensible" output from garbage.

However:

1. The behaviour for integer maps should remain unchanged.
2. Simply converting an integer map to FP shouldn't affect the
results.

If the above aren't true, then I've introduced a bug somewhere.

Beyond that, is i.cluster linear? IOW, if you scale all inputs by a
constant factor, should you get "equivalent" results?

If so, then the new i.cluster should behave as expected while the old
one would produce bogus results if the values are scaled down such
that the error introduced by rounding becomes significant.

-- 
Glynn Clements <glynn at gclements.plus.com>