[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
Wed Oct 29 18:40:27 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 annakrat):

 Replying to [comment:8 glynn]:
 > Replying to [comment:5 glynn]:
 >
 > > I wouldn't suggest using the input map's type for the input type
 unless this will produce identical results.
 >
 > From examining lib/raster/fpreclass.c, it appears that they will produce
 identical results (int and float values are simply converted to double),
 so this is a non-issue.
 >

 So, if we decide to go with a simple fix, using input map type (as
 suggested in the code snippet above) would be a solution, right?
 >
 > However, this might be a good time to re-examine how floating-point
 values are converted to integers both in fpreclass.c and put_row.c.
 >
 > Both cases simply use a C cast, which is defined as discarding the
 fractional part, i.e. rounding toward zero (inwards). The GRASS
 quantisation functions are only used when reading floating-point maps as
 integer, not when writing.
 >
 > This is one of the least useful rounding modes, due to its anti-
 symmetric behaviour (i.e. positive numbers are rounded down, negative
 numbers are rounded up). Rounding to nearest integer or rounding toward
 negative infinity (i.e. floor()) are usually preferred.

 Floor sounds definitely better. How invasive and difficult would be this
 're-examining'?

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2053#comment:9>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list