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