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.)
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 > the 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
