[gdal-dev] Motion: adopt RFC 107 (Re: Call for review on RFC 107: Add OGRLayer::IGetExtent() and OGRLayer::ISetSpatialFilter())
Howard Butler
howard at hobu.co
Mon Feb 10 11:39:39 PST 2025
+1
Howard
> On Feb 10, 2025, at 9:53 AM, Even Rouault via gdal-dev <gdal-dev at lists.osgeo.org> wrote:
>
> Hi,
>
> I move to adopt RFC 107
>
> Starting with my +1
>
> Even
>
> Le 06/02/2025 à 22:19, Even Rouault via gdal-dev a écrit :
>> Hi,
>>
>> Please review https://github.com/OSGeo/gdal/pull/11814: Add OGRLayer::IGetExtent() and OGRLayer::ISetSpatialFilter()
>>
>> It could have gone through a pull request business-as-usual, but as this impacts a number of drivers, including out-of-tree ones, this is worth this small RFC.
>>
>> Summary
>> -------
>>
>> This RFC changes the prototype of the OGRLayer::GetExtent(), GetExtent3D(),
>> SetSpatialFilter() and SetSpatialFilterRect() methods.
>>
>> Motivation
>> ----------
>>
>> Originally GetExtent(), SetSpatialFilter() and SetSpatialFilterRect() were
>> designed for a single geometry field. When support for multiple geometry fields
>> was added per :ref:`rfc-41`, alternate virtual methods were added to accept a
>> ``int iGeomField`` argument, but this causes slightly repeating code patterns
>> in most drivers, and omissions of the boilerplate can cause bugs.
>>
>> Even
>>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
More information about the gdal-dev
mailing list