Re: [GRASS-user] [GRASS-dev] Using r.quantile result with r.recode
Hi Glynn, Unless I missed it, this does not seem to be mentioned explicitly in the r.recode help file. Would it be an idea to add this? Paulo On Tue, Apr 16, 2013 at 9:50 PM, Glynn Clements gl...@gclements.plus.comwrote: [CC to grass-dev for discussion] Pedro Venâncio wrote: Thank you very much for your answer! My question lies precisely in the need to know if a quantile value which falls as the upper limit for one range and the lower limit of the next, should belong to the class anterior or posterior. For example, assuming that r.quantile (with -r flag) gives this result: 2:6:1 6:8:2 8:12:3 12:20:4 20:873:5 the value 6 should belong to the first class or second? r.recode will treat boundary values as belonging to the upper range, e.g. in the above example, 6.0 will get recoded to 2. This behaviour stems from Rast_fpreclass_get_cell_value() in lib/raster/fpreclass.c, and isn't configurable (i.e. there's no way that r.recode's behaviour could be modified without modifying the fpreclass functions). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [GRASS-dev] Using r.quantile result with r.recode
Paulo van Breugel wrote: r.recode will treat boundary values as belonging to the upper range, e.g. in the above example, 6.0 will get recoded to 2. This behaviour stems from Rast_fpreclass_get_cell_value() in lib/raster/fpreclass.c, and isn't configurable (i.e. there's no way that r.recode's behaviour could be modified without modifying the fpreclass functions). Unless I missed it, this does not seem to be mentioned explicitly in the r.recode help file. Would it be an idea to add this? Actually, it's more accurate to say that r.recode uses the last range specified (which isn't necessarily the upper range). More generally, r.recode doesn't care if ranges overlap. It just stores the rules in the order they are given, and performs a lookup by iterating over the rules from last to first until it finds a match. The fpreclass code has a function to reverse the order of rules, but nothing uses it. Apart from the lack of clarity regarding boundary values, the existing method is inefficient if the number of rules is large; a binary search tree (or similar) would be better. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
