+1 Javier On Mon, 10 Feb 2025 at 20:40, Howard Butler via gdal-dev < gdal-dev@lists.osgeo.org> wrote:
> +1 > > Howard > > > On Feb 10, 2025, at 9:53 AM, Even Rouault via gdal-dev < > gdal-dev@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@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
