[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