Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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:  closed
  Priority:  major|   Milestone:  7.0.0 
 Component:  Raster   | Version:  unspecified   
Resolution:  fixed|Keywords:  r.recode, DCELL, CELL, rules, needinfo
  Platform:  Unspecified  | Cpu:  Unspecified   
--+-
Changes (by mlennert):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Works for me as well, so closing.

 Moritz

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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 nikosa):

 Works for me.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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 lucadelu):

 Replying to [comment:15 annakrat]:
 > Replying to [comment:12 annakrat]:
 > > Otherwise this ticket should be solved once r62518 is backported.
 >
 > Backported in r62557.

 Could we close this ticket?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[Paulo van Breugel]

On Sun, Nov 2, 2014 at 10:10 PM, GRASS GIS  wrote:

> #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:13 glynn]:
>  > Replying to [comment:12 annakrat]:
>  >
>  > > 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.
>  >
>  > The advantage of floor() is that it will produce identical results to
>  the existing implementation for positive values.
>  >
>  > The main disadvantage of floor() is that minuscule rounding errors can
>  result in the wrong value, e.g. (CELL)floor(1.999) is 1 rather than 2.
>
>  Thanks for the summary, but I was mainly asking for opinions which one
>  should we use. I prefer rounding to the nearest integer, even though it
>  can give different results. Anyone has the same/different opinion?
>

+1 for rounding to the nearest integer

>
> --
> Ticket URL: 
> GRASS GIS 
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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:12 annakrat]:
 > Otherwise this ticket should be solved once r62518 is backported.

 Backported in r62557.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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:13 glynn]:
 > Replying to [comment:12 annakrat]:
 >
 > > 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.
 >
 > The advantage of floor() is that it will produce identical results to
 the existing implementation for positive values.
 >
 > The main disadvantage of floor() is that minuscule rounding errors can
 result in the wrong value, e.g. (CELL)floor(1.999) is 1 rather than 2.

 Thanks for the summary, but I was mainly asking for opinions which one
 should we use. I prefer rounding to the nearest integer, even though it
 can give different results. Anyone has the same/different opinion?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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 glynn):

 Replying to [comment:12 annakrat]:

 > 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.

 The advantage of floor() is that it will produce identical results to the
 existing implementation for positive values.

 The main disadvantage of floor() is that minuscule rounding errors can
 result in the wrong value, e.g. (CELL)floor(1.999) is 1 rather than 2.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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.

 OK, done in r62518.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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 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).

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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 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.


 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.

 Another issue with a C cast is that if the result is outside the range of
 an integer, the behaviour is undefined. Ideally such values should be
 either converted to null or clamped to the most positive/negative
 representable value.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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 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. The output should be determined by the rules, since it seems as a
 common practice - the numbers giving the type. This does not apply the to
 input map because it already has a type. `r.mapcalc` has the same behavior
 unless you do explicit retype (using `int()` but using number format is
 not explicit retype in my opinion).

 In other words, I consider the current behavior wrong and determining the
 input type from decimal point does not improve the situation. If rules are
 `0:1:0:255` and the input is double, the result will be always 0 for the
 whole map. This is not what I expect. For `0:10:0:255` and input again
 double from 0 to 10, the output will not look completely wrong as in
 previous case which is perhaps even more dangerous because I just don't
 expect the numbers from input map to by trimmed to integers before the
 computation (although I expect the integer on the output).

 I also don't see any case where it would be advantageous to trim the
 numbers before the recoding itself.

 What is your reason for trimming the numbers on input ("to produce
 identical results")?

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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 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.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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 |  
+---
Changes (by annakrat):

  * keywords:  r.recode, DCELL, CELL, rules => r.recode, DCELL, CELL,
   rules, needinfo
  * priority:  normal => major


Comment:

 Any opinion on the suggested change? This is in my view quite serious bug.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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:  normal|   Milestone:  7.0.0 
   
Component:  Raster| Version:  unspecified   
   
 Keywords:  r.recode, DCELL, CELL, rules  |Platform:  Unspecified   
   
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 BTW, using -d (force DCELL) flag I get correct result, however the
 resulting map is DCELL. This flag should affect just the output map type.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#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:  normal|   Milestone:  7.0.0 
   
Component:  Raster| Version:  unspecified   
   
 Keywords:  r.recode, DCELL, CELL, rules  |Platform:  Unspecified   
   
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 I've just run into this problem too. For some reason, r.recode tries to
 guess the input type from the recode rules which seems to be nonsense and
 leads to the errors above. -1.00 is considered as -1 and it reads the
 values from the input map as integers although the map can be DCELL. A
 simple change like this (they might be some more elegant way) seems to do
 what everyone expects:

 {{{
 Index: read_rules.c
 ===
 --- read_rules.c(revision 61256)
 +++ read_rules.c(working copy)
 @@ -50,7 +50,7 @@
  DCELL oLow, oHigh, nLow, nHigh;
  int line, n;

 -in_type = out_type = CELL_TYPE;
 +in_type = Rast_map_type(name, "");

  rules = (char **)G_malloc(INCR * sizeof(char *));
  rule_size = INCR;
 @@ -98,16 +98,12 @@
lookup the values in the quant table */
 switch (sscanf(buf, "%lf:%lf:%lf:%lf", &oLow, &oHigh, &nLow,
 &nHigh)) {
 case 3:
 -   update_type(&in_type, oLow);
 -   update_type(&in_type, oHigh);
 update_type(&out_type, nLow);
 update_rules(buf);
 Rast_fpreclass_add_rule(&rcl_struct, oLow, oHigh, nLow, nLow);
 break;

 case 4:
 -   update_type(&in_type, oLow);
 -   update_type(&in_type, oHigh);
 update_type(&out_type, nLow);
 update_type(&out_type, nHigh);
 update_rules(buf);

 }}}

 It could be even enough if r.recode reads the map values as doubles always
 and takes care just of the output map type.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account (was: r.recode is buggy when minimum "from=0.0")

[GRASS GIS]

#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:  normal|   Milestone:  7.0.0 
   
Component:  Raster| Version:  unspecified   
   
 Keywords:  r.recode, DCELL, CELL, rules  |Platform:  Unspecified   
   
  Cpu:  Unspecified   |  
--+-

Comment(by mlennert):

 I'm having a similar (probably related) issue:

 Given a raster map with a classic normalized difference index ranging
 theoretically from -1 to 1. The exact values are:


 {{{
 > r.univar mymap
 minimum: -0.971429
 maximum: 0.766129
 }}}


 When I recode using the following rules:


 {{{
 -1.0:0:0.0
 0:1.0:1.0
 }}}


 I get


 {{{
 > r.stats -c mybinarymap
 0 5804
 1 9487108
 }}}


 Changing the rules to


 {{{
 -0.99:0.0:0
 0.0:1.0:1
 }}}


 or


 {{{
 -1.0:0.0:0
 0.0:0.99:1
 }}}


 I get


 {{{
 > r.stats -c mybinarymap
 0 5626374
 1 3866538
 }}}

 Moritz

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev