On Thu, Apr 10, 2014 at 8:56 PM, Glynn Clements <[email protected]> wrote: > > Markus Neteler wrote: > >> in r59668 and r59669 I have fixed the issue that a map type >> (CELL/FCELL/DCELL) was not preserved as expected but always converted >> to DCELL. >> >> Now CELL is generated for >> >> {c_count, w_count, NO_CATS, 0, 0, 1, "count", "count of non-NULL >> values"}, >> {c_divr, NULL, divr_cats, 0, 0, 1, "diversity", >> {c_intr, NULL, intr_cats, 0, 0, 1, "interspersion", > > Note that this change is incorrect for method=count when used with > weight=, as the result is the sum of the weights, which isn't > necessarily an integer. > > Fixed in trunk in r59677.
Thanks, >> Remaining issues: >> >> 1) "quantile=0.5" creeps into the history: >> >> r.info landuse96_28m_mode7x7 >> ... >> | r.neighbors input="landuse96_28m" output="landuse96_28m_mode7x7" met\ >> | >> | hod="mode" size=3 quantile=0.5 >> >> --> quantile=0.5 should not be there (even if ignored). > > Remove the line: > > parm.quantile->answer = "0.5"; > > Optionally change: > > out->quantile = (parm.quantile->answer && parm.quantile->answers[i]) > ? atof(parm.quantile->answers[i]) > : 0; > > to default to 0.5 rather than 0. > > But given that we already a distinct "median" method, using > "quantile=0.5" is largely redundant. ... mmh, not sure what to change. >> 2) The method=mode does not preserve CELL (likewise in r.series). >> >> Any suggestion how to fix these two remaining problems? > > You could just set is_int=1 (although that would make r59677 > incorrect, as the weighted mode calulation does return an integer > result for integer values). > > Using method=mode isn't particularly meaningful on floating-point > data, as the result is an artifact of the quantisation of the original > data. If measurement was perfectly accurate, every value should be > unique. This is largely why r.stats.zonal (formerly r.statistics2) > doesn't have method=mode. > > Alternatively, replace the boolean is_int field with either a pointer > to a function which returns the result type based upon the input type > and whether weights are being used, or an enumeration (which would > either select such a function, or an equivalent block of code within a > switch statement). This is a bit over my programming skills. But the broken "mode" operator is a critical issue. Help (=svn commits) welcome, thanks Markus _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
