[gdal-dev] Motion: adopt RFC 107 (Re: Call for review on RFC 107: Add OGRLayer::IGetExtent() and OGRLayer::ISetSpatialFilter())

[Daniel Baston]

+1 Dan

On Mon, Feb 10, 2025 at 3:27 PM 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250210/5848d3c3/attachment.htm>