[raster] st_dumpaspolygon create int values

[etiennebr]

SELECT ST_AsBinary((ST_DumpAsPolygons(rast)).geom),

(ST_DumpAsPolygons(rast)).val

FROM smallr

Returns grouped values at the integer value. Is it possible to specify to return three digits values ?

Using let'say SELECT ST_Value(rast,10,15) FROM smallr

Returns 32B floats values

[etiennebr]

small 32B rasters from an .asc file (three digits)

[pracine]

How do you plan to do that?

[jorgearevalo]

Working on it. Strange, because the values returned by the dump core function (rt_raster_dump_as_wktpolygons) are in floating point format, but they're truncated before being shown (just before calling PostgreSQL function BuildTupleFromCStrings).

Maybe the decimal part is omitted when is zero (like in the example with smallr table)…

[pracine]

If you read the doc of the GDALPolygonize function:

​http://www.gdal.org/gdal__alg_8h.html#3f522a9035d3512b5d414fb4752671b1

it says: "Note that currently the source pixel band values are read into a signed 32bit integer buffer (Int32), so floating point or complex bands will be implicitly truncated before processing."

I think this makes it impossible for us to get floats back from this function. We could add a parameter saying the number of digits we want and multiply every pixel by 10 exp(this number) but this would inply multiplying every pixel value: way too long.

I think the only way will be to have GDAL to work with float values…

[pracine]

Frank will have a look at this problem during the code sprint. Hopefully we'll have float support!

[jorgearevalo]

Great news!

[pracine]

I filled a ticket in GDAL Trac:

​http://trac.osgeo.org/gdal/ticket/4005

[jorgearevalo]

Fixed in r7308. New GDAL polygonize function implemented in GDAL release 22476 (​http://trac.osgeo.org/gdal/changeset/22476). Please, update your GDAL copy to a release up to 22476 before compiling PostGIS with raster support to make it work.

[pracine]

No change in the API? No way to specify the number of digits?

[dustymugs]

From the looks of it, there is no way to specify a rounding factor.

Personally, I have a different question. By the looks of it, you need GDAL trunk revision 22476 to make use of the functionality and run some of the tests. So, is PostGIS Raster going to set the minimum required version of GDAL raster to whatever point release includes this specific revision?

[jorgearevalo]

No, no changes in the API. You simply get the raster value in a float variable, and this variable is copied in the 'val' field of the rt_geomval structure. Is not that enough?

Bborie: yes, I forgot to modify the configure script. We'll need the next GDAL stable version. We may call GDALPolygonize if GDAL version is lower than the required or the new GDALFPolygonize in case we have the right version of GDAL installed, and warn the user in the first case.

[jorgearevalo]

Now the existence of GDALFPolygonize is checked. r7316

[dustymugs]

Reopened as testing of rt_raster_dump_as_wktpolygons() reveals that the output values are integers rather than floating point even though GDAL is trunk r22922 and postgis config detects GDALFPolygonize. It looks like the GDALFPOLYGONIZE macro isn't being set so that the compilation occurs correctly.

[dustymugs]

Fixed in r7785.