Opened 6 years ago

Closed 6 years ago

#650 closed defect (fixed)

[raster] st_dumpaspolygon create int values

Reported by: etiennebr Owned by: jorgearevalo
Priority: blocker Milestone: PostGIS 2.0.0
Component: raster Version: trunk
Keywords: Cc:

Description

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

Attachments (1)

smallr.sql (6.3 KB) - added by etiennebr 6 years ago.
small 32B rasters from an .asc file (three digits)

Download all attachments as: .zip

Change History (20)

Changed 6 years ago by etiennebr

Attachment: smallr.sql added

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

comment:1 Changed 6 years ago by pracine

Summary: st_dumpaspolygon create int values[raster] st_dumpaspolygon create int values

comment:2 Changed 6 years ago by pracine

Milestone: PostGIS 1.5.3PostGIS 2.0.0
Version: 1.5.Xtrunk

comment:3 Changed 6 years ago by pracine

Priority: mediumcritical

comment:4 Changed 6 years ago by pracine

Owner: changed from pracine to jorgearevalo

comment:5 Changed 6 years ago by jorgearevalo

Status: newassigned

comment:6 Changed 6 years ago by pracine

How do you plan to do that?

comment:7 Changed 6 years ago by 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)...

comment:8 Changed 6 years ago by 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...

comment:9 Changed 6 years ago by pracine

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

comment:10 Changed 6 years ago by jorgearevalo

Great news!

comment:11 Changed 6 years ago by pracine

Priority: criticalblocker

comment:12 Changed 6 years ago by pracine

I filled a ticket in GDAL Trac:

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

comment:13 Changed 6 years ago by jorgearevalo

Resolution: fixed
Status: assignedclosed

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.

comment:14 Changed 6 years ago by pracine

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

comment:15 Changed 6 years ago by 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?

comment:16 Changed 6 years ago by 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.

comment:17 Changed 6 years ago by jorgearevalo

Now the existence of GDALFPolygonize is checked. r7316

comment:18 Changed 6 years ago by dustymugs

Resolution: fixed
Status: closedreopened

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.

comment:19 Changed 6 years ago by dustymugs

Resolution: fixed
Status: reopenedclosed

Fixed in r7785.

Note: See TracTickets for help on using tickets.