[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