Opened 4 years ago

Last modified 4 years ago

#2657 new defect

[raster] Respect imprecise real valued nodata

Reported by: mlt Owned by: dustymugs
Priority: medium Milestone: PostGIS GDAL
Component: raster Version: 2.0.x
Keywords: nodata Cc:

Description

PostGIS should handle well real valued, e.g., fractional NODATA values, e.g. with ST_DumpAsPolygons. I suspect rounding takes place somewhere in the code as the following query from my testing database

select (gv).val, ST_Centroid((gv).geom) geom, (gv).val = nd
from (
  select ST_DumpAsPolygons(ST_Union(ST_Clip(rast, geom)), 1, True) gv, ST_BandNoDataValue(rast,1) nd
  from dem, depressions
  where ST_Intersects(rast, geom)
        and gid=1
  group by gid, nd
) foo
--where (gv).val!=(select ST_BandNoDataValue(rast,1) from dem where rid=1)
order by (gv).val
limit 1

returns

-999.900024414063;"01010000202369000000000000BA4E1641000000A0CC825241";t

whereas I'd either expect False for direct comparison with NODATA due to imprecision/rounding, or different value in the first column if PostGIS properly eliminated NODATA from the output.

I'm using

"POSTGIS="2.1.1 r12113" GEOS="3.4.2-CAPI-1.8.2 r3924" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8" LIBJSON="UNKNOWN" TOPOLOGY RASTER"

on Windows 7 64 bit.

Change History (1)

comment:1 Changed 4 years ago by dustymugs

Milestone: PostGIS 2.1.2PostGIS GDAL
Version: 2.1.x2.0.x

ST_DumpAsPolygons() depends on GDALFPolygonize, which works with 32-bit floating point values.

This isn't something we can't fix but I am in the process of writing a polygonization function directly in PostGIS that'll be pixel-type specific.

Note: See TracTickets for help on using tickets.