[geos-devel] GDAL>GEOS development funding priorities

Tue Dec 6 17:20:55 PST 2022

I don’t typically work in C++, so I’m not sure how commonplace this is, but I’ve seen a library that used the PImpl pattern to try to provide ABI stability: https://en.cppreference.com/w/cpp/language/pimpl

Sent via Superhuman iOS ( https://sprh.mn/?vip=andrew.d.hershberger@gmail.com )

On Tue, Dec 6 2022 at 5:04 PM, Daniel Baston < dbaston at 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.)
> 
> 
> 
> 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
>> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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/20221207/d4cfb76b/attachment-0001.htm>