> 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
