[geos-devel] GDAL>GEOS development funding priorities

[Daniel Baston]

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 <pramsey at 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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20221206/6d9cb4e9/attachment.htm>