OGRGeometry: Add BufferEx method

[dbaston]

What does this PR do?

Adds an OGRGeometry::BufferEx method to allow passing key/value options.

What are related issues/pull requests?

#8132

Tasklist

• Add test case(s)
• Add documentation
• Updated Python API documentation (swig/include/python/docs/)
• Review
• Adjust for comments
• All CI builds and checks have passed

[dbaston]

I'm not sure of the cleanest way to handle this. I guess I could expose BufferEx under a separate name. The tests pass despite the warning.

/home/dan/dev/gdal/swig/include/ogr.i:3713: Warning 511: Can't use keyword arguments with overloaded functions (OGRGeometryShadow::Buffer(double,int)).
/home/dan/dev/gdal/swig/include/ogr.i:3717: Warning 511: Can't use keyword arguments with overloaded functions (OGRGeometryShadow::Buffer(double,char **)).

[dbaston]

This parameter parsing/validation is really verbose and makes me wonder if I'm missing something like std::optional<int> CPLReadInt(std::string_view) or bool CPLReadInt(const char*, int*).

std::from_chars is the best solution I've found but I recently ran into problems with it being unsupported on recent versions of Apple clang.

[rouault]

std::from_chars is the best solution I've found but I recently ran into problems with it being unsupported on recent versions of Apple clang.

well, it is now a requirement since it is used in apps/argparse/argparse.hpp

Otherwise, I wouldn't care much about validating that the provided string is in range and would just blindly use atoi() . We do that almost everywhere....

[rouault]

I'm not sure of the cleanest way to handle this. I guess I could expose BufferEx under a separate name. The tests pass despite the warning.

yeah, we have a similar issue with Feature::SetField(). One solution might be, for Python, to expose different SWIG method names for the 2 forms of Buffer, and have a Python method in swig/include/python/ogr_python.i that redirects to the appropriate one.

[rouault]

std::from_chars is the best solution I've found but I recently ran into problems with it being unsupported on recent versions of Apple clang.

well, it is now a requirement since it is used in apps/argparse/argparse.hpp

Otherwise, I wouldn't care much about validating that the provided string is in range and would just blindly use atoi() . We do that almost everywhere....

[coveralls]

coverage: 69.103% (-0.009%) from 69.112%
when pulling f49da24 on dbaston:buffer-params
into 0367605 on OSGeo:master.

[dbaston]

One solution might be, for Python, to expose different SWIG method names for the 2 forms of Buffer, and have a Python method in swig/include/python/ogr_python.i that redirects to the appropriate one.

I guess the alternative is to disable kwargs for this function, which breaks the usage

ogr.CreateGeometryFromWkt("POINT (0 0)").Buffer(1, quadsecs=1)

That doesn't bother me, especially with "quadsecs" being a typo, but I'm fine to go either way.

[rouault]

is to disable kwargs [... ] That doesn't bother me, especially with "quadsecs" being a typo,

That would be fine too