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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
