Opened 5 years ago

Last modified 5 years ago

#2353 new defect

[raster] GDAL's GDALFPolygonize() function

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

Description (last modified by dustymugs)

Hello,

I got some inconsistency using ST_DumpAsPolygons. It turns out that when I used this function it drops one pixel. Based on this discussion (http://lists.osgeo.org/pipermail/postgis-users/2013-June/037082.html) it looks like GDAL's GDALFPolygonize() is in fault.

Here is the reproducible example:

value's number 4 in this raster come out with ST_Value:

SELECT ST_Value(rast, 1, 8, 2), ST_BandnoDataValue(rast), ST_BandPixelType(rast)
FROM (SELECT '0100000100000000000088C340000000000088C3C03FF0F16F910F29C1F38C064BB32D244100000000000000000000000000000000C67D00000A000A0045FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0100FFFFFFFFFFFFFFFFFFFF0300FFFF040005000600FFFFFFFFFFFF0C000D000E000F00100011001200FFFFFFFFFFFF180019001A001B001C001D001E00FFFFFFFFFFFF2400250026002700280029002A00FFFFFFFFFFFF3400350036003700380039003A00FFFFFFFF4B004C004D004E004F00500051005200FFFFFFFF6A006B006C006D006E006F0070007100FFFFFFFF8F009000910092009300940095009600FFFFFFFFB500B600B700B800B900BA00BB00BC00'::raster rast) foo

but not with ST_DumpAsPolygons:

SELECT (ST_DumpAsPolygons(rast)).val
FROM (SELECT '0100000100000000000088C340000000000088C3C03FF0F16F910F29C1F38C064BB32D244100000000000000000000000000000000C67D00000A000A0045FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0100FFFFFFFFFFFFFFFFFFFF0300FFFF040005000600FFFFFFFFFFFF0C000D000E000F00100011001200FFFFFFFFFFFF180019001A001B001C001D001E00FFFFFFFFFFFF2400250026002700280029002A00FFFFFFFFFFFF3400350036003700380039003A00FFFFFFFF4B004C004D004E004F00500051005200FFFFFFFF6A006B006C006D006E006F0070007100FFFFFFFF8F009000910092009300940095009600FFFFFFFFB500B600B700B800B900BA00BB00BC00'::raster rast) foo

I used ST_Value to show that the value 4 associated with the pixel with coordinates (8,2) actually exists! Please note that adjacent values are different. Also note that ST_PixelAsPolygons() works fine.

GDAL version is 1.9.2

best regards,

Jean

Change History (3)

comment:1 Changed 5 years ago by jeanm

Owner: changed from pramsey to jeanm
Type: patchdefect

comment:2 Changed 5 years ago by dustymugs

Component: postgisraster
Description: modified (diff)
Owner: changed from jeanm to dustymugs

comment:3 Changed 5 years ago by dustymugs

So the problem is in the function GDALFloatEquals() of alg/fpolygonize.cpp. Specifically, aInt and bInt are integers. intDiff is also an integer and is assigned the value from abs(aInt - bInt). Problem is that the difference between aInt and bInt may exceed a 32-bit integer.

This is evident when GDALFloatEquals() is called:

GDALFloatEquals(4, -1)
Note: See TracTickets for help on using tickets.