Re: [geos-devel] MacOS DYLD Fix

An exciting possibility, I haven’t poked that bear yet. > On Nov 10, 2023, at 3:57 PM, Regina Obe wrote: > > Hmm what about GDAL built with GEOS on Mac, anything fun happen there? > > From: Paul Ramsey > Sent: Friday, November 10, 2023 6:51 PM > To: Regina Obe > C

Re: [geos-devel] MacOS DYLD Fix

he postgis build. But it broke proj, which had some tests that expected to be able to manually move an installation post-install. P > > From: Paul Ramsey <mailto:pram...@cleverelephant.ca>> > Sent: Friday, November 10, 2023 12:58 PM > To: Regina Obe mailto:l...@p

Re: [geos-devel] MacOS DYLD Fix

023, at 6:38 PM, Regina Obe wrote: > > I’ll hold off on releasing until there is consensus on this issue. > > From: geos-devel On Behalf Of Paul > Ramsey via geos-devel > Sent: Thursday, November 9, 2023 4:47 PM > To: GEOS Development List > Cc: Paul Ramsey > Subjec

[geos-devel] MacOS DYLD Fix

From XCode 15, the dyld linker no longer falls back to /usr/local/lib when resolving an @rpath, so installing libraries in /usr/local/lib and hoping that the linker finds them there is no longer workable. They need to be installed with LC_ID_DYLIB set to the install location, which in cmake

Re: [geos-devel] PSC Vote: Mark GEOS 3.8 EOL after GEOS 3.8.4 and release 3.9.5, 3.10.6, 3.11.3, 3.12.1

OK doke > On Nov 6, 2023, at 12:57 PM, Regina Obe wrote: > > I was thinking maybe would be good for someone else to do besides you just to > confirm your instructions are followable. > > From: geos-devel On Behalf Of Paul > Ramsey via geos-devel > Sent: Monday,

Re: [geos-devel] PSC Vote: Mark GEOS 3.8 EOL after GEOS 3.8.4 and release 3.9.5, 3.10.6, 3.11.3, 3.12.1

+1. I can do the releases if you wish > On Nov 6, 2023, at 11:52 AM, Martin Davis via geos-devel > wrote: > > +1 > > On Mon, Nov 6, 2023 at 11:48 AM Regina Obe via geos-devel > mailto:geos-devel@lists.osgeo.org>> wrote: >> According to our chart here: >> >>

Re: [geos-devel] Buffering with obstacles

Feels like a raster problem… each cell in your picture is a fixed distance from the starting cell. > On Oct 11, 2023, at 3:49 PM, Nyall Dawson via geos-devel > wrote: > > Hi list! > > (Apologies in advance for the embedded image, I couldn't write this > post sensibly without it). > > I had

[geos-devel] cmake => 3.15?

For this small fix with MSVC noise... https://github.com/libgeos/geos/pull/936 It's still quite an old release, my dev env sits at 3.24 for example. P ___ geos-devel mailing list geos-devel@lists.osgeo.org

[geos-devel] GEOS 3.12.0 Released

Exciting news, geometry processors, the latest feature release of GEOS is now available. http://libgeos.org/posts/2023-06-27-geos-3-12-released/ This release includes the following new features in the C API (and of course underlying changes to the C++ code to support these features): *

[geos-devel] Vote on 3.12.0 Release

Does anyone object to a 3.12.0 release on Monday/Tuesday? P. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.12 release warning

> On Jun 20, 2023, at 10:28 AM, Paul Ramsey wrote: > > > >> On Jun 20, 2023, at 9:29 AM, Greg Troxel wrote: >> >> Sebastiaan Couwenberg writes: >> >>> Warning message: >>> In fun(libname, pkgname) : >>> rgeos: versions of GE

Re: [geos-devel] 3.12 release warning

> On Jun 20, 2023, at 9:29 AM, Greg Troxel wrote: > > Sebastiaan Couwenberg writes: > >> Warning message: >> In fun(libname, pkgname) : >> rgeos: versions of GEOS runtime 3.12.0beta2-CAPI-1.18.0 >> and GEOS at installation 3.11.1-CAPI-1.17.1differ > > Also, I found that geoe does not use

Re: [geos-devel] 3.12 release warning

> On Jun 20, 2023, at 9:16 AM, Sebastiaan Couwenberg wrote: > > On 6/20/23 17:58, Paul Ramsey wrote: >>> On Jun 20, 2023, at 8:55 AM, Sebastiaan Couwenberg >>> wrote: >>> On 6/20/23 00:04, Paul Ramsey wrote: >>>> Please, test 3.12beta2 an

Re: [geos-devel] 3.12 release warning

> On Jun 20, 2023, at 8:55 AM, Sebastiaan Couwenberg wrote: > > On 6/20/23 00:04, Paul Ramsey wrote: >> Please, test 3.12beta2 and let us know if you’re finding any issues, I am >> planning to release 3.12 at the end of the week, if there are no reports of >>

Re: [geos-devel] 3.12 release warning

> On Jun 19, 2023, at 8:20 PM, Sebastiaan Couwenberg wrote: > > On 6/20/23 00:04, Paul Ramsey wrote: >> Please, test 3.12beta2 and let us know if you’re finding any issues, I am >> planning to release 3.12 at the end of the week, if there are no reports of >>

[geos-devel] 3.12 release warning

Please, test 3.12beta2 and let us know if you’re finding any issues, I am planning to release 3.12 at the end of the week, if there are no reports of issues with the last beta release. P. ___ geos-devel mailing list geos-devel@lists.osgeo.org

Re: [geos-devel] 3.12.0beta1

Ytre Sandviken, 5045 Bergen, Norway > roger.biv...@nhh.no > > > From: Paul Ramsey > Sent: 15 June 2023 21:26 > To: Roger Bivand > Cc: geos-devel@lists.osgeo.org; Robert Hijmans; Edzer Pebesma > Subject: Re: [geos-devel] 3.12.0beta1 > > > >> On Jun

Re: [geos-devel] 3.12.0beta1

> On Jun 15, 2023, at 12:08 PM, Roger Bivand wrote: > > Paul, will try tomorrow morning my time. Does this 3.11 contain the fix for > gcc 13 - I had to switch to devel on upgrading to Fedora 38 so if that commit > is also present here, it should be feasible, if not rather harder. There are

Re: [geos-devel] 3.12.0beta2

> On Jun 15, 2023, at 12:18 PM, Sean Gillies wrote: > > The GEOSMinimumRotatedEnvelope algorithm change affects some Shapely tests, > but I don't see any other problems. We're likely to change the tests to match > the new implementation. Super! Yes, this new implementation is “different but

Re: [geos-devel] 3.12.0beta1

to confirm that the change is benign for you. P On Wed, Jun 14, 2023 at 11:57 AM Paul Ramsey wrote: > > > > > On Jun 14, 2023, at 1:26 AM, Roger Bivand wrote: > > > > Thanks, Paul, for responding so quickly. > > > > Having built GEOS with > > https:/

Re: [geos-devel] 3.12.0beta2

On Thu, Jun 15, 2023 at 6:30 AM Greg Troxel wrote: > Looking at the logs (at end), overall this smells like either a > systematic issue where the floating point on my system is broken, or > there is some slight floating point difference from x86, and geos tests > are very sensitive to exact FP

[geos-devel] 3.12.0beta2

Thank you everyone who tested and gave feedback on the first beta release. Having incorporated all the feedback thus far, the next beta is available: https://download.osgeo.org/geos/geos-3.12.0beta2.tar.bz2 Thanks again, P ___ geos-devel mailing list

Re: [geos-devel] 3.12.0beta1

> On Jun 14, 2023, at 1:26 AM, Roger Bivand wrote: > > Thanks, Paul, for responding so quickly. > > Having built GEOS with > https://github.com/pramsey/geos/tree/main-collection-overlay, the issues in > released and development versions of R package terra appear resolved. Super, thanks

Re: [geos-devel] 3.12.0beta1

I have taken a swipe at it here. https://github.com/libgeos/geos/pull/923 > On Jun 12, 2023, at 6:01 AM, Daniel Baston wrote: > > 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

Re: [geos-devel] 3.12.0beta1

> /build/geos-3.12.0~beta1/include/geos/coverage/CoverageRingEdges.h:76: > warning: found documented return type for > geos::coverage::CoverageRingEdges::CoverageRingEdges that does not > return > anything Should be good now. ___

Re: [geos-devel] 3.12.0beta1

> On Jun 8, 2023, at 9:16 AM, Sebastiaan Couwenberg wrote: > > On 6/8/23 18:00, Paul Ramsey wrote: >> done > Thanks. > > Can src/coverage/CoverageBoundarySegmentFinder.cpp be relicensed to match the > rest of GEOS instead of JTS? Or should we expect more EPL-2.0 o

Re: [geos-devel] 3.12.0beta1

ept-ranges: bytes front-end-https: on > On Jun 8, 2023, at 8:59 AM, Paul Ramsey wrote: > > If that's required I can do that now... > > On Thu, Jun 8, 2023 at 8:58 AM Sebastiaan Couwenberg > wrote: >> >> On 6/7/23 22:05, Paul Ramsey wrote: >>&

Re: [geos-devel] 3.12.0beta1

If that's required I can do that now... On Thu, Jun 8, 2023 at 8:58 AM Sebastiaan Couwenberg wrote: > > On 6/7/23 22:05, Paul Ramsey wrote: > > First tagged release auto built and available at > > > > https://github.com/libgeos/geos/releases/tag/3.12.0beta1 > When

Re: [geos-devel] 3.12.0beta1

> On Jun 8, 2023, at 8:42 AM, Greg Troxel wrote: > > Paul Ramsey writes: > >>> On Jun 7, 2023, at 5:26 PM, Greg Troxel wrote: >>> >>> If I install the 3.12.0beta1 package, then the tests pass. So there is >>> a bug, but it is that the tests

Re: [geos-devel] 3.12.0beta1

> On Jun 8, 2023, at 8:28 AM, Paul Ramsey wrote: > >> My only question then about 3.12.0beta1 is if the comings-and-goings >> diff of .h files is what the authors intend. > > Probably! I’ll look at that diff. Yep, all changes confirmed. We’r

Re: [geos-devel] 3.12.0beta1

> On Jun 7, 2023, at 5:26 PM, Greg Troxel wrote: > > If I install the 3.12.0beta1 package, then the tests pass. So there is > a bug, but it is that the tests appaprently refer to installed files, > rather than being controlled to use only files in the build tree. We had this out last

Re: [geos-devel] 3.12.0beta1

vel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of >> Paul Ramsey >> Sent: Wednesday, June 7, 2023 1:53 PM >> To: GEOS Development List >> Subject: [geos-devel] 3.12.0beta1 >> >> Any objections to my cutting a source release for packagers to play with? >>

[geos-devel] 3.12.0beta1

Any objections to my cutting a source release for packagers to play with? P ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Release Time!

Nevermind, I see you’re way ahead of me pushing things into the 3.13 milestone, Dan :) P > On Jun 7, 2023, at 9:10 AM, Paul Ramsey wrote: > > HotPixelIndex: Use STRtree instead of KdTree > <https://github.com/libgeos/geos/pull/769> > CoordinateSequence: create using exte

Re: [geos-devel] Release Time!

ps://github.com/libgeos/geos/pull/747#partial-pull-merging> <https://github.com/libgeos/geos/pull/747#partial-pull-merging> > On Jun 5, 2023, at 8:57 AM, Paul Ramsey wrote: > > I would like to get us to a 3.12 release state over the next few > weeks... are there t

[geos-devel] Release Time!

I would like to get us to a 3.12 release state over the next few weeks... are there tickets outstanding that anyone feels are critical to release? Things you are working on that you'd like to complete? Please call them out in this thread... Thanks! P

Re: [geos-devel] Breaking changes to WKT output for GEOS 3.12 dev

Good job Mike, I think you’ve found some good historical nonsense underbrush to clear out of the forest. The future will thank you. P > On May 10, 2023, at 5:09 PM, Mike Taves wrote: > > Hi All, > > Since not everyone is subscribed to GitHub changes, this email is to > provide a "heads up"

Re: [geos-devel] CoverageUnion

I put it in. I'm going to flip over to the ng coverage union for CAPI, with the area test in place now. On Sat, Apr 29, 2023 at 5:15 PM Daniel Baston wrote: >> >> We have not been able to conjure up a way to note non-coverage inputs >> without incurring a huge performance penalty. > > > I think

Re: [geos-devel] [postgis-devel] Coverage Functions

For context, the GEOS discussions were here. https://lists.osgeo.org/pipermail/geos-devel/2023-April/010887.html P On Fri, Apr 28, 2023 at 3:00 PM Paul Ramsey wrote: > > > > On Apr 28, 2023, at 2:57 PM, Martin Davis wrote: > > On Fri, Apr 28, 2023 at 7:18 AM Sand

Re: [geos-devel] [postgis-devel] Coverage Functions

> On Apr 28, 2023, at 2:57 PM, Martin Davis wrote: > > On Fri, Apr 28, 2023 at 7:18 AM Sandro Santilli > wrote: >> >> As mentioned in chat, I'm thinking having a GEOSCoverage >> datatype would be advisible here, with one constructor >> taking a vector of Geometry pointer

Re: [geos-devel] [postgis-devel] Coverage Functions

Cc’ing over to geos-devel too > On Apr 28, 2023, at 8:21 AM, Paul Ramsey wrote: > > > >> On Apr 28, 2023, at 7:18 AM, Sandro Santilli wrote: >> >> On Tue, Apr 25, 2023 at 05:03:25PM -0700, Paul Ramsey wrote: >>> The first coverage functions are read

Re: [geos-devel] CoverageUnion

h >> is the same as the other coverage operations. >> >> overlayng/CoverageUnion seems to be quite a bit faster than >> geos/operation/union/CoverageUnion, by my testing. So it has my vote.(They >> are both exposed in geosop, so independent verification is welcome.) >>

Re: [geos-devel] Fedora 38 GCC 13 3.11.2 build failure

Put up a PR with the changes needed to support Gcc13 in older branches, I’ll merge it in. I just don’t have easy access to gcc13 to do the build/test cycle with. P > On Apr 25, 2023, at 5:48 AM, Roger Bivand wrote: > > Having just upgraded to F38, which comes with GCC 13, I deleted my

[geos-devel] CoverageUnion

We have quite a few of them? Which one should be keep and bind into CAPI? geos/operation/union/CoverageUnion.h geos/operation/overlayng/CoverageUnion.h geos/coverage/CoverageUnion.h ___ geos-devel mailing list geos-devel@lists.osgeo.org

[geos-devel] Coverage Operations API

Having a little discussion on GH about the first two coverage functions, for validation and simplification, and some opinions from downstream consumers might be good ;) https://github.com/libgeos/geos/pull/866 P___ geos-devel mailing list

Re: [geos-devel] CAPI \since

There’s an issue if anyone wants to pick it up. https://github.com/libgeos/geos/issues/854 P > On Mar 24, 2023, at 9:43 AM, Paul Ramsey wrote: > > If anyone feels like annotating the doxygen, here’s a list of the CAPI > function additions from 2.2 (start of CAPI) to pre

[geos-devel] CAPI \since

If anyone feels like annotating the doxygen, here’s a list of the CAPI function additions from 2.2 (start of CAPI) to present. P## 2.2 GEOSArea GEOSBoundary GEOSBuffer GEOSContains GEOSConvexHull GEOSCoordSeq_clone GEOSCoordSeq_create GEOSCoordSeq_destroy GEOSCoordSeq_getDimensions

Re: [geos-devel] 3.10.5 and 3.11.2 released

This is expected, they came along for the backport of - Fix handling of odd cases in PolygonHoleJoiner (JTS-946, Paul Ramsey, Martin Davis) P > On Mar 17, 2023, at 6:23 AM, Brian M Hamlin wrote: > > I confirm that 3.11.3 build shows two new header files, called > Po

[geos-devel] 3.10.5 and 3.11.2 released

from Envelope::disjoint (GH-791, Dan Baston) - Fix handling of odd cases in PolygonHoleJoiner (JTS-946, Paul Ramsey, Martin Davis) - Support gcc-13 (GH-743, Sergei Trofimovich) - Disallow Inf envelopes in Quadtree, avoid inf loop (Paul Ramsey) - GEOSUnaryUnion: Fix crash on collection contai

[geos-devel] Release 3.11.2, 3.10.5?

Given a potentially large performance regression in the stable branches [1], I propose doing patch releases for the 3.10 and 3.11 series. There are also decent backlogs of defects repaired as well, so I think these releases will be welcome. Any objections? [1]

[geos-devel] Preserving Collection Type on Precision Reduction

Anyone have opinions on this one? https://github.com/libgeos/geos/issues/662 On the one hand it’s easily worked around in PostGIS. On the other hand, it’s a biter for anyone working with homogeneous geometry type. P___ geos-devel mailing list

Re: [geos-devel] [gdal-dev] Report on GEOS maintenance grant

Thanks so much Dan, it’s been great having you on patrol these last few months, and the big changes you got through lay a nice foundation for the future of the library. P > On Feb 27, 2023, at 9:02 AM, Howard Butler wrote: > > > >> On Feb 27, 2023, at 8:32 AM, Daniel Baston wrote: >> >>

[geos-devel] External CS Buffer

Some eyes on this, and opinions would be helpful! https://github.com/libgeos/geos/pull/747 P ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Patch Releases

Actually I was wrong, there are very few changed stacked into 3.11, 3.10, 3.9. I released a final 3.6 and marked EOL in the downloads. On Fri, Jan 27, 2023 at 2:19 PM Paul Ramsey wrote: > > No, I'll push it out, the items are crashers so they should be released. > P > > > On

Re: [geos-devel] Patch Releases

es, but do we plan to ever push anymore to it? > > I'm also okay with just calling it dead and saying it died in 3.6.5 if > everyone else is okay with that. > > Thanks, > Regina > >> -Original Message- >> From: geos-devel [mailto:geos-devel-boun...@lists.osg

[geos-devel] Patch Releases

Any objection to my rolling out patch releases for 3.9, 3.10, 3.11? They have about half-dozen changes in NEWS, and it's bee over 6 months since last release. P ___ geos-devel mailing list geos-devel@lists.osgeo.org

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

So far all sounds very safe and sound... +1 > On Jan 18, 2023, at 5:37 AM, Daniel Baston wrote: > > 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

Re: [geos-devel] GEOS support for Visual Studio 2015

I have no skin in the game, so I'm OK for dropping MSVC 2015 going forward... for what that's worth (nothing). P > On Nov 16, 2022, at 4:44 PM, Regina Obe wrote: > > I vote for drop for GEOS 3.12+ > I guess technically we can’t drop for 3.11 and below since those would be > considered

Re: [geos-devel] Stepping down from PSC chair

Since we still "need" to have a PSC per our OSGeo project membership and since Regina says I "have to to it" (paraphrase) I'm putting my name forward. Thanks to Sandro for his decades of service! I think in general, conversation on the mailing list is great, better than votes / moves. Let

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

+1 > On Sep 19, 2022, at 1:28 PM, Regina Obe wrote: > > I am resending this again since no one bothered to vote. > > +1 from me. > Sandro already gave a remark about "You made this voting business a second > job. Why don't you just do things and eventually we rage and cut your head?" > >

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

t. So just to be clear, that leaves >> space open to: >> >> We may put an update on such a release like 3.4 to the 3.4 branch but we >> will not bother tagging it. >> >> I'm not going to say that of course, just saying we are okay with that. >> >> Thanks, >&g

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

egina > > > > >> -----Original Message- >> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of >> Paul Ramsey >> Sent: Monday, September 12, 2022 11:20 AM >> To: GEOS Development List >> Subject: Re: [geos-devel] End of Lif

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

> On Sep 12, 2022, at 8:28 AM, Daniel Baston wrote: > > > 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"

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

> On Sep 12, 2022, at 8:12 AM, Regina Obe wrote: > > I'd like to make an RFC proposing a standardish End of Like Policy > > Does anyone have an issue with that? Only insofar as there's this idea that we support any particular version at all. Honestly, there are some bugs I just cannot be

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

> On Sep 7, 2022, at 3:50 PM, Martin Davis wrote: > > You read my mind. I'm fine with an additional type in PostGIS. > > Along the lines with what Dan Baston said, the idea of having a special > coverage type that multiple operations can be applied to is very appealing > to me. > > But not

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

> On Sep 7, 2022, at 9:12 AM, Brendan Ward wrote: > > Having final outputs (e.g., coverage => polygons) relate 1:1 to the input > polygons so we can re-attach associated data will be essential I wonder if having the userData survive the trip from polygon->coverage->polygon would be

[geos-devel] CoordinateArraySequence == CoordinateSequence

One of the things that tinkering with the SegmenString layer of overlay brought out to me was the extent to which we construct CoordinateSequence almost exclusively out of CoordinateArraySequence. Like, all the time. At yet, because we handle those CoordinateArraySequence at the API level

Re: [geos-devel] Performance 3.10 -> 3.11

Forgot to note the source of the test framework, for those interesting in running themselves: https://github.com/pramsey/geos-performance On Mon, Jul 4, 2022 at 11:43 AM Paul Ramsey wrote: > > I thought I'd run the "standard" performance comparison set over the > latest

[geos-devel] GEOS 3.11.0 Released

previous implementation, for those kinds of inputs. For "normal" inputs, the results should look very much like the old implementation. As usual, numerous bugs have been fixed, and a few performance improvements discovered and implemented. - New things: - OffsetCurve (GH-530, Paul

Re: [geos-devel] 3.11.0 Release Vote

That said, since Greg found a versioning issue on the CAPI I've cut an rc0 anyways, it is at the usual place, please check if that's what you would like to do, as I am going to cut the release Friday. http://libgeos.org/usage/download/ P. On Wed, Jun 29, 2022 at 8:03 AM Paul Ramsey wrote

Re: [geos-devel] 3.11.0 Release Vote

libtool maybe, but it does nothing for me. P. On Tue, Jun 28, 2022 at 5:19 PM Greg Troxel wrote: > > > Paul Ramsey writes: > > > 3.11.0beta2 has been out for a week, and no complaints. This is the vote on > > final release of 3.11.0 > > I didn't get to it because it was

Re: [geos-devel] 3.11.0 Release Vote

No, there's only slightly more than zero code commits since beta2, CI is green, I'm fine w/ the state of things. P. > On Jun 28, 2022, at 8:19 PM, Sebastiaan Couwenberg wrote: > > On 6/29/22 01:27, Paul Ramsey wrote: >> 3.11.0beta2 has been out for a week, and no complaints. T

[geos-devel] 3.11.0 Release Vote

3.11.0beta2 has been out for a week, and no complaints. This is the vote on final release of 3.11.0 +1 Paul P ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] build failure of 3.10.3 on smartos (= illumos)

> > Looking at > https://github.com/google/sentencepiece/issues/432#issuecomment-639434698, it > seems this is a known defect of Solaris world > > Using 5.0 should be a no-brainer and portable fix. > > Le 22/06/2022 à 00:22, Greg Troxel a écrit : >> Paul Ramsey writes: &

Re: [geos-devel] build failure of 3.10.3 on smartos (= illumos)

Well, it's super rare, platformwise so I don't really categorize it as "our problem", but it's nice to be clearer. What's the simplest way to even find out if a change fixes this? I'm tempted to make everything std::sqrt() on some kind of principle, but I have no idea if that will actually

[geos-devel] 3.11.0beta2 Released

Available wherever fine computational geometries are sold. https://github.com/libgeos/geos/releases/tag/3.11.0beta2 http://download.osgeo.org/geos/geos-3.11.0beta2.tar.bz2 ___ geos-devel mailing list geos-devel@lists.osgeo.org

Re: [geos-devel] mingw64 file libs changed

Nope, missed a spot. Main should be back to original behaviour now. P > > Thanks, > Regina > > >> -Original Message- >> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of >> Paul Ramsey >> Sent: Wednesday, June 15, 2022 12:17

Re: [geos-devel] mingw64 file libs changed

This is in main now. P > On Jun 14, 2022, at 11:05 AM, Regina Obe wrote: > > Sandro, > > I'm not sure I understand your question. > > The issue is not the linking of my code. It's the dependency of > > libgeos_c-1.dll > > To libgeos-3.11.0.dll > > I am trying to get rid of. > > All my

Re: [geos-devel] mingw64 file libs changed

I'm tempted to put the versioned MinGW stuff behind an option and return to the default cmake output by default. That doesn't get to your "ideal" scenario Regina, that would have to be yet another option, since most people are not probably going to want to totally hide the c++ DLL inside the c

Re: [geos-devel] mingw64 file libs changed

> On Jun 13, 2022, at 9:29 AM, Regina Obe wrote: > > Okay guess the question has been answered by > > https://github.com/manisandro/geos/commit/927e442ab1da361d3f487e2b620a878dd1 > 1f191d > > I'll have to live with it moving forward. I wouldn't say so necessarily. I took in a commit from

Re: [geos-devel] mingw64 file libs changed

https://github.com/manisandro/geos/commit/927e442ab1da361d3f487e2b620a878dd11f191d#commitcomment-75986489 > On Jun 13, 2022, at 9:00 AM, Regina Obe wrote: > > I mentioned this on IRC, and Paul is looking into why the change was made. > > I'm mentioning here in case someone knows the reason.

[geos-devel] 3.11.0beta1 Released

Testing out release-on-tag, seems to work. https://github.com/libgeos/geos/releases/tag/3.11.0beta1 Also available at the usual download location. http://download.osgeo.org/geos/geos-3.11.0beta1.tar.bz2 We need to unravel the mystery of the MinGW versioning change for Regina, and presumably

[geos-devel] DDISABLE_GEOS_INLINE

A few months ago we removed all the .inl files and got rid of the optionality around inlining... but we stll have DDISABLE_GEOS_INLINE. Any concerns about me ripping that out of the configuration options? P ___ geos-devel mailing list

[geos-devel] 3.11.0beta1

Any objection to a beta release? We are feature complete for this release, so a quick packaging check release makes sense. P. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] Released 3.7.4, 3.8.3, 3.9.3, 3.10.3

drew Stelter) - Fix IsValidOp to handle repeated node points (JTS-845, Martin Davis) - Fix IsSimpleOp to handle closed LineStrings with repeated endpoints (JTS-851, Martin Davis) - Add OverlayNG area check heuristic (JTS-812, Paul Ramsey) - Improve test_geos_unit application error checking and repor

Re: [geos-devel] Stable Patch Releases

Hearing no objection, I'm going to start chewing through these. P On Wed, Jun 1, 2022 at 2:57 PM Regina Obe wrote: > > > Just getting the last changes to the CAPI into main, but in the meanwhile, > > would like approval to push out all the extant stable patch releases, 3.7, > 3.8, > > 3.9, 3.10.

[geos-devel] Stable Patch Releases

Just getting the last changes to the CAPI into main, but in the meanwhile, would like approval to push out all the extant stable patch releases, 3.7, 3.8, 3.9, 3.10. +1! P ___ geos-devel mailing list geos-devel@lists.osgeo.org

Re: [geos-devel] MSVC / Error C2280

t PolygonHull&) = delete; > PolygonHull& operator=(const PolygonHull&) = delete; > > Even > > Le 08/05/2022 à 01:11, Paul Ramsey a écrit : >> Hi all, >> >> I have again been defeated by MSVC and the nuances of unique_ptr and copy >> ... the

[geos-devel] MSVC / Error C2280

Hi all, I have again been defeated by MSVC and the nuances of unique_ptr and copy ... the build error is here: https://github.com/pramsey/geos/runs/6336639337?check_suite_focus=true#step:3:97 The relevant files are

Re: [geos-devel] GEOS for 3/more-dimensional polyhedra

Muthu, While more effective handling of higher dimensions is something we are considering in the near/medium term, actually doing volumetric calculations is something that goes far beyond simply handling the extra coordinate dimensions, and is not in any developers roap map to my knowledge.

[geos-devel] GDAL>GEOS development funding priorities

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

Re: [geos-devel] JTS Harmony

> On Feb 18, 2022, at 4:31 PM, Paul Ramsey wrote: > > >> On Feb 18, 2022, at 4:15 PM, Andrew Bell wrote: >> >> Has the attitude about keeping the codebase in sync with the JTS code >> changed? I would potentially do some work on this project if this isn

[geos-devel] JTS Harmony

> On Feb 18, 2022, at 4:15 PM, Andrew Bell wrote: > > Has the attitude about keeping the codebase in sync with the JTS code > changed? I would potentially do some work on this project if this isn't a > requirement -- it seemed difficult to make changes that would make the code > more

Re: [geos-devel] GEOS Maintenance Grant

While I appreciate the sentiment behind this, I do not believe the particular breakdown below is reflective of the current needs of this project. - This is a library. The users of the project are not pro-sumers or non-technical, they are C and C++ developers. Users who are not C and C++

Re: [geos-devel] PSC Resignation

Thanks Dale, for your time with the PSC over the years and for Safe's early support and validation of GEOS as a library that could to "real work for real people" back when that was, curiously, an argument that had to be made! Yours, Paul > On Feb 17, 2022, at 5:48 PM, Dale Lutz wrote: > >

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

Thanks all, approved and done. P > On Feb 17, 2022, at 7:05 AM, Howard Butler wrote: > > +1 > > Howard > >> On Feb 16, 2022, at 7:04 PM, Daniel Baston wrote: >> >> +1 >> >> Dan >> >> On Wed, Feb 16, 2022 at 5:46 PM Sandro Santil

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

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. https://github.com/libgeos/geos/pull/568 We already have a +1 Paul +1 Regina ___ geos-devel mailing list

Re: [geos-devel] [gdal-dev] GEOS Maintenance Grant

As usual, GDAL has a reasonable template to work from. https://gdal.org/community/code_of_conduct.html#code-of-conduct I'm happy to have a CoC and happy to just copy someone else's. Other thoughts? P > On Feb 16, 2022, at 7:49 AM, Sean Gillies wrote: > > Howard, > > I'm in favor, but first

Re: [geos-devel] GEOS Maintenance Grant

+1, sounds wonderful. I'm willing to be the liason to the GDAL / NumFocus administrators for this work. P > On Feb 15, 2022, at 10:11 AM, Regina Obe wrote: > > GEOS PSC +1 > >> -Original Message- >> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of >> Howard

[geos-devel] GEOS 3.10.2 Released

, Paul Ramsey) - Improve BuildArea performance (TRAC-1122, Sandro Santilli) - Fix unaryUnion to avoid segfault with empty polygon (GH-501, Mike Taves) - Fix memory leak on exception in prepared geometry (GH-506, Dan Baston) - Iterator invalidation in rare cases (GH-508, Momtchil Momtchev

  1   2   3   4   5   >