Thanks to all who looked at this and Even for resolution.
On Thu, May 9, 2024 at 12:11 PM Even Rouault
wrote:
> Andrew,
>
> this is now fixed per
> https://github.com/OSGeo/gdal/commit/393eee77b40ae16751e4d2c0ad3e53386b22d025
> . Doxygen apparently takes the function/method at declaration time,
Andrew,
this is now fixed per
https://github.com/OSGeo/gdal/commit/393eee77b40ae16751e4d2c0ad3e53386b22d025
. Doxygen apparently takes the function/method at declaration time, and
not definition time, and we had a number of unnamed parameters in
declarations. (I also struggled with weird
It looks like Doxygen is using argument names from the function prototype
instead of the implementation:
https://github.com/OSGeo/gdal/blob/master/gcore/gdal_priv.h#L753
I did some searching but didn't come across a way to change this behavior.
It looks like many other functions include the
Hi,
I'm looking at the documentation for GDALRasterBand::RasterIO and it's
surprising that the names of the arguments aren't included in the function
prototype despite them being in the doxygen function definition. The
arguments are described well below the function prototype, making it hard
to
Jukka
Am 08.05.24 um 16:49 schrieb Rahkonen Jukka via gdal-dev:
Warning 1: VA_Parcels layer has a
Virginia_Parcel_Dataset_2024Q1.gdb\a0009.gdbtable.cdf file whose
format is unhandled
This is not new in 3.9.0dev, I get the same warning with 3.8.5. CDF
files are not supported by the