I concur. Great work Dan :)
> -----Original Message----- > From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of > Paul Ramsey > Sent: Monday, February 27, 2023 12:12 PM > To: Howard Butler <how...@hobu.co> > Cc: gdal dev <gdal-dev@lists.osgeo.org>; GEOS Development List <geos- > de...@lists.osgeo.org> > Subject: Re: [geos-devel] [gdal-dev] Report on GEOS maintenance grant > > Thanks so much Dan, it’s been great having you on patrol these last few > months, and the big changes you got through lay a nice foundation for the > future of the library. > > P > > > On Feb 27, 2023, at 9:02 AM, Howard Butler <how...@hobu.co> wrote: > > > > > > > >> On Feb 27, 2023, at 8:32 AM, Daniel Baston <dbas...@gmail.com> wrote: > >> > >> Hi All, > >> > >> As February comes to a close, I’m winding down the GEOS maintenance > work that the GDAL PSC funded in 2022 [1]. I appreciate the opportunity to do > this work and am especially thankful to those who reported issues, reviewed > pull requests, or participated in discussions about this work. > >> > >> For anyone who’s interested, I wanted to share a few of the highlights from > my perspective. > >> > >> New functionality: GEOS now supports reading, writing, and overlay of > geometries with an M dimension. I added a number of C API utility functions > requested by client library developers: GEOSLineSubstring, > GEOSEqualsIdentical, and thread/context-specific interrupt handlers. I also > brought in clustering algorithms such as DBSCAN that were previously only > available in PostGIS. > >> > >> Performance enhancements: I found some nice performance wins in key > GEOS algorithms such as geometry intersection testing (GEOSIntersects and > GEOSPreparedIntersects), distance (GEOSPreparedDistance and > GEOSPreparedDistanceWithin) and buffering complex geometries. There are > also some gains in core internal classes such as CoordinateSequence and > STRtree that deliver across-the-board gains. > >> > >> Project maintenance. I was able to simplify our CI setup by removing the > use of Azure and AppVeyor services and bringing the associated environments > into GitHub Actions, write a harness for performance testing and > visualization, and perform code cleanup such as migrating from raw to > managed pointers in key classes. I resolved a number of long-standing bug > reports with WKT input/output, geometry simplification, and > crashes/incorrect results from multiple algorithms in edge cases such as > empty geometry inputs. > >> > >> Not everything panned out, or at least not yet. Something we’ve wanted in > GEOS for a long time is the ability to create a GEOS geometry directly from an > external memory buffer, such as a PostGIS LWGEOM or a GDAL > OGRGeometry (“zero-copy”). I added experimental support for this, but so far > I haven’t found a case where it offers much performance benefit. > >> > >> Dan > >> > >> [1] https://lists.osgeo.org/pipermail/gdal-dev/2022-February/055433.html > > > > Dan, > > > > Thank you so much for taking on these efforts in a way that was both > reactive to the community and aligned with the stated goals of the project. > The project was to move GEOS forward on topics that do not achieve outside > contribution, and you took on some tough topics that reached up and down > the codebase to provide easier to use APIs and performance wins that will be > fun to show off in other contexts like OGR, Shapely, and PostGIS usages. > > > > Thanks, > > > > Howard > > > > _______________________________________________ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > _______________________________________________ > geos-devel mailing list > geos-de...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev