From geos-trac at osgeo.org Sat Dec 3 12:02:12 2022 From: geos-trac at osgeo.org (GEOS) Date: Sat, 03 Dec 2022 20:02:12 -0000 Subject: [geos-devel] [GEOS] #1097: Dropped holes when buffer(0) -ing a valid geometry In-Reply-To: <050.1e39fd5fe0c7ad473cef493b071d3d01@osgeo.org> References: <050.1e39fd5fe0c7ad473cef493b071d3d01@osgeo.org> Message-ID: <065.6b5237123d21aa363b05518a69c79b3e@osgeo.org> #1097: Dropped holes when buffer(0) -ing a valid geometry --------------------------+--------------------------- Reporter: astronomiser | Owner: geos-devel@? Type: defect | Status: new Priority: minor | Milestone: Component: Default | Version: 3.8.1 Severity: Unassigned | Resolution: Keywords: buffer | --------------------------+--------------------------- Comment (by jorisvandenbossche): Using shapely with GEOS 3.11.1, this seems to work now. -- Ticket URL: GEOS GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). From dbaston at gmail.com Tue Dec 6 17:04:33 2022 From: dbaston at gmail.com (Daniel Baston) Date: Tue, 6 Dec 2022 20:04:33 -0500 Subject: [geos-devel] GDAL>GEOS development funding priorities In-Reply-To: <19C9FF06-1F7D-473C-881A-FC0B15AC6C1D@cleverelephant.ca> References: <19C9FF06-1F7D-473C-881A-FC0B15AC6C1D@cleverelephant.ca> Message-ID: 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 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: From andrew.d.hershberger at gmail.com Tue Dec 6 17:20:55 2022 From: andrew.d.hershberger at gmail.com (Andrew Hershberger) Date: Wed, 07 Dec 2022 01:20:55 +0000 Subject: [geos-devel] GDAL>GEOS development funding priorities In-Reply-To: References: <19C9FF06-1F7D-473C-881A-FC0B15AC6C1D@cleverelephant.ca> Message-ID: 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 at 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: From nyall.dawson at gmail.com Tue Dec 6 17:30:21 2022 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Wed, 7 Dec 2022 11:30:21 +1000 Subject: [geos-devel] GDAL>GEOS development funding priorities In-Reply-To: References: <19C9FF06-1F7D-473C-881A-FC0B15AC6C1D@cleverelephant.ca> Message-ID: On Wed, 7 Dec 2022 at 11:04, Daniel Baston 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 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 From andrew.bell.ia at gmail.com Tue Dec 6 18:17:24 2022 From: andrew.bell.ia at gmail.com (Andrew Bell) Date: Tue, 6 Dec 2022 21:17:24 -0500 Subject: [geos-devel] GDAL>GEOS development funding priorities In-Reply-To: References: <19C9FF06-1F7D-473C-881A-FC0B15AC6C1D@cleverelephant.ca> Message-ID: On Tue, Dec 6, 2022, 8:04 PM Daniel Baston 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? > Do you build a shared library? If so, limit what you export to what you want to be your API. Don't document anything else. Maybe I'm missing something in what you're asking. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbaston at gmail.com Wed Dec 7 07:05:22 2022 From: dbaston at gmail.com (Daniel Baston) Date: Wed, 7 Dec 2022 10:05:22 -0500 Subject: [geos-devel] GDAL>GEOS development funding priorities In-Reply-To: References: <19C9FF06-1F7D-473C-881A-FC0B15AC6C1D@cleverelephant.ca> Message-ID: > > Do you build a shared library? If so, limit what you export to what you > want to be your API. Don't document anything else. > > Maybe I'm missing something in what you're asking. > I don't think you're missing anything, and these are routes we could take. I am inclined to look for a solution that flags "stable" methods but doesn't actually prevent the user from using methods not flagged as such. For example, we could flag all non-stable methods in such a way that a compiler warning is generated unless the user has defined "USE_NON_STABLE_API" or whatever it's called. But since the unstable methods will greatly outnumber the stable ones, it would be nice to have something that didn't require us to put an extra directive all over the place. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbaston at gmail.com Wed Dec 7 07:09:22 2022 From: dbaston at gmail.com (Daniel Baston) Date: Wed, 7 Dec 2022 10:09:22 -0500 Subject: [geos-devel] GDAL>GEOS development funding priorities In-Reply-To: References: <19C9FF06-1F7D-473C-881A-FC0B15AC6C1D@cleverelephant.ca> Message-ID: 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 wrote: > On Wed, 7 Dec 2022 at 11:04, Daniel Baston 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 > 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: From andrew.bell.ia at gmail.com Wed Dec 7 07:30:46 2022 From: andrew.bell.ia at gmail.com (Andrew Bell) Date: Wed, 7 Dec 2022 10:30:46 -0500 Subject: [geos-devel] GDAL>GEOS development funding priorities In-Reply-To: References: <19C9FF06-1F7D-473C-881A-FC0B15AC6C1D@cleverelephant.ca>

Message-ID: At the risk of overstepping...this is open-source software. You never prevent anyone from using any bits that they like. All you're doing by annotating or otherwise hiding things is saying that such code may not exist in future releases, which may or may not be important for users. People who are going to use "private" bits are almost by definition taking some responsibility for integration and upgrades if they desire them. On Wed, Dec 7, 2022 at 10:05 AM Daniel Baston wrote: > Do you build a shared library? If so, limit what you export to what you >> want to be your API. Don't document anything else. >> >> Maybe I'm missing something in what you're asking. >> > > I don't think you're missing anything, and these are routes we could take. > I am inclined to look for a solution that flags "stable" methods but > doesn't actually prevent the user from using methods not flagged as such. > For example, we could flag all non-stable methods in such a way that a > compiler warning is generated unless the user has defined > "USE_NON_STABLE_API" or whatever it's called. But since the unstable > methods will greatly outnumber the stable ones, it would be nice to have > something that didn't require us to put an extra directive all over the > place. > > Dan > _______________________________________________ > geos-devel mailing list > geos-devel at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel > -- Andrew Bell andrew.bell.ia at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From geos-trac at osgeo.org Thu Dec 8 17:29:55 2022 From: geos-trac at osgeo.org (GEOS) Date: Fri, 09 Dec 2022 01:29:55 -0000 Subject: [geos-devel] [GEOS] #1144: OverlayNG intersection gives wrong result In-Reply-To: <046.14c0b39a4c98efcddfdccd9c16a37450@osgeo.org> References: <046.14c0b39a4c98efcddfdccd9c16a37450@osgeo.org> Message-ID: <061.441a9f04ab7c7d159c4c43cb82cf50fa@osgeo.org> #1144: OverlayNG intersection gives wrong result ------------------------+--------------------------- Reporter: theroggy | Owner: geos-devel@? Type: defect | Status: closed Priority: major | Milestone: 3.10.1 Component: Default | Version: 3.9.0 Severity: Unassigned | Resolution: fixed Keywords: | ------------------------+--------------------------- Changes (by dbaston): * status: new => closed * resolution: => fixed Comment: Fixed with [changeset:5ea36b157ed641c506f4316a68487b80fbbda1fc/git] -- Ticket URL: GEOS GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). From geos-trac at osgeo.org Thu Dec 8 17:32:38 2022 From: geos-trac at osgeo.org (GEOS) Date: Fri, 09 Dec 2022 01:32:38 -0000 Subject: [geos-devel] [GEOS] #1012: Thread Sanitizer warns of data race in geos::util::Interrupt::cancel() In-Reply-To: <046.b5405f3a930bd392f9a7c59bf85ebfb2@osgeo.org> References: <046.b5405f3a930bd392f9a7c59bf85ebfb2@osgeo.org> Message-ID: <061.415bee0a51b24420da13232c64542196@osgeo.org> #1012: Thread Sanitizer warns of data race in geos::util::Interrupt::cancel() ------------------------+--------------------------- Reporter: macdrevx | Owner: geos-devel@? Type: defect | Status: new Priority: major | Milestone: 3.11.0 Component: Default | Version: main Severity: Unassigned | Resolution: Keywords: | ------------------------+--------------------------- Comment (by dbaston): A thread-specific interruption mechanism is proposed in https://github.com/libgeos/geos/pull/761 -- Ticket URL: GEOS GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). From geos-trac at osgeo.org Thu Dec 8 17:35:14 2022 From: geos-trac at osgeo.org (GEOS) Date: Fri, 09 Dec 2022 01:35:14 -0000 Subject: [geos-devel] [GEOS] #1108: Doxygen GEOS API returns 404 In-Reply-To: <046.5f91183bee8b42a30fd74b22390c35a3@osgeo.org> References: <046.5f91183bee8b42a30fd74b22390c35a3@osgeo.org> Message-ID: <061.420d25756a93c06ef928ab97caf44931@osgeo.org> #1108: Doxygen GEOS API returns 404 ---------------------------+--------------------------- Reporter: akadouri | Owner: geos-devel@? Type: defect | Status: closed Priority: major | Milestone: 3.9.3 Component: Documentation | Version: 3.9.0 Severity: Unassigned | Resolution: fixed Keywords: doxygen | ---------------------------+--------------------------- Changes (by dbaston): * status: new => closed * resolution: => fixed -- Ticket URL: GEOS GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). From geos-trac at osgeo.org Thu Dec 8 17:37:56 2022 From: geos-trac at osgeo.org (GEOS) Date: Fri, 09 Dec 2022 01:37:56 -0000 Subject: [geos-devel] [GEOS] #1041: Port DBSCAN clustering from PostGIS In-Reply-To: <045.b4518afaae1beb0857e1ced178171fc8@osgeo.org> References: <045.b4518afaae1beb0857e1ced178171fc8@osgeo.org> Message-ID: <060.3282607a6be687ad82e2a22c7ff3c4e2@osgeo.org> #1041: Port DBSCAN clustering from PostGIS -------------------------+--------------------------- Reporter: dericke | Owner: geos-devel@? Type: enhancement | Status: closed Priority: major | Milestone: 3.11.0 Component: Default | Version: 3.8.0 Severity: Unassigned | Resolution: fixed Keywords: | -------------------------+--------------------------- Changes (by dbaston): * status: new => closed * resolution: => fixed Comment: Added with [changeset:6ea4e94e9c3a8d14ee9950f7e12eef273c74047c/git] -- Ticket URL: GEOS GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). From geos-trac at osgeo.org Mon Dec 12 18:34:50 2022 From: geos-trac at osgeo.org (GEOS) Date: Tue, 13 Dec 2022 02:34:50 -0000 Subject: [geos-devel] [GEOS] #859: Voronoi issue In-Reply-To: <045.eb68cecd0b7332a162029ded2e367592@osgeo.org> References: <045.eb68cecd0b7332a162029ded2e367592@osgeo.org> Message-ID: <060.953aa6f17e613200cb25ee2d2781e355@osgeo.org> #859: Voronoi issue ------------------------+--------------------------- Reporter: jjgreen | Owner: geos-devel@? Type: defect | Status: closed Priority: major | Milestone: 3.6.6 Component: Default | Version: 3.5.1 Severity: Unassigned | Resolution: fixed Keywords: | ------------------------+--------------------------- Changes (by dbaston): * status: new => closed * resolution: => fixed -- Ticket URL: GEOS GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS). From geos-trac at osgeo.org Mon Dec 12 19:24:51 2022 From: geos-trac at osgeo.org (GEOS) Date: Tue, 13 Dec 2022 03:24:51 -0000 Subject: [geos-devel] [GEOS] #769: Robustness failure in GEOSVoronoiDiagram In-Reply-To: <045.a5d58c4fc8050711f7e9cf27d0a5e356@osgeo.org> References: <045.a5d58c4fc8050711f7e9cf27d0a5e356@osgeo.org> Message-ID: <060.3bf07b3de3923e277709fab6c810b5e8@osgeo.org> #769: Robustness failure in GEOSVoronoiDiagram ------------------------+--------------------------- Reporter: dbaston | Owner: geos-devel@? Type: defect | Status: closed Priority: major | Milestone: Upstream Component: Default | Version: 3.5.0 Severity: Unassigned | Resolution: fixed Keywords: | ------------------------+--------------------------- Changes (by dbaston): * status: new => closed * resolution: => fixed Comment: Not sure when this was fixed, but I added a test confirming the fix at [changeset:6a5588c912d0f897db4dcd1de7f5b163ccefa3dd/git]. -- Ticket URL: GEOS GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).