On Wed, 7 Dec 2022 at 11:04, Daniel Baston <dbas...@gmail.com> wrote: > > Hi All, > > The "Priority 1" item in this list has been completed, and I've been chipping > away at items #3 and #5 as well as many bug fixes and opportunistic > optimizations. While there is plenty to keep busy with along this track, I > want to be responsive to the needs of the broader GEOS community. If you are > using GEOS in your application or library, please be a squeaky wheel and > create GitHub issues with your requests (or reply to this email.)
First up, I'm loving all the optimisations you've been pushing. Very impressive work! My #1 geos wishlist item: proper cancellation support for in progress operations. The GEOS interrupt api (GEOS_interruptRegisterCallback/GEOS_interruptRequest/...) is all designed around a single-threaded application, and it's impossible to selectively cancel an operation in a multi-threaded application. Cancellation support should ideally be handled per context. Nyall > > I'm particularly interested in some feedback on the "defining a C++ API" > item, which is now ticketed at https://github.com/libgeos/geos/issues/755. > Does anyone have an example of a library that has a good system for > designating stable methods while allowing continual changes in the internals? > > Dan > > > On Mon, Mar 7, 2022 at 1:09 PM Paul Ramsey <pram...@cleverelephant.ca> wrote: >> >> All, >> >> Below is the list of priorities for GEOS improvement work that Dan will be >> attacking under the funding provided from the GDAL project. I think these >> all meet the general definition of being generally infrastructural and >> unlikely to be dealt with in the ordinary course of affairs: aka good >> targets for infra funding. As the project contact for the GDAL funding, I >> can approve this list, and it looks fine to me, so this is mostly a FYI, >> with an added layer of "hopefully not missing anything obvious". >> >> ATB, >> P >> >> ------ >> >> > Howard Butler requested that I provide you with a proposed statement of >> > work describing maintenance to be performed on the GEOS library under a >> > grant from the GDAL project. Specifically, he requested that the proposed >> > work target performance improvements and API enhancements that do not >> > typically attract external funding. >> > >> > The specific changes made to the library will be identified during the >> > course of the work based on code review and community input. However, >> > based on past discussions with the community and experience contributing >> > to the library since 2015, I recommend the areas of focus listed below. >> > >> > Priority 1: Improving storage and access of Coordinates. Like JTS, GEOS >> > requires all coordinates to contain three dimensions and be stored in a >> > container that implements the CoordinateSequence interface. A stated >> > purpose of the CoordinateSequence interface is to allow different >> > underlying representations to be used for coordinate storage, such as an >> > array of XYZ values or parallel arrays of X, Y and Z values. This >> > flexibility comes with a cost of slow Coordinate access through virtual >> > methods. However, other assumptions of GEOS code effectively require the >> > XYZ representation. The result is that GEOS pays a performance penalty >> > without gaining a commensurate amount of implementation flexibility. >> > Converting CoordinateSequence into a concrete class backed by a vector of >> > Coordinates is expected to improve performance throughout the library. >> > Further, many commonly used operations only support two-dimensional >> > coordinates. A CoordinateSequence backed by a vector of doubles, mimicking >> > th e P >> ostGIS POINTARRAY type, may also provide improved performance while >> removing the storage penalty of Z and/or M values where they are not >> required. >> > >> > Priority 2: Exploring applications of non-exclusive object ownership. >> > Unlike JTS, GEOS generally relies on an exclusive ownership model whereby >> > an object such as a GeometryCollection has exclusive ownership over its >> > component Geometry objects, which in turn have exclusive ownership over >> > their CoordinateSequences. While this provides simple and predictable >> > memory management, it may also result in extra copies of objects being >> > generated so that they can be used by an operation that may need to modify >> > them (e.g., noding) or by an operation that requires a specific input >> > representation (e.g., unary union). Using const shared pointers may >> > provide opportunities to reduce copying in a way that mimics JTS. However, >> > the need to expose raw pointers through the C API may limit the >> > application of this technique. >> > >> > Priority 3: Removing inheritance from portions of the code where it may >> > reduce performance, such as in SegmentString classes. This would need to >> > be done in coordination with JTS and would be contingent on the >> > availability of Martin Davis during the project period. No work is >> > proposed for classes supporting spatial predicates, as it is expected that >> > these will be replaced in a future release of JTS. >> > >> > Priority 4: Reorganization of the C API such that reentrant and >> > non-reentrant versions of a function are in the same translation unit, >> > thereby allowing the compiler to inline trivial functions. >> > >> > Priority 5: Removing remaining usage of raw pointer types in favor of >> > managed pointers that communicate lifecycle and ownership. >> > >> > Priority 6: Defining a C++ API that can feasibly remain stable between >> > releases. It is challenging for projects to incorporate GEOS via C++ >> > because the library does not promise API or ABI stability between >> > versions. It is not possible to maintain complete API and ABI stability >> > while closely following JTS code without using cumbersome patterns such as >> > PIMPL. However, GEOS could improve its usability for C++ clients by >> > clearly defining limited portions of the API for which the project can >> > support a stability contract (e.g., methods of Geometry) and avoiding the >> > export of internal classes that are not intended for external use. >> > >> > As needed, work may also include tasks such as researching and resolving >> > issues reported to GitHub, reviewing pull requests, and supporting >> > projects such as GDAL and shapely in their use of GEOS. >> > >> > Proposed changes to GEOS will be described in GitHub issues and/or GitHub >> > pull requests. >> >> >> _______________________________________________ >> 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 _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
