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.daw...@gmail.com> wrote: > On Wed, 7 Dec 2022 at 11:04, Daniel Baston <dbas...@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 <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 > 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@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 > _______________________________________________ > 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
