GDAL Proximity maxdist value

[rbarnes]

Currently gdal_proximity uses a user-specified nodata value, the input's nodata value, or 65535 (in that order of availability) if the distance to a target pixel exceeds maxdist.

This does not seem like the best course of action to me.

For instance, a user may have an irregularly-shaped raster island amid an ocean of nodata cells. They may then calculate a proximity on their island. How, in the result, can the user differentiate between cells which were above maxdist versus cells which would have been nodata because they were nodata in the input?

In my opinion a -maxdistval flag should be provided so that users can specify what value they wish to use to indicate maximum distance, be it nodata or something else.

I am happy to try to write a patch for this if people think it is a good idea.

[Even Rouault]

Hum, not sure how this would work with the current -nodata flag ? It seems to me that the current code has no provision for special processing when input pixel values are equal to the nodata value of the input dataset

[rbarnes]

Should the code have special progressing for when input pixel values are equal to the nodata value of the input dataset?

Right now, every time I run gdal_proximity I have to use a vector cutline of my area of interest's borders in order to crop the resultant back to the area of interest. My input dataset has no_data specified. It seems odd to me that the algorithm does not respect this, though perhaps that respects a different use-case I have not thought of?

[Even Rouault]

I think it could be useful to take input account nodata pixels from the input dataset. Looks like the challenge is to have a clear naming/description of options...

[rbarnes]

Though I feel the algorithm should take account of this by default, that would break backwards compatibility. Is this something that the GDAL project avoids generally, or can it be done with appropriate warnings?

Do you know the rationale behind the current design?

[devans]

I have put together a patch that allows CalculateProximity and by extension gdal_proximity.py to optionally take the input no data value into account. Detecting the difference between out of range and true no-data value.

​https://github.com/OSGeo/gdal/pull/49

Perhaps comparing two rasters of true proximity and another raster generated with a maximum proximity set could be used in your case?

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