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
