Re: [geos-devel] Dropping "trunk" from SVN, continuing under GIT

It seems like it could complicate the workflow when backporting a commit to an earlier release branch. Is it difficult to migrate the SVN branches into git ? (I have no idea). Dan On Wed, Oct 26, 2016 at 5:28 AM, Sandro Santilli wrote: > As per recent motion to move from SVN to

[geos-devel] Porting recent JTS contributions to GEOS

Some interesting new code has recently gone into JTS, for example a KNN search on STRtrees (https://github.com/locationtech/jts/pull/75). JTS is now under the Eclipse license. Can post-1.14 contributions still be ported to GEOS and released under LGPL? Dan

Re: [geos-devel] Ready to switch from SVN to GIT ?

I'm not a PSC member, but I have done a bit of recent porting from JTS. I would also prefer hosting with GitHub. Especially lately, it is difficult to create an OSGeo account and I think this may discourage participation. Dan On Tue, Apr 4, 2017 at 3:42 PM, Mateusz Loskot

Re: [geos-devel] Ready to switch from SVN to GIT ?

On Wed, Apr 5, 2017 at 3:54 AM, Sandro Santilli wrote: > We already have mirrors both on github.com and gitlab.com, this should > be enough to not keep away any contributor (and indeed we do are merging > pull requests opened on those infrastructure). > We are, however, turning

Re: [geos-devel] continuous testing via sponsorship (was: Ready to switch from SVN to GIT ?)

On Thu, Apr 6, 2017 at 4:22 PM, Sandro Santilli wrote: > This is a great idea. Asking them to donate build services would be > a good start. > I would find it to be a peculiar request if a project asked my company for financial resources so that they could attempt to replicate

Re: [geos-devel] Correct use of setPrecision

My understanding is that precision models are considered only in the overlay options (and not in the geometry predicates). Dan On Mon, Sep 4, 2017 at 5:13 AM, Nyall Dawson wrote: > On 4 September 2017 at 17:29, Sandro Santilli wrote: > > On Mon, Sep 04,

Re: [geos-devel] Refactoring CoordinateSequence

> > Regina > > > > *From:* geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] *On Behalf > Of *Daniel Baston > *Sent:* Thursday, August 30, 2018 9:10 AM > *To:* GEOS Development List > *Subject:* [geos-devel] Refactoring CoordinateSequence > > > > I've

Re: [geos-devel] Refactoring CoordinateSequence

; > I was never "married" to JTS, I think GEOS must get "divorced" of JTS, and > a re-design is part of the divorce papers :) > > > > > > On Thu, Aug 30, 2018 at 11:00 AM, Regina Obe wrote: > >> Great. I'm fine with it then – adding to C-APi is fine

Re: [geos-devel] XML Tests

I get four test failures on Ubuntu 16.04 if I run the tests the way that Paul is doing it. Paul's command gives four failures in 70 seconds, while "make check" reports no failures in 7 seconds. Clearly, "make check" isn't running all of the tests. The autotools config relies on hardcoded lists of

Re: [geos-devel] RFC7 - Use CMake as build system for GEOS

> One of the reasons why I still prefer autotools is its ability > to build tester scripts which work before install (via libtool). > Does cmake allow for that ? Are you asking whether the GEOS test suite can be run against a non-installed copy of the library (yes), or are you referring to other

[geos-devel] RFC7 - Use CMake as build system for GEOS

Hi All, I've posted an RFC to switch to CMake as the exclusive build system for GEOS. Some reasoning is in the RFC itself, but it boils down to wasted developer and machine effort supporting the combination of autotools, CMake, and NMake. https://trac.osgeo.org/geos/wiki/RFC7 Thoughts from the

Re: [geos-devel] RFC7 - Use CMake as build system for GEOS

> I'm asking if we can have a "make check" rule, generated by CMake, > that will run the same tests run by current "make check" rule > generated by autotools and with the same important condition of > built binaries and libraries _NOT_ moving out of the build tree. > > Also I'd like to have a

Re: [geos-devel] RFC7 - Use CMake as build system for GEOS

On Thu, Oct 4, 2018 at 9:58 AM Regina Obe wrote: > And as Vicky pointed out the CMake setup in GEOS is kinda old and needs to be > reworked of which Dan did a bit of already. I think people may be thinking of Mateusz. I haven't done any work on the GEOS CMake configuration, though I'm

Re: [geos-devel] RFC7 - Use CMake as build system for GEOS

> Proposal of dropping CMake is only driven by raised concerns about > contributors confusion. I don't care if CMake is kept, as long as > I (as a contributor) don't have to maintain it. Thanks for clarifying. This RFC is about dropping autotools and NMake in favor of CMake, for the reasons

Re: [geos-devel] RFC7 - Use CMake as build system for GEOS

> What you can do to make _me_ use cmake is providing the > UI and functionality I'm used to The pieces I'm not sure about are "make dist" and "make distcheck." The other things you listed are supported. I can try and clarify the docs at https://trac.osgeo.org/geos/wiki/BuildingOnUnixWithCMake

[geos-devel] Refactoring CoordinateSequence

I've been exploring porting the PackedCoordinateSequence from JTS to GEOS because it seems like a useful way to improve the interoperability of GEOS with other code (LWGEOM, for example) without requiring copying of everything into GEOS data structures. It turns out that extending

[geos-devel] C++14

Paul raised an issue yesterday about how to mark something as "deprecated" without using the "[[deprecated]]" attribute provided in C++14. It made me wonder what others think about using C++14 for GEOS. I see C++14 as mostly a "bugfix" to C++11, introducing things like std::make_unique that were

Re: [geos-devel] GeometryPtr or ...

I'd agree; I find that typedefs like GeometryPtr generally obfuscate things. Although one can guess, it's not immediately obvious if GeometryPtr means Geometry*, unique_ptr, shared_ptr, or something else. Dan On Thu, Dec 6, 2018 at 5:46 PM Paul Ramsey wrote: > std::unique_ptr ? > > We've got a

Re: [geos-devel] GeometryPtr or ...

> basis > > On Fri, Dec 7, 2018 at 6:40 AM Daniel Baston wrote: > >> I'd agree; I find that typedefs like GeometryPtr generally obfuscate >> things. Although one can guess, it's not immediately obvious if GeometryPtr >> means Geometry*, unique_ptr, shared_ptr, or some

Re: [geos-devel] GeometryPtr or ...

> > would probably opt for using GeomPtr instead of "GeometryPtr". > Didn't think to look for that one! Looks like we've got ~500 of those, too. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] geos-devel@lists.osgeo.org

Hi Paul, The implementation for ST_LineInterpolatePoint is internal to PostGIS and does not use GEOS: https://github.com/postgis/postgis/blob/svn-trunk/liblwgeom/lwline.c#L534 Dan On Wed, Nov 28, 2018 at 3:04 PM Paul Meems wrote: > Hi List, > > I see PostGIS has >

Re: [geos-devel] Fix Appveyor badge?

you provide a URL for the badge? > > On Fri, Feb 22, 2019 at 10:42 AM Daniel Baston wrote: > >> Hi Martin, >> >> You're welcome to link the badge to my AppVeyor account if you'd like. I >> just set that up because I wanted to test my own pull requests against >>

Re: [geos-devel] Death to auto_ptr?

I think auto_ptr has been removed from master already, no? I'd prefer to lose the typedefs as well, but last time we brought that up I recall there being some disagreement. Dan On Tue, Jan 29, 2019 at 2:19 PM Paul Ramsey wrote: > Any reason not to renovate the code base and remote the various

Re: [geos-devel] Progress on #837 - TopologyException in UnaryUnion

Either way, the union of a polygonal coverage is a common special case that would benefit from having its own algorithm. I implemented this for PostGIS a couple of years ago, though there didn't seem to be much interest at the time [1]. It's probably a better fit for GEOS anyway. I wrote a fairly

Re: [geos-devel] Progress on #837 - TopologyException in UnaryUnion

how to do that efficiently, > which would defeat the purpose. > > > On Tue, Apr 16, 2019 at 8:21 AM Daniel Baston wrote: > >> Either way, the union of a polygonal coverage is a common special case >> that would benefit from having its own algorithm. I implemented

Re: [geos-devel] Compiling geos on windows

Hi Paul, I suspect you're running into the same problem documented in this ticket: https://trac.osgeo.org/geos/ticket/975 I think the CI builds are succeeding because they have -DBUILD_SHARED_LIBS=NO. We probably need to build shared libraries in the CI builds. I haven't fixed it because I don't

Re: [geos-devel] 3.8.0 problems building on Windows

> > BTW, how do you confirm what feature set we’re using? Is there a magic > test? > Not that I'm aware of. I said we're not using anything from > 3.8 because that's what our CMakeLists claims, but I guess it could be wrong. Dan > P > > On Oct 23, 2019, at 6:13

Re: [geos-devel] Motion: Add Dan Baston to GEOS PSC

Thank you! On Wed, Oct 23, 2019 at 9:07 AM Paul Ramsey wrote: > Seeing all in favour and no opposed, let the motion be carried... now > to figure out where we actually keep track of this and update it. > > On Thu, Oct 10, 2019 at 11:21 PM Sandro Santilli wrote: > > > > On Thu, Oct 10, 2019 at

Re: [geos-devel] 3.8.0 problems building on Windows

Hello Asa, Thank you for the reports. I ticketed the assertion failure issue at: https://trac.osgeo.org/geos/ticket/1002 I'm not sure why the CMake version check for MSVC needs to be a fatal error, since we're not using any features from CMake > 3.8. Does anyone object to changing this? Dan

Re: [geos-devel] github issues ?

I enabled them after some discussion on IRC in November. The thought was they are a harmless way to collect user feedback, and a preferable alternative to ignoring users that do not have an OSGeo account. If something is worth ticketing, such as a fix that needs to be applied to a stable branch, I

Re: [geos-devel] scan-build

Yeah, the reporting is pretty bad. If you search the log for "warning" you will find the cause: https://travis-ci.com/libgeos/geos/jobs/266448653#L1082 which is a false positive. The build shows as failed since it's from 3 months ago; Raul has since changed the configuration so that scan-build

Re: [geos-devel] 3.8.1

Sounds good. On Mon, Mar 9, 2020 at 7:36 PM Regina Obe wrote: > Nope. +1 from me. > > > -Original Message- > > From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf > Of > > Paul Ramsey > > Sent: Monday, March 9, 2020 4:52 PM > > To: GEOS Development List > > Subject:

Re: [geos-devel] Remove ttmath?

I ran some of my performance benchmarks (overlay, PIP) am seeing roughly equal or slightly better performance on the DD branch. So, sounds like a win to me. Dan On Wed, Apr 15, 2020 at 5:17 PM Paul Ramsey wrote: > So, we ran into some issues with GEOS 3.8 on a Power architecture, and > based

Re: [geos-devel] OverlayNG for Testing

> > What are people's thoughts on this? It is probably possible to build in > the old behaviour (with a bit of coding effort), and make it the default > path. But I think the new behaviour is preferable and more sensible. > This behavior seems confusing to me, and I'm struggling to tell if it's

Re: [geos-devel] Update to 3.9?

After collecting the inputs and writing to WKT: \copy (select st_astext(st_collect(geom), 18) from wsa_vi) to ~/data/wsa.wkt; I'm seeing 6 seconds in GEOS (not including WKT parsing) bin/perf_unary ~/data/wsa.wkt union # Reading geometries from /home/dan/data/wsa.wkt # Read 1 geometries. #

Re: [geos-devel] Update to 3.9?

> > Of all the design decisions made in the white heat of the development of > the initial release of JTS, the ordering of arguments to the Envelope > constructor is one I regret most. Don't see a way to change it now though > (ideas welcome). > I've been thinking of an alternate way to

Re: [geos-devel] Noisy Patch => Master

I merged in the work I'm comfortable with, so please go ahead with yours. And thanks for taking that on! Dan On Thu, Dec 10, 2020 at 5:10 PM Paul Ramsey wrote: > Dan, et al, > > I've got a noisy branch I'm thinking of merging into master. > > https://github.com/pramsey/geos/tree/namespace >

Re: [geos-devel] GEOS 3.9.0 Released

> > Some headers I see were installed as a facility for C++ library users. > Nowadays we discourage those users so I don't see any big problem with > them being removed (like opBuffer.h and io.h) > I think this comment is about https://trac.osgeo.org/geos/ticket/999. That probably should have

Re: [geos-devel] OverlayNG as Default

This strikes me as a big deal - any thoughts on calling the next release GEOS 4? Dan On Tue, Nov 3, 2020 at 5:45 PM Paul Ramsey wrote: > The switch has been flipped. > If you build GEOS without any options, you will get the OverlayNG engine > backing the standard geometry functions. > >

Re: [geos-devel] Port of PostGIS ST_Subdivide to GEOS / downstream libraries

Hi Brendan, I don't remember it being discussed anywhere, but it's certainly been floating around in my head for a while. I think it's very much worth pursuing. Dan On Fri, Nov 13, 2020 at 11:41 AM Brendan Ward wrote: > I would like to expose functionality similar to ST_Subdivide ( >

[geos-devel] RFC7: Discontinue use of autotools

Hi, I'd like to propose that we revisit RFC 7 [1], introduced in October 2018, which proposes that we use CMake as the exclusive build system for GEOS. The CMake configuration was added to GEOS 11 years ago and has been officially supported since release 3.5, over five years ago. The CMake

Re: [geos-devel] RFC7: Discontinue use of autotools

> > I already have a clone of the gitea repo, and can if need be change > branches (you may recall the non-announcement of needing > --enable_overlayng in > https://lists.osgeo.org/pipermail/geos-devel/2020-October/009754.html ) > I think the root cause for that confusion was GEOS developers

Re: [geos-devel] RFC7: Discontinue use of autotools

> > It's quite a bit faster in GH CI too (unless autotools builds are doing > something additional) > Not just in CI. CMake+ninja is about 2x faster for me locally. Not sure how much of that is CMake and how much is ninja. Dan ___ geos-devel mailing

Re: [geos-devel] RFC7: Discontinue use of autotools

> > It's relevant to the extent that _dropping_ cmake would also resolve > the "need to do double work" issue, if it wasn't for Windows. > It doesn't resolve the issue, because we'd need to re-introduce NMake. If you're suggesting that we drop Windows, please make that motion separately. I'm

Re: [geos-devel] RFC7: Discontinue use of autotools

> > I suggest proponents do address the points above. As I mentioned, Paul added a "make distcheck" in 2019. I have no knowledge of cross-compiling other than that people do it. The documentation [1] appears to provide some instructions. > We don't want to loose functionality for being

Re: [geos-devel] RFC7: Discontinue use of autotools

> > Make the CMake build adhere to CMAKE_INSTALL_LIBDIR so that multiarch > keeps working, I created a pull request for this at https://github.com/libgeos/geos/pull/380 Have CMAKE_BUILD_TYPE=None define NDEBUG so that assert() is removed > from the code, thereby not storing the buildpath in the

Re: [geos-devel] RFC7: Discontinue use of autotools

> > buildflags, multiarch, etc. CMake requires more work to make such > features work, upstreams seldomly care about those where packagers do. > Can you quantify "more work"? Is there anything that can be done by GEOS to reduce it? Dan ___ geos-devel

Re: [geos-devel] RFC7: Discontinue use of autotools

> > Can CMake be made to be "opt-in" instead, to avoid this kind of > situations ? I think packaging releases from a clean tree is a pretty reasonable requirement. The "opt-in" aspect of autotools has caused tests to be skipped for years. Nothing's perfect. Dan

Re: [geos-devel] Motion: Adopt RFC-7 (Discontinue use of autotools)

Looks like the motion has passed. I will proceed with removing the autotools configuration. It is a single commit so it can be easily brought back if needed. Dan On Fri, Jan 15, 2021 at 1:32 PM Sandro Santilli wrote: > On Wed, Jan 13, 2021 at 08:41:42PM -0500, Daniel Baston wrote: >

Re: [geos-devel] [geos-commits] [SCM] GEOS branch master updated. dae18d6c6555b4b129ec053af3a50f7045fd5413

> Could we do this in a build-script agnostic way ? > Maybe just using a "disabled/" directory, or a file prefix ? > That seemed more confusing, especially since we DO want the test to run on 64-bit architectures. A nice thing about handling it this way is that the test output clearly shows that

[geos-devel] Motion: Adopt RFC-7 (Discontinue use of autotools)

Hi, I'd like to thank everyone who contributed to the recent discussion of RFC-7 [1]. Considering the feedback received, and our early position in the release cycle, I do not anticipate problems from removing autotools for our next release. +1 Dan [1]

Re: [geos-devel] GEOS 3.9.0 Released

your code to accommodate API changes? Maybe use the C++ API. Dan On Fri, Jan 29, 2021 at 3:31 PM Greg Troxel wrote: > > Daniel Baston writes: > > >> > >> Some headers I see were installed as a facility for C++ library users. > >> Nowadays we discourage those

Re: [geos-devel] Fwd: [GEOSwift/GEOSwift] Invalid Intersection result after upgrading to GeoSwift 7.0.0+ (#212)

Seems reasonable to me. On Wed, Jan 27, 2021 at 3:25 PM Paul Ramsey wrote: > How do we feel about porting this back into 3.9? > > > https://github.com/libgeos/geos/commit/701e4900c432127c0b2f5a0b2462a51d92fbef8b > > It's not *tiny* but it's also not huge. > > P. > > Begin forwarded message: > >

Re: [geos-devel] Backporting geosop?

I think a safer and lower-maintenance solution would be to write it in such a way that it can link to multiple versions of GEOS, rather than developing it in parallel across four branches. If it is backported I think it is reasonable for the build warnings to be cleared up first. It should

Re: [geos-devel] 3.10.0 Release Vote

+1 On Mon, Oct 18, 2021 at 4:34 PM Paul Ramsey wrote: > Having gone through numerous beta and rc releases, and hearing no > further screams of agony, I call the vote on releasing 3.10.0. > > +1 > > P > ___ > geos-devel mailing list >

Re: [geos-devel] 3.9.2 Release?

+1 Dan On Fri, Oct 29, 2021 at 9:43 PM Paul Ramsey wrote: > I call for approval of a 3.9.2 release! (rah!) > The list of fixes is pretty chunky at this point and it's been a while. > > +1 from me > > > > > - Bug fixes / improvements: > - Add in interrupt points in OverlayNG (#4857, Paul

Re: [geos-devel] GEOS RFC 10 - Move Project to GitHub

+1 Dan On Fri, Oct 29, 2021 at 3:13 PM Paul Ramsey wrote: > http://libgeos.org/development/rfcs/rfc10/ > > GitHub has been the largest source of 3rd party code contribution via > pull-requests for some time now. > > Moving to Github has the following components: > > • Move the

Re: [geos-devel] OpenMP

I've always been a bit uneasy with the "magic" aspect of sticking #pragma statements in the code, relative to alternatives like TBB or the parallel algorithms in the C++ standard. But if it works and can be controlled at runtime, sure? Dan On Tue, Jul 27, 2021 at 4:18 PM Paul Ramsey wrote: >

Re: [geos-devel] GEOS Maintenance Grant

Thank you, all. I'm honored by your support. Please don't hesitate to open issues on the GEOS GitHub page to share any ideas you have about how GEOS can better support GDAL and friends. Dan On Thu, Feb 17, 2022 at 11:13 AM Howard Butler wrote: > Declaring this motion passed with +1's from > >

Re: [geos-devel] Motion: Adopt OSGeo Code of Conduct

+1 Dan On Wed, Feb 16, 2022 at 5:46 PM Sandro Santilli wrote: > On Wed, Feb 16, 2022 at 12:31:06PM -0800, Paul Ramsey wrote: > > I noticed that the GDAL CoC is in fact just the OSGeo CoC, which is > convenient, as we are an OSGeo project. > > > > The code change is here. > > > >

Re: [geos-devel] 3.10.2 release

https://github.com/libgeos/geos/issues/544 seems important to fix, if I'm not too late. Dan On Thu, Jan 13, 2022 at 7:54 PM Paul Ramsey wrote: > I should roll a new patch release, any objections? Will do it either > tomorrow or over the weekend. > > P >

Re: [geos-devel] GEOS C API for Polygonal Coverage operations?

Lots of useful stuff here! I would prefer a specific coverage data type, because it more clearly captures intent, allows preservation of structural information (or other data we haven't yet anticipated) between function calls, and results in function signatures that are simpler those associated

Re: [geos-devel] GEOS C API for Polygonal Coverage operations?

I think this is a good way to do it. In precision-reduction operation I can imagine that some input polygons would disappear; maintaining a 1:1 correspondence would require including NULLs in the output, which seems unwieldy. Dan On Wed, Sep 7, 2022 at 12:15 PM Paul Ramsey wrote: > > > > On

Re: [geos-devel] GEOS C API for Polygonal Coverage operations?

> > But not sure how much extra overhead or difficulty that would cause for > other projects consuming such a new type. > It would be the same difficulty/overhead as creating a GeometryCollection instead of passing around an array of geometries or creating an Envelope instead of working with

Re: [geos-devel] CoordinateArraySequence == CoordinateSequence

This has come up a few times and despite some pushback from users [1] I agree that the benefits of the simplification probably outweigh the costs. Replacing CoordinateSequence with a concrete implementation is top on my list for the GDAL grant work [2] that I will be available to begin on

Re: [geos-devel] GEOS 3.12 regression failure in PostGIS

It's not intentional. I will fix it in GEOS and add a test there. You might consider removing the PostGIS test because it's only testing GEOS behavior. Dan On Fri, Oct 21, 2022 at 10:35 AM Regina Obe wrote: > Hi all, > > PostGIS geos310 regression test, detailed here: > >

Re: [geos-devel] End of Life Policy (EOL)

> What does it mean to "support" this stuff anyways? It's useful for maintainers to have a guideline to follow when backporting. Do I backport only as far as I can apply the patch cleanly? Or is there a list of "supported" releases I should try to cover? Dan

Re: [geos-devel] GEOS C API for Polygonal Coverage operations?

> > If the Coverage type is just a list of polygons, then agreed, it has low > overhead. > > If it is actually a full topological structure, then it has significant > overhead both in constructing the topology and allocating objects > representing the topology graph. I think some of the ideas in

Re: [geos-devel] PSC Vote: RFC 11 Geos Versioning and EOL Policy

+1 On Mon, Sep 19, 2022 at 4:59 PM Martin Davis wrote: > +1. > > On Mon, Sep 12, 2022 at 11:34 AM Regina Obe wrote: > >> Here is my formal request to vote on: >> >> https://libgeos.org/development/rfcs/rfc11/ >> >> To accompany that change we will >> >> 1) Put a link on

Re: [geos-devel] CoordinateArraySequence == CoordinateSequence

if it could use a single memcpy for > 2D as well (related to underlying memory storage above) or even avoid this > one memcpy). > > Best, > Joris > > On Wed, 24 Aug 2022 at 13:50, Daniel Baston wrote: > >> This has come up a few times and despite some pushback from

Re: [geos-devel] GDAL>GEOS development funding priorities

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

Re: [geos-devel] GDAL>GEOS development funding priorities

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, > >

Re: [geos-devel] GDAL>GEOS development funding priorities

> > 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

[geos-devel] GEOS support for Visual Studio 2015

Hi, Not for the first time, I've been testing some code changes that work in all of our CI environments except for Visual Studio 2015. We recently removed support for gcc 4.8 and I'm wondering if we should consider removing support for MSVC 2015 in the same release. Like gcc 4.8, MSVC 2015 lacks

[geos-devel] Switching to C++14

Back in 2018, we discussed whether we should move to C++14 in order to take advantage of minor features like std::make_unique and [[deprecated]]. At that time the consensus seemed to be that the change was not warranted [1]. More recently, I've found the use of C++14 auto lambdas to be a

Re: [geos-devel] Switching to C++14

> > What is the current lowest version? C++11 requires gcc 4.9, strictly, > but 4.8 is often enough. Is this "4.9 worked before and will still > work", or something else. > The lowest gcc version we test is 5. We know that GEOS does not build with gcc 4.8 because we sometimes return

Re: [geos-devel] Switching to C++14

For what it's worth, I can confirm that my pull request builds in C++14 mode with gcc 4.9.4. Dan ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Switching to C++14

t; > > > Thanks, > > Regina > > > > > > > > *From:* geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] *On Behalf > Of *Daniel Baston > *Sent:* Wednesday, January 18, 2023 1:25 PM > *To:* Greg Troxel > *Cc:* GEOS Development List > *Sub

Re: [geos-devel] Switching to C++14

Thank you all for weighing in. I will make the switch to C++14. Dan On Thu, Jan 19, 2023 at 10:36 AM Sandro Santilli wrote: > On Wed, Jan 18, 2023 at 10:38:24AM -0800, Paul Ramsey wrote: > > So far all sounds very safe and sound... +1 > > I've the same impression. > My "debian stable rule"

Re: [geos-devel] Writing a wrapper around LibGEOS

> > My opinion is that to consider an extension of this magnitude, there needs > to be evidence that this initiative is feasible and sustainable over the > long term (at least 10 years). A good way to demonstrate this is a separate > project that extends GEOS with support for representing curves,

Re: [geos-devel] CoverageUnion

I noticed that the OverlayNG coverage union returns an empty polygon if the inputs do not form a coverage, whereas the older algorithm produces an error. I think it would be a good idea to apply an area post-check to the NG version so that we retain the error. I have also noticed cases (TIGER

Re: [geos-devel] CoverageUnion

> We have not been able to conjure up a way to note non-coverage inputs > without incurring a huge performance penalty. I think the area test we have been using catches many non-contrived cases with essentially no penalty. What is the benefit to removing it? Dan

Re: [geos-devel] 3.12.0beta1

Thanks for raising this. There was some discussion of the issue at https://github.com/libgeos/geos/issues/797 and other tickets linked from there, but it was never really resolved. Dan On Mon, Jun 12, 2023 at 8:52 AM Roger Bivand wrote: > An R packages built against GEOS is showing new test

Re: [geos-devel] cmake => 3.15?

I don't see a problem with requiring 3.15, but the issue isn't very clear to me. Is our CMake configuration using some feature of 3.15 while declaring that we only require 3.13? Dan On Mon, Jul 3, 2023 at 3:56 PM Paul Ramsey wrote: > For this small fix with MSVC noise... > >

DOI (digital object identifier) for GEOS

Hello, Would there be any objection to me uploading the most recent release of GEOS to zenodo.org? Uploading a release generates a digital object identifier (DOI) that can be used to cite a specific release of GEOS, as well as a "concept" DOI that can be used to cite GEOS in general. At least in