Opened 11 years ago
Closed 5 years ago
#2657 closed defect (fixed)
[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 (3)
comment:1 by , 11 years ago
Milestone: | PostGIS 2.1.2 → PostGIS GDAL |
---|---|
Version: | 2.1.x → 2.0.x |
comment:3 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.