[gdal-dev] Report on GEOS maintenance grant

Howard Butler howard at hobu.co
Mon Feb 27 09:02:30 PST 2023



> On Feb 27, 2023, at 8:32 AM, Daniel Baston <dbaston at 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



More information about the gdal-dev mailing list