r.recode results in integer when floating numbers are expected [Bug]

[ecodiv]

Describe the bug

I have a map with data type Float, with values between 0 and 18.7. I use r.recode to rescale the layer to values between 0 and 1 using the steps below. I expect the output to be a float raster. But it is converted to an integer map instead.

To reproduce

1. Take a raster of data type Float
2. Run the following (replace the old min and max for min and max value of your input raster layer).

echo "0.0:18.7:0.0:1.0" | r.recode input=myinput output=myoutput rules=-

4. Check data type

r.info -g myoutput

The resulting output layer is an integer raster.

Expected behavior

I would expect the output layer to be a float raster. Using the -d flag will force the output layer to be of type DCELL.

System description

• Operating System: Linux, Ubuntu 22.04
• GRASS GIS version: 8.3.2

[dhdeangelis]

You need to add the -d flag to your command to achieve your expected results:

-d Force output to 'double' raster map type (DCELL)

Try:

echo "0.0:18.7:0.0:1.0" | r.recode -d input=myinput output=myoutput rules=-

[ecodiv]

You need to add the -d flag to your command to achieve your expected results:

-d Force output to 'double' raster map type (DCELL)

Try:

echo "0.0:18.7:0.0:1.0" | r.recode -d input=myinput output=myoutput rules=-

Thanks. I know you can use the -d flag (and I wrote that in the bug report), but the point I was trying to make is that based on the manual, I would not necessarily expect r.recode to convert the floating map to an integer map, as I used decimal numbers for the new minimum and maximum value. I think that either the behavior should be changed, or the behavior (when does the function change the data type) should be explained more explicitly.

[dhdeangelis]

I know you can use the -d flag (and I wrote that in the bug report)

I see, I missed that.

based on the manual, I would not necessarily expect r.recode to convert the floating map to an integer map, as I used decimal numbers for the new minimum and maximum value. I think that either the behavior should be changed, or the behavior (when does the function change the data type) should be explained more explicitly.

I agree with this. I also find the manual confusing on this regard. The manual first states that r.recode is for recoding categorical maps, which it seems to be made for, but then gives an example of rescaling, for which r.mapcalc is more convenient.

[ninsbl]

This seems like a bug to me.

r.recode appears to be intended to produce FCELL results too. See e.g.: https://github.com/OSGeo/grass/blob/25961a86c26765f293d582900b00bb37403a780d/raster/r.recode/read_rules.c#L143C25-L143C29

[dhdeangelis]

It seems that the problem lies in parsing or managing the input, as numbers ending in zero are not interpreted as float.

Example:
echo "0.0:18.7:0.0:1.0" | r.recode input=r output=test rules=- --overwrite
produces a raster of type CELL
while
echo "0.0:18.7:0.01:1.0" | r.recode input=r output=test rules=- --overwrite
or
echo "0.0:18.7:0.0:1.01" | r.recode input=r output=test rules=- --overwrite
produce rasters of type FCELL

Edit: deleted reference to rules, as I could not trace the exact source of the problem.

[dhdeangelis]

It seems to me that this part in read_rules.c is not working as intended:

grass/raster/r.recode/read_rules.c

Lines 136 to 146 in f4d8c62

	int update_type(RASTER_MAP_TYPE *map_type, DCELL val)
	{
	/* check if val is not an integer number */
	if (make_dcell)
	*map_type = DCELL_TYPE;
	else {
	if ((DCELL)((CELL)val) != val)
	*map_type = FCELL_TYPE;
	}
	return 0;
	}

Perhaps line 142 could be replaced with a call to a function to tell if val is a float or integer. . I am not so fluent in C but it seems that is not so straightforward.

A simple work around could be to default output to integer, unless it is forced to double using the -d switch, or to float using a new switch, for example: -f. This I just tested and works. But it is perhaps not the expected behaviour? Also it adds a new switch and may break backwards compatibility.