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

[Markus Neteler]

On Sat, Jun 21, 2008 at 1:47 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> 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.

It does something like this:
http://en.wikipedia.org/wiki/Cluster_analysis

> However:
>
> 1. The behaviour for integer maps should remain unchanged.

Confirmed.

> 2. Simply converting an integer map to FP shouldn't affect the
> results.

I suppose so.

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

No bug in the upper part. No bug at all, but missing feature (see below).

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

Indeed: results are simply divided by 10000. in this case.
Since the precision doesn't suffice, it fails as all gets 0.00000x.

First class of integer map:
#produced by i.cluster
#Class 1
235
68.897872 50.136170 41.085106 18.565957 17.463830 14.174468 25.851064
9.425423
10.432770 18.562575
14.645481 23.813148 37.283324
8.686252 12.072177 21.374704 45.503110
11.581760 12.654519 23.242408 48.065430 74.796763
9.086270 8.638534 15.972268 27.007674 44.474286 32.136097
8.065921 9.900709 18.880251 28.033370 33.176214 19.970540 55.734133

First class of FP map (integer map divided by 10000. as in my example):
#produced by i.cluster
#Class 1
235
0.006890 0.005014 0.004109 0.001857 0.001746 0.001417 0.002585
0.000000
0.000000 0.000000
0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000 0.000001
0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000001

What's needed since we cannot change the format is a normalization
related to the range (AFAIK in i.cluster/print2.c).

Markus