GDALSieveFilter rounding floating point values in raster

[Flewellyn]

When I run GDALSieveFilter on a floating point raster, the output result has all values truncated to integer values.

How can I work around this issue?

[Jukka Rahkonen]

This is a bug tracker and gdal-dev mailing list is the preferred forum for asking questions.

By looking at source file ​https://trac.osgeo.org/gdal/browser/trunk/gdal/alg/gdalsievefilter.cpp it seems to contain

/*      Read the image data.                                            */
/* -------------------------------------------------------------------- */
        eErr = GDALRasterIO( hSrcBand, GF_Read, 0, iY, nXSize, 1,
                             panThisLineVal, nXSize, 1, GDT_Int32, 0, 0 );

I suppose that it means that the datatype is hardcoded into Int32 and getting floating point output would require some edits and recompiling.

[Flewellyn]

Sorry, I should have phrased this as a bug report would be phrased.

If the data types are hardcoded to Int32, I'm a bit hesitant to change it without knowing the implications first.

I was able to work around it using multiplication and division by powers of 10 (shifting the decimal points around), but this is a bit cumbersome.

Can this function be changed to operate with the native raster data type, rather than hardcoding? I'm not conversant enough in C++ to make the changes myself.

[Even Rouault]

Extending to float could potentially be possible, but you'd need an option to define a tolerance when pixel values are compared to be evaluated if they must be considered to be the same/close enough (basically what you do with powers of 10 multiplication/division)

[Flewellyn]

Of course, like a "within epsilon" comparison or something. How does GDALFPolygonize do it? I wasn't able to make sense of that function when I looked.

[Even Rouault]

GDALFPolygonize use an almost exact value comparison : ​https://trac.osgeo.org/gdal/browser/trunk/gdal/alg/gdal_alg_priv.h#L194 . But that could be customized

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.