[GRASS-user] cannot write raster w/ max = inf

Dear GRASS list,

I have a GeoTIFF that I can read in to a raster. ~r.info~ reports "max = inf". If I try to write it out as a raster with ~r.out.gdal~ I get an error (below) and the file is not saved to disk. I can't figure out how to replace "inf" values with ~r.mapcalc~. Can someone suggest how to work with this data?

Thanks,

  -k.

Checking GDAL data type and nodata value...
100%
WARNING: Selected GDAL datatype does not cover data range.
WARNING: GDAL datatype: Float32, range: -3.4e+38 - 3.4e+38
WARNING: Raster map <foo> range: 0.393347 - inf
WARNING: Raster export results in data loss.
Using GDAL data type <Float32>
Input raster map contains cells with NULL-value (no-data). The value nan
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.

Hi Ken,

On Sat, Nov 11, 2017 at 12:25 AM, Ken Mankoff <mankoff@gmail.com> wrote:

Dear GRASS list,

I have a GeoTIFF that I can read in to a raster.

Can you please post the output of

gdalinfo -mm your_raster_map
?

~r.info~ reports "max = inf".

Sounds like "unusual"...

If I try to write it out as a raster with ~r.out.gdal~ I get an error (below)

That is likely a error due to above problem.

Markus

and the file is not saved to disk. I can't figure out how
to replace "inf" values with ~r.mapcalc~. Can someone suggest how to work with this data?

Thanks,

  -k.

Checking GDAL data type and nodata value...
100%
WARNING: Selected GDAL datatype does not cover data range.
WARNING: GDAL datatype: Float32, range: -3.4e+38 - 3.4e+38
WARNING: Raster map <foo> range: 0.393347 - inf
WARNING: Raster export results in data loss.
Using GDAL data type <Float32>
Input raster map contains cells with NULL-value (no-data). The value nan
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.
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

On Sat, Nov 11, 2017 at 12:25 AM, Ken Mankoff <mankoff@gmail.com> wrote:

Dear GRASS list,

I have a GeoTIFF that I can read in to a raster. ~r.info~ reports “max = inf”. If I try to write it out as a raster with ~r.out.gdal~ I get an error (below) and the file is not saved to disk. I can’t figure out how to replace “inf” values with ~r.mapcalc~. Can someone suggest how to work with this data?

Thanks,

-k.

Checking GDAL data type and nodata value…
100%
WARNING: Selected GDAL datatype does not cover data range.

Did you specify type=Float32? If yes, try to use type=Float64. You can also use the -f flag to force raster export.

Markus M

WARNING: GDAL datatype: Float32, range: -3.4e+38 - 3.4e+38
WARNING: Raster map range: 0.393347 - inf
WARNING: Raster export results in data loss.
Using GDAL data type
Input raster map contains cells with NULL-value (no-data). The value nan
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.


grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

On 2017-11-11 at 00:24, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Nov 11, 2017 at 12:25 AM, Ken Mankoff <mankoff@gmail.com> wrote:
Did you specify type=Float32? If yes, try to use type=Float64. You can
also use the -f flag to force raster export.

-f doesn't solve this. Exact same error except the valid data range has changed:

WARNING: GDAL datatype: Float64, range: -1.79e+308 - 1.79e+308

  -k.

On 2017-11-10 at 23:37, Markus Neteler <neteler@osgeo.org> wrote:

gdalinfo -mm your_raster_map

I can post the full output, but I assume the part you are interested is the diff between the normal and the '-mm' option, which is:

    Computed Min/Max=0.380,inf

Which are the values reported by ~r.info~.

It may be a bug with the upstream producer. If inf is invalid, I can let them know. I have not seen mention of inf anywhere online (searching GeoTIFF, GDAL, or GRASS), but it makes it hard to search because INF is a file format.

  -k.

On Sat, Nov 11, 2017 at 7:24 AM, Ken Mankoff <mankoff@gmail.com> wrote:

On 2017-11-10 at 23:37, Markus Neteler <neteler@osgeo.org> wrote:

gdalinfo -mm your_raster_map

I can post the full output, but I assume the part you are interested is the diff between the normal and the ‘-mm’ option, which is:

Computed Min/Max=0.380,inf

Which are the values reported by ~r.info~.

It may be a bug with the upstream producer. If inf is invalid, I can let them know.

inf is a perfectly valid number, meaning infinity. Unfortunately, a test for inf is only available with C standard 99, and I don’t know of a manual test in C for inf (or -inf) to avoid C 99. The bug is in r.out.gdal, not testing for input inf values.

Markus M

I have not seen mention of inf anywhere online (searching GeoTIFF, GDAL, or GRASS), but it makes it hard to search because INF is a file format.

-k.


grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

inf is a perfectly valid number, meaning infinity. Unfortunately, a test

for inf is only available with C standard 99, and I don’t know of a manual

test in C for inf (or -inf) to avoid C 99. The bug is in r.out.gdal, not

testing for input inf values.

You could use the CPLIsInf() macro from GDAL’s cpl_port.h . It uses different implementations depending on the platform.

Spatialys - Geospatial professional services

http://www.spatialys.com

On Sat, Nov 11, 2017 at 11:14 AM, Even Rouault <even.rouault@spatialys.com> wrote:

inf is a perfectly valid number, meaning infinity. Unfortunately, a test

for inf is only available with C standard 99, and I don’t know of a manual

test in C for inf (or -inf) to avoid C 99. The bug is in r.out.gdal, not

testing for input inf values.

You could use the CPLIsInf() macro from GDAL’s cpl_port.h . It uses different implementations depending on the platform.

Nice! Thanks for the hint, using it now to test for inf during export.

inf values are now exported with r.out.gdal in trunk and relbr72 (r71665,6).

Markus M

Spatialys - Geospatial professional services

http://www.spatialys.com

On 2017-11-11 at 11:49, Markus Metz <markus.metz.giswork@gmail.com> wrote:

inf values are now exported with r.out.gdal in trunk and relbr72
(r71665,6).

Great news. Thanks for fixing this bug. Is there any way to process/detect these numbers in r.mapcalc until the bugfix makes its way into a packaged distribution?

Thanks,

  -k.

On Sat, Nov 11, 2017 at 2:32 PM, Ken Mankoff <mankoff@gmail.com> wrote:

On 2017-11-11 at 11:49, Markus Metz <markus.metz.giswork@gmail.com> wrote:

inf values are now exported with r.out.gdal in trunk and relbr72
(r71665,6).

Great news. Thanks for fixing this bug. Is there any way to process/detect these numbers in r.mapcalc until the bugfix makes its way into a packaged distribution?

It seems that r.mapcalc treats inf as nan (NULL cells), so r.mapcalc probably does not help.

Markus M

Thanks,

-k.

Hi,

On 2017-11-11 at 15:01, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Sat, Nov 11, 2017 at 2:32 PM, Ken Mankoff <mankoff@gmail.com> wrote:
Is there any way to process/detect these numbers in r.mapcalc until
the bugfix makes its way into a packaged distribution?

It seems that r.mapcalc treats inf as nan (NULL cells), so r.mapcalc
probably does not help.

I figured out a solution: r.null map=foo setnull=inf

  -k.