Re: [geos-devel] [gdal-dev] Report on GEOS maintenance grant
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 > Cc: gdal dev ; GEOS Development List 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 wrote: > > > > > > > >> On Feb 27, 2023, at 8:32 AM, Daniel Baston 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-...@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > ___ > geos-devel mailing list > geos-devel@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [gdal-dev] Report on GEOS maintenance grant
Dan, thanks on behalf of the GEOSwift project and everyone who uses it, especially your work on thread/context-specific interrupt handlers ! I'm looking forward to updating to a new GEOS with these improvements soon! Sent via Superhuman ( https://sprh.mn/?vip=andrew.d.hershber...@gmail.com ) On Mon, Feb 27, 2023 at 12:12 PM, Paul Ramsey < pram...@cleverelephant.ca > wrote: > > > > 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 < howard@ hobu. co ( >> how...@hobu.co ) > wrote: >> >> >>> >>> >>> On Feb 27, 2023, at 8:32 AM, Daniel Baston < dbaston@ gmail. com ( >>> 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 ( 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 ( gdal-...@lists.osgeo.org ) >> https:/ / lists. osgeo. org/ mailman/ listinfo/ gdal-dev ( >> https://lists.osgeo.org/mailman/listinfo/gdal-dev ) >> >> > > > > ___ > geos-devel mailing list > geos-devel@ lists. osgeo. org ( geos-devel@lists.osgeo.org ) > https:/ / lists. osgeo. org/ mailman/ listinfo/ geos-devel ( > https://lists.osgeo.org/mailman/listinfo/geos-devel ) > > >___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
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 wrote: > > > >> On Feb 27, 2023, at 8:32 AM, Daniel Baston 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-...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
