[geos-devel] GDAL>GEOS development funding priorities

Wed Dec 7 07:09:22 PST 2022

This isn't something I'm very familiar with, but hopefully
https://github.com/libgeos/geos/pull/761 can be the starting point for a
solution.

Dan

On Tue, Dec 6, 2022 at 8:30 PM Nyall Dawson <nyall.dawson at gmail.com> wrote:

> On Wed, 7 Dec 2022 at 11:04, 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.)
>
> 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 <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
> 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 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
> _______________________________________________
> 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/e39e3409/attachment-0001.htm>