[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
Sat Nov 1 14:08:12 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:10 glynn]:
 > Replying to [comment:9 annakrat]:
 > > 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?
 > Right. Forcing the input type to DCELL would also work.
 > > Floor sounds definitely better. How invasive and difficult would be
 this 're-examining'?
 > It's just a matter of replacing casts such as "(CELL)x" (as well as
 implicit conversions) with "(CELL)floor(x)" (or "(CELL)round(x), or
 "(CELL)floor(x+0.5)" as round() is C99).
 > For fpreclass.c, this applies to Rast_fpreclass_perform_di (L599),
 Rast_fpreclass_perform_fi (L641), and Rast_fpreclass_perform_ii (L683).
 > For put_row.c, this applies to convert_and_write_fi (L636) and
 convert_and_write_di (L652).

 I attached the diff for this, I decided for floor(x+0.5) logic (but we
 could use just floor if someone is against this). I would rather get some
 approval from other developers for this.

 Otherwise this ticket should be solved once r62518 is backported.

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

More information about the grass-dev mailing list