gdal_polygonize specific value

[ysiddiqui]

Add an option to gdal_polygonize to polygonize a single value in the raster file. This would be an inclusion, not an exclusion. This will address the most likely scenario of its use by i-cubed, which is to polygonize the data area of an image from a binary mask of 0s and 1s.

[ctoney]

The attached polygonize.cpp adds an option to polygonize a single value in the raster file. The single pixel value is specified as an additional option to GDALPolygonize in the papszOptions argument ('SINGLE_VAL=n'). Masking to the single pixel value is done after applying an optional mask band, so SINGLE_VAL and mask band can be used together if needed.

The attached gdal_polygonize.py adds a -value argument supporting the new option for single value. (This version of gdal_polygonize.py also contains the -8 argument added in ticket #4655... this attached version of gdal_polygonize.py can replace the version added in ticket 4655).

The attached fpolygonize.cpp adds the SINGLE_VAL option to the floating point version of the algorithm. The floating point side is untested.

[Jukka Rahkonen]

Patch never applied. Do I understand right that purpose is somehow the same as with -mask, but with some kind of images easier for the users? Finding waters from topographic maps with handful of colors for example.

[ysid]

I believe the purpose of this change was to treat the file being operated on as the mask, so that you don't have to specify a separate mask file. It looks like this can be effected by using the -mask option with the same file. The purpose of having a value that could be specified may be to make it easier to pull certain things out, such as your example of water from a topographic map, or the case of a mask with several values instead of just 0s and 1s. However, I don't have an actual use case for a variable single inclusion value at this time. Long story short, we don't need this option now, but it might be something that is "nice to have."

[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.