[GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account
GRASS GIS
trac at osgeo.org
Mon Sep 22 00:08:50 PDT 2014
#2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account
----------------------------------------------------+-----------------------
Reporter: nikosa | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 7.0.0
Component: Raster | Version: unspecified
Keywords: r.recode, DCELL, CELL, rules, needinfo | Platform: Unspecified
Cpu: Unspecified |
----------------------------------------------------+-----------------------
Comment(by mlennert):
Replying to [comment:6 wenzeslaus]:
> Replying to [comment:5 glynn]:
> > Replying to [comment:4 annakrat]:
> > > Any opinion on the suggested change? This is in my view quite
serious bug.
> >
> > If it's going to deduce the type from the rules, I suggest checking
for a decimal point prior to parsing rather than checking whether the
parsed value is exactly representable as an integer. IOW, "0.0:1.0:0:255"
will perform a float-int recode while "0:1:0:255" will perform a int-int
conversion.
> >
> > I wouldn't suggest using the input map's type for the input type
unless this will produce identical results.
>
> I think that what is expected to determine the type of input is the
input map.
Glynn, I imagine your suggestion is meant to leave more flexibility ? I
can see a point in that (and thus including an "explicit retype" in
r.recode, to use Václav's words).
However, I also agree with Václav that user expectations would be that if
the input map is floating point, a rule of -1:1:0:255 would take into
account all input values, not only -1, 0, and 1.
So, if we follow Glynn's suggestion, we should at least include a big fat
warning message indicating what the module is doing.
Moritz
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2053#comment:7>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list