I’m expericing a problem while trying to export a reclasses (r.reclass) raster map:
I’m getting this error:
Exporting to GDAL data type: Byte
Checking GDAl data type and nodata value
Selected GDAL datatype does not cover data range.
GDAL datatype: Byte, range: 0 - 255
Raster map full_LULC@Regional range: -2.14748e+009 - 20
Raster export results in data loss.
Input raster map contains cells with NULL-value (no-data). The value 255 will be used to represent no-data values in the input map. You can specify a nodata value with the nodata option.
ERROR: Raster export aborted.
But If I try to export my original file (before reclass) It exports just fine.
My reclass file is like this:
190 191 = 1
14 15 16 20 21 22 = 2
11 12 13 = 3
32 40 41 42 50 60 70 90 91 92 100 101 102 = 4
30 31 110 130 131 132 133 134 135 136 = 5
120 140 141 142 143 144 145 = 6
150 151 152 153 = 7
230 = 8
200 201 202 203 = 9
160 161 162 170 180 181 182 183 184 185 186 187 188 = 10
210 = 11
211 245= 20
What might be happening?
Thanks
Monica
On Mon, May 16, 2011 at 3:32 PM, Monica Buescu
<monicabuescu1985@gmail.com> wrote:
I'm expericing a problem while trying to export a reclasses (r.reclass)
raster map:
I'm getting this error:
Exporting to GDAL data type: Byte
Checking GDAl data type and nodata value
Selected GDAL datatype does not cover data range.
GDAL datatype: Byte, range: 0 - 255
Raster map <full_LULC@Regional> range: -2.14748e+009 - 20
Raster export results in data loss.
Input raster map contains cells with NULL-value (no-data). The value 255
will be used to represent no-data values in the input map. You can specify a
nodata value with the nodata option.
ERROR: Raster export aborted.
But If I try to export my original file (before reclass) It exports just
fine.
My reclass file is like this:
190 191 = 1
14 15 16 20 21 22 = 2
11 12 13 = 3
32 40 41 42 50 60 70 90 91 92 100 101 102 = 4
30 31 110 130 131 132 133 134 135 136 = 5
120 140 141 142 143 144 145 = 6
150 151 152 153 = 7
230 = 8
200 201 202 203 = 9
160 161 162 170 180 181 182 183 184 185 186 187 188 = 10
210 = 11
211 245= 20
* = NULL
What might be happening?
The NULL value of the reclass map is not recognized as NULL value, but
instead treated as a valid number.
This seems to be a bug in the GRASS library, specifically in
G_get_null_value_row() and has probably been around since GRASS 6.3.
r.out.gdal can easily be fixed by not using G_get_null_value_row().
I could reproduce it in nc_spm_08 with landclass96
echo "1 2 3 = 1
5 6 = 2
* = NULL" >reclass.rcl
r.reclass in=landclass96 out=my_landclass96 rules=reclass.rcl
# my_landclass96 is now a reclassified map of a reclassified map
r.out.gdal in=my_landclass96 out=my_landclass96.tif
Markus Metz wrote:
The NULL value of the reclass map is not recognized as NULL value, but
instead treated as a valid number.
This seems to be a bug in the GRASS library, specifically in
G_get_null_value_row() and has probably been around since GRASS 6.3.
AFAICT, it has been around as long as G_get_null_value_row() has
existed. G_get_null_value_row() returns the raw data, without any
reclass applied.
As it stands, this function probably isn't of much use. If it is to be
retained in its current form, it should have _no_reclass appended to
the name. The existing name should be used for a function which
honours any reclass table (done in 7.0 with r46323).
r.out.gdal can easily be fixed by not using G_get_null_value_row().
In 7.0, it's also used by r.neighbors and the OGSF library.
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, May 17, 2011 at 3:09 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Metz wrote:
The NULL value of the reclass map is not recognized as NULL value, but
instead treated as a valid number.
This seems to be a bug in the GRASS library, specifically in
G_get_null_value_row() and has probably been around since GRASS 6.3.
AFAICT, it has been around as long as G_get_null_value_row() has
existed. G_get_null_value_row() returns the raw data, without any
reclass applied.
As it stands, this function probably isn't of much use.
Remove?
r.out.gdal can easily be fixed by not using G_get_null_value_row().
Fixed in r46324, r46325, r46326 (7.0, 6.5, 6.4.2, respectively).
Markus M
Markus Metz wrote:
>> The NULL value of the reclass map is not recognized as NULL value, but
>> instead treated as a valid number.
>>
>> This seems to be a bug in the GRASS library, specifically in
>> G_get_null_value_row() and has probably been around since GRASS 6.3.
>
> AFAICT, it has been around as long as G_get_null_value_row() has
> existed. G_get_null_value_row() returns the raw data, without any
> reclass applied.
>
> As it stands, this function probably isn't of much use.
Remove?
No, fix (as per r46323).
If you only care about whether a cell is null or non-null, reading and
decoding the actual data is needless overhead.
If you need to read the data anyhow, then use that rather than reading
the null data a second time (the raw data is cached, but conversion
and masking will be re-done).
r.out.gdal was the latter case, so it shouldn't have been using that
function. OGSF is also the latter case, and should be fixed.
r.neighbors is the former case (it's used for the the selection=
parameter), so it should be using Rast_get_null_value_row(). There may
be other modules which should be doing this but are actually reading
the data.
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, May 18, 2011 at 10:29 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Metz wrote:
>> The NULL value of the reclass map is not recognized as NULL value, but
>> instead treated as a valid number.
>>
>> This seems to be a bug in the GRASS library, specifically in
>> G_get_null_value_row() and has probably been around since GRASS 6.3.
>
> AFAICT, it has been around as long as G_get_null_value_row() has
> existed. G_get_null_value_row() returns the raw data, without any
> reclass applied.
>
> As it stands, this function probably isn't of much use.
Remove?
No, fix (as per r46323).
Done in r46345, r46346.
If you only care about whether a cell is null or non-null, reading and
decoding the actual data is needless overhead.
If you need to read the data anyhow, then use that rather than reading
the null data a second time (the raw data is cached, but conversion
and masking will be re-done).
r.out.gdal was the latter case, so it shouldn't have been using that
function. OGSF is also the latter case, and should be fixed.
OGSF fixed in r46347 for trunk. This is an enhancement, no bug because
[Rast|G]_get_null_value_row is fixed, so the OGSF change does not need
to be backported.
Markus M