Feeding the test values and the evi(2) formula to r.mapcalc, the results are more or less in the expected range, still beyond [-1, 1], but not much. Obviously, there is a bug in i.vi. Furthermore, i.vi is slower than r.mapcalc. I recommend to replace the C module i.vi with a i.vi script that calls r.mapcalc.
Markus M On Sun, Jun 16, 2013 at 8:13 PM, Nikos Alexandris <n...@nikosalexandris.net> wrote: > Nikos Alexandris wrote: >> > > I get an unexpected range of evi values using "i.vi" (G7), i.e. > > [..] > >> > > # range is... >> > > r.info -r evi > >> > > min=-6912.82161611806 >> > > max=2264.42037461018 > > [..] > >> Looking for these pixels, e.g. >> >> r.stats evi_ToAR -g | grep '\-5905' >> >> 784935 2695215 -5905.4417191748 >> 786465 2694675 -5905.4417191748 >> 766185 2685615 -5905.4417191748 >> >> and >> >> r.stats evi_ToAR -g | grep '6952\.' >> >> 783435 2690025 6952.8054373157 > > > >> Then tracing the values that produced this out-of-range value, >> >> r.what coordinates=784935,2695215 >> map=B.Trimmed.ToAR.1,B.Trimmed.ToAR.3,B.Trimmed.ToAR.4,evi_DN,evi_ToAR >> >> 784935|2695215||0.230260364323039|0.110923862670943|0.0614305088322746| >> 0.35181236673774|-5905.44171917482 >> >> and >> >> r.what coordinates=783435,2690025 >> map=B.Trimmed.ToAR.1,B.Trimmed.ToAR.3,B.Trimmed.ToAR.4,evi_DN,evi_ToAR >> >> 783435|2690025||0.228143006540123|0.106632395012542|0.0712654621906476| >> 0.296610169491526|6952.80543731566 > > > > A bit more clear perhaps: > > # res=30 > g.region -pagc rast=B.Trimmed.ToAR.1 res=30 > > n=2815500 > s=2621340 > w=658560 > e=875880 > nsres=30 > ewres=30 > rows=6472 > cols=7244 > cells=46883168 > center_easting=767220.000000 > center_northing=2718420.000000 > > # what is there? > r.what coordinates=784935,2695215 > map=B.Trimmed.ToAR.1,B.Trimmed.ToAR.3,B.Trimmed.ToAR.4,evi_DN,evi_ToAR > > 784935|2695215||0.230260364323039|0.110923862670943|0.0614305088322746| > 0.35181236673774|-5905.44171917482 > > # while res=1... > g.region -pagc rast=B.Trimmed.ToAR.1 res=1 > > n=2815500 > s=2621340 > w=658560 > e=875880 > nsres=1 > ewres=1 > rows=194160 > cols=217320 > cells=42194851200 > center_easting=767220.000000 > center_northing=2718420.000000 > > # ...gives > r.what coordinates=784935,2695215 > map=B.Trimmed.ToAR.1,B.Trimmed.ToAR.3,B.Trimmed.ToAR.4,evi_DN,evi_ToAR > > 784935|2695215||0.230260364323039|0.110923862670943|0.0614305088322746| > 0.35181236673774|-5905.44171917482 > > > > Now, "pointing" to the suspect pixel: > > # both res=30 & res=1 give the same result, of course > g.region -pagc e=784935 n=2695215 rows=1 cols=1 res=30 > > n=2695230 > s=2621340 > w=658560 > e=784950 > nsres=73890 > ewres=126390 > rows=1 > cols=1 > cells=1 > center_easting=721755.000000 > center_northing=2658285.000000 > > # what is there? > r.what coordinates=784935,2695215 > map=B.Trimmed.ToAR.1,B.Trimmed.ToAR.3,B.Trimmed.ToAR.4,evi_DN,evi_ToAR > > 784935|2695215||0.264138088849702|0.372703389833447| > 0.438437054236573|-0.203045685279188|0.0970312073830427 > > [..] > > I guess it has to do with the extent/res definitions... > > Thanks, Nikos > _______________________________________________ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev