[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