[GRASS-dev] GRASS created geotiff do not properly load into PostGIS (raster2pgsql)

Hi,

And sorry for posting on two lists. Just don`t know where the issue belongs to…

I tried to load a set of raster maps in Geotiff format, which I created in GRASS using r.external.out, into PostGIS 2.1.2dev.

In PostGIS the raster datasets only contain NoData values, while gdalinfo –stats produces reasonable statistics for the respective GeoTiffs.

I did some trouble shooting and found that the problem was that GRASS did not assign a numerical NoData value to the GeoTiff, but “nan”.

When I gdal_translate same GeoTiff with –a_nodata -9999, raster2pgsql loads the resulting file just fine.

Is raster2pgsql supposed to read rasters with nan as NoData values (using –N -9999 in raster2pgsql had no effect btw.) or should GRASS (r.external.out) assign a NoData value to the produced raster datasets?

Many thanks in advance,

Stefan

Hey,

what is your version of gdal (type gdalinfo --version)

Cheers,
Rémi-C

···

2014-05-16 11:14 GMT+02:00 Blumentrath, Stefan <Stefan.Blumentrath@nina.no>:

Hi,

And sorry for posting on two lists. Just don`t know where the issue belongs to…

I tried to load a set of raster maps in Geotiff format, which I created in GRASS using r.external.out, into PostGIS 2.1.2dev.

In PostGIS the raster datasets only contain NoData values, while gdalinfo –stats produces reasonable statistics for the respective GeoTiffs.

I did some trouble shooting and found that the problem was that GRASS did not assign a numerical NoData value to the GeoTiff, but “nan”.

When I gdal_translate same GeoTiff with –a_nodata -9999, raster2pgsql loads the resulting file just fine.

Is raster2pgsql supposed to read rasters with nan as NoData values (using –N -9999 in raster2pgsql had no effect btw.) or should GRASS (r.external.out) assign a NoData value to the produced raster datasets?

Many thanks in advance,

Stefan


grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Hi,

And thanks for the swift response!

My GDAL version is:

GDAL 1.11.0, released 2014/04/16.

I recompiled GDAL recently (but not PostGIS). Can that be the source of error?

However, ASCII and Tiffs with assigned NoData work…

Cheers

Stefan

···

Hey,

what is your version of gdal (type gdalinfo --version)

Cheers,
Rémi-C

2014-05-16 11:14 GMT+02:00 Blumentrath, Stefan <Stefan.Blumentrath@nina.no>:

Hi,

And sorry for posting on two lists. Just don`t know where the issue belongs to…

I tried to load a set of raster maps in Geotiff format, which I created in GRASS using r.external.out, into PostGIS 2.1.2dev.

In PostGIS the raster datasets only contain NoData values, while gdalinfo –stats produces reasonable statistics for the respective GeoTiffs.

I did some trouble shooting and found that the problem was that GRASS did not assign a numerical NoData value to the GeoTiff, but “nan”.

When I gdal_translate same GeoTiff with –a_nodata -9999, raster2pgsql loads the resulting file just fine.

Is raster2pgsql supposed to read rasters with nan as NoData values (using –N -9999 in raster2pgsql had no effect btw.) or should GRASS (r.external.out) assign a NoData value to the produced raster datasets?

Many thanks in advance,

Stefan


grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

OK gdal is out of the way.

Like you I had troubles with the ‘nan’ value ,

because ‘nan’ is actually platform dependent AND it get casted differently depending on the precision of the type.

Like you said the only way to get it working was manually assign a number instead of Nan :frowning:

Cheers,
Rémi-C

···

2014-05-16 11:40 GMT+02:00 Blumentrath, Stefan <Stefan.Blumentrath@nina.no>:

Hi,

And thanks for the swift response!

My GDAL version is:

GDAL 1.11.0, released 2014/04/16.

I recompiled GDAL recently (but not PostGIS). Can that be the source of error?

However, ASCII and Tiffs with assigned NoData work…

Cheers

Stefan

From: Rémi Cura [mailto:remi.cura@gmail.com]
Sent: 16. mai 2014 11:24
To: Blumentrath, Stefan
Cc: GRASS developers list (grass-dev@lists.osgeo.org); postgis-devel@lists.osgeo.org
Subject: Re: [GRASS-dev] GRASS created geotiff do not properly load into PostGIS (raster2pgsql)

Hey,

what is your version of gdal (type gdalinfo --version)

Cheers,
Rémi-C

2014-05-16 11:14 GMT+02:00 Blumentrath, Stefan <Stefan.Blumentrath@nina.no>:

Hi,

And sorry for posting on two lists. Just don`t know where the issue belongs to…

I tried to load a set of raster maps in Geotiff format, which I created in GRASS using r.external.out, into PostGIS 2.1.2dev.

In PostGIS the raster datasets only contain NoData values, while gdalinfo –stats produces reasonable statistics for the respective GeoTiffs.

I did some trouble shooting and found that the problem was that GRASS did not assign a numerical NoData value to the GeoTiff, but “nan”.

When I gdal_translate same GeoTiff with –a_nodata -9999, raster2pgsql loads the resulting file just fine.

Is raster2pgsql supposed to read rasters with nan as NoData values (using –N -9999 in raster2pgsql had no effect btw.) or should GRASS (r.external.out) assign a NoData value to the produced raster datasets?

Many thanks in advance,

Stefan


grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Thanks Rémi,

For clarification. The remaining question is, is this a PostGIS or a GRASS issue?

Since GRASS and GDAL obviously manage to handle the NaN concept, maybe raster2pgsql should be able to do that too?

Cheers

Stefan

···

OK gdal is out of the way.

Like you I had troubles with the ‘nan’ value ,

because ‘nan’ is actually platform dependent AND it get casted differently depending on the precision of the type.

Like you said the only way to get it working was manually assign a number instead of Nan :frowning:

Cheers,
Rémi-C

2014-05-16 11:40 GMT+02:00 Blumentrath, Stefan <Stefan.Blumentrath@nina.no>:

Hi,

And thanks for the swift response!

My GDAL version is:

GDAL 1.11.0, released 2014/04/16.

I recompiled GDAL recently (but not PostGIS). Can that be the source of error?

However, ASCII and Tiffs with assigned NoData work…

Cheers

Stefan

From: Rémi Cura [mailto:remi.cura@gmail.com]
Sent: 16. mai 2014 11:24
To: Blumentrath, Stefan
Cc: GRASS developers list (grass-dev@lists.osgeo.org); postgis-devel@lists.osgeo.org
Subject: Re: [GRASS-dev] GRASS created geotiff do not properly load into PostGIS (raster2pgsql)

Hey,

what is your version of gdal (type gdalinfo --version)

Cheers,
Rémi-C

2014-05-16 11:14 GMT+02:00 Blumentrath, Stefan <Stefan.Blumentrath@nina.no>:

Hi,

And sorry for posting on two lists. Just don`t know where the issue belongs to…

I tried to load a set of raster maps in Geotiff format, which I created in GRASS using r.external.out, into PostGIS 2.1.2dev.

In PostGIS the raster datasets only contain NoData values, while gdalinfo –stats produces reasonable statistics for the respective GeoTiffs.

I did some trouble shooting and found that the problem was that GRASS did not assign a numerical NoData value to the GeoTiff, but “nan”.

When I gdal_translate same GeoTiff with –a_nodata -9999, raster2pgsql loads the resulting file just fine.

Is raster2pgsql supposed to read rasters with nan as NoData values (using –N -9999 in raster2pgsql had no effect btw.) or should GRASS (r.external.out) assign a NoData value to the produced raster datasets?

Many thanks in advance,

Stefan


grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Hi again,

Just to leave a note in case others encounter the same problem and read this thread:

  1. It seems the problem occurs only with rasters in double or floating point precision (a test with integer (Int16) rasters worked fine). However, other integer types may cause problems too: see http://trac.osgeo.org/gdal/browser/trunk/gdal/gcore/gdalrasterband.cpp, where the CPLIsNan function handles NaN explicitly for some data types (see also: http://osgeo-org.1560.x6.nabble.com/gdal-dev-GDALSetRasterNoDataValue-and-NaN-td4996633.html).

  2. GDAL handles NaN without problems, at least on Linux and Windows (I have no Mac for testing).

In any case, I reopened a relevant ticket on this issue which I found in PostGIS trac: http://trac.osgeo.org/postgis/ticket/828

Cheers

Stefan