[geos-devel] GEOS 3.9.5 and GEOS 3.8.4 released

[Regina Obe via geos-devel]

As part of a batch release of patches for stable branches, the 3.8.4 and
3.9.5 releases of GEOS are now available for download
https://libgeos.org/usage/download/ .  
Note that GEOS 3.8.4 is the final release for the GEOS 3.8 series.
If you haven't already upgraded to a newer GEOS minor version from GEOS 3.8,
we highly recommend you do so.

Release notes for 3.8.4 and 3.9.5 are below:
3.8.4 EOL  https://github.com/libgeos/geos/blob/3.8.4/NEWS
3.9.5 https://github.com/libgeos/geos/blob/3.9.5/NEWS

Regards,
GEOS Development Team


___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] 3.10.6, 3.11.3, 3.12.1 released

[Regina Obe via geos-devel]

GEOS development team is happy to release GEOS 3.10.6, 3.11.3, and 3.12.1
releases.

Note these are bug fix and improvement releases.

Details at https://libgeos.org/posts/2023-11-11-geos-3-12-1-released/


We'll be releasing GEOS 3.8.4 EOL and GEOS 3.9.5 soon as well.

Thanks,

GEOS Development Team

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] MacOS DYLD Fix

[Regina Obe via geos-devel]

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 
Cc: GEOS Development List ; PostGIS Development 
Discussion 
Subject: Re: [geos-devel] MacOS DYLD Fix

 

 





On Nov 10, 2023, at 3:46 PM, Regina Obe mailto:l...@pcorp.us> > 
wrote:

 

This isn’t an issue with other projects besides PostGIS that use GEOS?

Perhaps related, how much trouble would it be to get PostGIS to use pkgconfig 
for GEOS.  I see that GEOS does ship pkgconfig files.

 

We could probably do it on a going-forward basis, but per usual we’d end up 
with all the old code *plus* the pkgconfig code, so it wouldn’t really “clean 
up” anything. There are autoconf macros already in configure.ac doing pkgconfig 
stuff on other deps, so not too too hard of an add.





 It’s always annoying when I try to do it that I have to explicitly specify the 
geos-config file in PostGIS when in other cases, we can read the pkg-config and 
have in fact standardized on that for other dependencies we use.

 

I’ve added PostGIS dev to this since well we seem to be talking about PostGIS 
now.

 

I’m honestly at a bit of a loss as to whether installing with an rpath and 
expecting linking software to set an appropriate search path is the right 
thing, or locking in a fixed installation location is the right thing. 
Certainly the latter results in less nonsense in the 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...@pcorp.us> >
Cc: GEOS Development List mailto:geos-devel@lists.osgeo.org> >
Subject: Re: [geos-devel] MacOS DYLD Fix

 

I’m on both sides of the argument now. The best/better practice might be to 
leave the install behaviour as-is and try to coerce PostGIS into ensuring the 
LD_RPATH on postgis.so, and other targets is set to the discovered locations of 
the dylib files in the ./configure.

 

P.






On Nov 9, 2023, at 6:38 PM, Regina Obe mailto:l...@pcorp.us> > 
wrote:

 

I’ll hold off on releasing until there is consensus on this issue.

 

From: geos-devel mailto:geos-devel-boun...@lists.osgeo.org> > On Behalf Of Paul Ramsey via 
geos-devel
Sent: Thursday, November 9, 2023 4:47 PM
To: GEOS Development List mailto:geos-devel@lists.osgeo.org> >
Cc: Paul Ramsey mailto:pram...@cleverelephant.ca> >
Subject: [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 world means 
>installing them after setting the INSTALL_NAME_DIR property on the target.

 

https://github.com/libgeos/geos/commit/8cf761b4d77b1261e0f6673c6716adb2daee7eb1

 

I have committed this into main, and would like to pull it back a few stable 
braches too, since I need it to effectively work on postgis/geos on my Macbook, 
but I am going to hold off on the stable branches for a while, if anyone 
working on main finds that this change has broken something in *their* 
environment, please let me know.

 

P.

 

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] MacOS DYLD Fix

[Regina Obe via geos-devel]

This isn’t an issue with other projects besides PostGIS that use GEOS?

Perhaps related, how much trouble would it be to get PostGIS to use pkgconfig 
for GEOS.  I see that GEOS does ship pkgconfig files.

 

It’s always annoying when I try to do it that I have to explicitly specify the 
geos-config file in PostGIS when in other cases, we can read the pkg-config and 
have in fact standardized on that for other dependencies we use.

 

I’ve added PostGIS dev to this since well we seem to be talking about PostGIS 
now.

 

From: Paul Ramsey  
Sent: Friday, November 10, 2023 12:58 PM
To: Regina Obe 
Cc: GEOS Development List 
Subject: Re: [geos-devel] MacOS DYLD Fix

 

I’m on both sides of the argument now. The best/better practice might be to 
leave the install behaviour as-is and try to coerce PostGIS into ensuring the 
LD_RPATH on postgis.so, and other targets is set to the discovered locations of 
the dylib files in the ./configure.

 

P.





On Nov 9, 2023, at 6:38 PM, Regina Obe mailto:l...@pcorp.us> > 
wrote:

 

I’ll hold off on releasing until there is consensus on this issue.

 

From: geos-devel mailto:geos-devel-boun...@lists.osgeo.org> > On Behalf Of Paul Ramsey via 
geos-devel
Sent: Thursday, November 9, 2023 4:47 PM
To: GEOS Development List mailto:geos-devel@lists.osgeo.org> >
Cc: Paul Ramsey mailto:pram...@cleverelephant.ca> >
Subject: [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 world means 
>installing them after setting the INSTALL_NAME_DIR property on the target.

 

https://github.com/libgeos/geos/commit/8cf761b4d77b1261e0f6673c6716adb2daee7eb1

 

I have committed this into main, and would like to pull it back a few stable 
braches too, since I need it to effectively work on postgis/geos on my Macbook, 
but I am going to hold off on the stable branches for a while, if anyone 
working on main finds that this change has broken something in *their* 
environment, please let me know.

 

P.

 

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] MacOS DYLD Fix

[Regina Obe via geos-devel]

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 
Subject: [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 world
means installing them after setting the INSTALL_NAME_DIR property on the
target.

 

https://github.com/libgeos/geos/commit/8cf761b4d77b1261e0f6673c6716adb2daee7
eb1

 

I have committed this into main, and would like to pull it back a few stable
braches too, since I need it to effectively work on postgis/geos on my
Macbook, but I am going to hold off on the stable branches for a while, if
anyone working on main finds that this change has broken something in
*their* environment, please let me know.

 

P.

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe via geos-devel]

> 
> +1 for release of 3.8.4, 3.9.5, 3.10.6, 3.11.3, 3.12.1
> +1 for EOL 3.8
> 
> --strk;
> 
> On Mon, Nov 06, 2023 at 02:48:47PM -0500, Regina Obe via geos-devel
> wrote:
> > According to our chart here:
> >
> > https://libgeos.org/usage/download/
> >
> > We should have EOL'd GEOS 3.8 last month.
> >
> > Looks like we have only 2 changes for 3.8.4
> >
> > https://github.com/libgeos/geos/blob/3.8/NEWS
> >
> > Are we ready to release them and sunset this minor, or should we wait
> > a little longer?
> >
> > I'm putting a +1 to release now, and mark it as EOL.
> >
> > I'm even willing to do the release myself of 3.8.4
> >
> > and  these - which seem to have quite a few fixes piled up
> > 3.9.5   https://github.com/libgeos/geos/blob/3.9/NEWS
> > 3.10.6 https://github.com/libgeos/geos/blob/3.10/NEWS
> > 3.11.3 https://github.com/libgeos/geos/blob/3.11/NEWS.md
> > 3.12.1 https://github.com/libgeos/geos/blob/3.12/NEWS.md
> >
> > +1 for release of 3.8.4, 3.9.5, 3.10.6, 3.11.3, 3.12.1
> >
> > Thanks,
> > Regina

I proclaim motion passed with no down votes and 4 up votes

Regina +1
Paul +1
Martin +1
Sandro +1

I plan to do the release this coming Friday night, so if you have changes
you want in there, get in before then
or give me warning and I can push the release date.

Thanks,
Regina

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe via geos-devel]

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, November 6, 2023 3:52 PM
To: GEOS Development List 
Cc: Paul Ramsey 
Subject: 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 
mailto:geos-devel@lists.osgeo.org> > 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:

https://libgeos.org/usage/download/

We should have EOL'd GEOS 3.8 last month.

Looks like we have only 2 changes for 3.8.4

https://github.com/libgeos/geos/blob/3.8/NEWS

Are we ready to release them and sunset this minor, or should we wait a
little longer?

I'm putting a +1 to release now, and mark it as EOL.

I'm even willing to do the release myself of 3.8.4 

and  these - which seem to have quite a few fixes piled up
3.9.5   https://github.com/libgeos/geos/blob/3.9/NEWS
3.10.6 https://github.com/libgeos/geos/blob/3.10/NEWS
3.11.3 https://github.com/libgeos/geos/blob/3.11/NEWS.md
3.12.1 https://github.com/libgeos/geos/blob/3.12/NEWS.md

+1 for release of 3.8.4, 3.9.5, 3.10.6, 3.11.3, 3.12.1

Thanks,
Regina


___
geos-devel mailing list
geos-devel@lists.osgeo.org <mailto:geos-devel@lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org <mailto:geos-devel@lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel

 

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] 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

[Regina Obe via geos-devel]

According to our chart here:

https://libgeos.org/usage/download/

We should have EOL'd GEOS 3.8 last month.

Looks like we have only 2 changes for 3.8.4

https://github.com/libgeos/geos/blob/3.8/NEWS

Are we ready to release them and sunset this minor, or should we wait a
little longer?

I'm putting a +1 to release now, and mark it as EOL.

I'm even willing to do the release myself of 3.8.4 

and  these - which seem to have quite a few fixes piled up
3.9.5   https://github.com/libgeos/geos/blob/3.9/NEWS
3.10.6 https://github.com/libgeos/geos/blob/3.10/NEWS
3.11.3 https://github.com/libgeos/geos/blob/3.11/NEWS.md
3.12.1 https://github.com/libgeos/geos/blob/3.12/NEWS.md

+1 for release of 3.8.4, 3.9.5, 3.10.6, 3.11.3, 3.12.1

Thanks,
Regina


___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

FWIW Debian Buster I think ships with cmake 3.13 and it’s not that old.  Old 
but not that old.

 

-1  to increase the cmake version until the pressing reason can be better 
explained or there are more pressing reasons.

 

As I recall I think Amazon had to upgrade their CMake to build the latest GEOS.

 

Note Debian Buster ships with 3.13 (which is old but not that old).

I also just approved this run of this pull request, and it broke some of our 
bots like the Ubuntu 20.04, which is kind of in the same boat as Debian Buster, 
old but not that old. Okay maybe in year when it’s time to release we can 
consider it ancient.

 

What I am curious to understand is why our VS windows 2022 build running cmake 
3.26.4  https://github.com/libgeos/geos/actions/runs/5446890161/jobs/9908248625

 

Seems to be doing just fine without this patch am I missing something here?  
What is different about this pull request error. 

What version of VS is this using?

 

Thanks,

Regina

 

 

 

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of 
Daniel Baston
Sent: Monday, July 3, 2023 5:13 PM
To: GEOS Development List 
Subject: 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 mailto:pram...@cleverelephant.ca> > wrote:

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  
https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Vote on 3.12.0 Release

[Regina Obe]

> Paul Ramsey
> Sent: Sunday, June 25, 2023 7:46 PM
> To: GEOS Development List 
> Subject: [geos-devel] Vote on 3.12.0 Release
> 
> Does anyone object to a 3.12.0 release on Monday/Tuesday?
> 
> P.
I don't.  +1 to release.

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.12.0beta2

[Regina Obe]

> 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 results.  But that's just guessing.
> 
> In terms of CI, it's linux/windows/macos all on Intel. In terms of 
> development,
> there's me on MacOS AppleSilicon, so getting a little
> Arm64 in there. It's possible there's something special about the floating 
> point
> in the RPI3, but there's also a failure in unit-io-GeoJSONReader in there, 
> which
> ... is not doing any heavy lifting. So I duno. As with other fun platforms I'm
> always open to patches. :)
> 
> P

We do have 2 rasberry Pis (Arm64 and Arm32) running debian bullseye testing - 
berrie and berrie64
And those look to be showing successes.  But not sure about the endian.

https://libgeos.org/project/development/ci_status/


I think we've had issues in past specific to big endian.

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.12.0beta1

[Regina Obe]

No objection from me :)
Cut please

> -Original Message-
> From: geos-devel [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?
> 
> P
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Release 3.11.2, 3.10.5?

[Regina Obe]

No objections.

+1 to push on.

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Wednesday, March 15, 2023 6:35 PM
> To: GEOS Development List 
> Subject: [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] https://github.com/shapely/shapely/issues/1785
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

Graham,

 

Please do keep us posted on this with your trials and share your code.

As a fellow member of the “not one of us” crowd, I am interested in pushing 
GEOS beyond the very confined geography domain.

 

Thanks,

Regina

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of 
Graham Toal
Sent: Wednesday, March 8, 2023 3:39 PM
To: GEOS Development List 
Subject: Re: [geos-devel] Writing a wrapper around LibGEOS

 

On Wed, Mar 8, 2023 at 1:12 PM Martin Davis mailto:mtncl...@gmail.com> > wrote:

As others have said on this thread, adding curve support to GEOS is likely to 
be a big effort.  

 

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, and implementing a 
*significant* set of *native* operations on curves.  That project should have 
at least two developers contributing algorithmic code to it, to show that there 
is ability and desire to maintain such complex code over the long term.

 

You may find it surprising, but I do appreciate this point of view, and agree 
in as much as if I am the only person advocating for it, it's not going to 
happen as frankly I'm not "one of us" - I'm not a geographer and my interest in 
GEOS is primarily in how far I can stretch it in the direction of being a 
generic domain-independent polygon package that could be used in CAD and other 
fields. This may not be something you're interested in and there may not be 
enough interest in adding curves to the package from programmers working in the 
geography field.

 

And also I agree that a concrete demonstration in terms of a fork or pull 
request is a precondition to a more significant effort by the current 
maintainers; and I'd be happy to start that myself *if* I were a C++ 
programmer, but at the age of 65 I honestly do not have the enthusiasm to learn 
another language to the depth that I know C, which I think is a pre-requisite 
for working on a released codebase in any language.

 

So I'll continue to potter on working on an interface layered on top of your 
package (which is pretty good - the best of all the ones I've looked at, that 
support calling from C) and if any of the GEOS developers find anything I'm 
working on useful in the future then maybe you'll revisit the suggestion of 
adding curves.  I'll drop in infrequently with status updates - and if they're 
not welcome or irrelevant, do say so and I'll stop. I'm pretty thick skinned 
and won't take offence.

 

Incidentally I got the code to do the inverse flattening working relatively 
well last night.  I thought at first it was producing more Bezier segments than 
were needed until I worked out the math that showed that the elliptical arcs I 
was reconstituting were literally not possible with a single Bezier curve. So, 
progress.

 

Regards,

 

Graham

 

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

I concur.  Great work Dan :)


> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Monday, February 27, 2023 12:12 PM
> To: Howard Butler 
> Cc: gdal dev ; GEOS Development List  de...@lists.osgeo.org>
> Subject: 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:
> >>
> >> Hi All,
> >>
> >> As February comes to a close, I’m winding down the GEOS maintenance
> work that the GDAL PSC funded in 2022 [1]. I appreciate the opportunity to do
> this work and am especially thankful to those who reported issues, reviewed
> pull requests, or participated in discussions about this work.
> >>
> >> For anyone who’s interested, I wanted to share a few of the highlights from
> my perspective.
> >>
> >> New functionality: GEOS now supports reading, writing, and overlay of
> geometries with an M dimension. I added a number of C API utility functions
> requested by client library developers: GEOSLineSubstring,
> GEOSEqualsIdentical, and thread/context-specific interrupt handlers. I also
> brought in clustering algorithms such as DBSCAN that were previously only
> available in PostGIS.
> >>
> >> Performance enhancements: I found some nice performance wins in key
> GEOS algorithms such as geometry intersection testing (GEOSIntersects and
> GEOSPreparedIntersects), distance (GEOSPreparedDistance and
> GEOSPreparedDistanceWithin) and buffering complex geometries. There are
> also some gains in core internal classes such as CoordinateSequence and
> STRtree that deliver across-the-board gains.
> >>
> >> Project maintenance. I was able to simplify our CI setup by removing the
> use of Azure and AppVeyor services and bringing the associated environments
> into GitHub Actions, write a harness for performance testing and
> visualization, and perform code cleanup such as migrating from raw to
> managed pointers in key classes. I resolved a number of long-standing bug
> reports with WKT input/output, geometry simplification, and
> crashes/incorrect results from multiple algorithms in edge cases such as
> empty geometry inputs.
> >>
> >> Not everything panned out, or at least not yet. Something we’ve wanted in
> GEOS for a long time is the ability to create a GEOS geometry directly from an
> external memory buffer, such as a PostGIS LWGEOM or a GDAL
> OGRGeometry (“zero-copy”). I added experimental support for this, but so far
> I haven’t found a case where it offers much performance benefit.
> >>
> >> Dan
> >>
> >> [1] https://lists.osgeo.org/pipermail/gdal-dev/2022-February/055433.html
> >
> > Dan,
> >
> > Thank you so much for taking on these efforts in a way that was both
> reactive to the community and aligned with the stated goals of the project.
> The project was to move GEOS forward on topics that do not achieve outside
> contribution, and you took on some tough topics that reached up and down
> the codebase to provide easier to use APIs and performance wins that will be
> fun to show off in other contexts like OGR, Shapely, and PostGIS usages.
> >
> > Thanks,
> >
> > Howard
> >
> > ___
> > gdal-dev mailing list
> > gdal-...@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

Nyall,

Thanks for the input.  I got to check out QGIS more closely with PostGIS curved 
geometries.  I admit to being a closeted Server/Database Admin person, not 
paying much attention to UIs beyond pgAdmin.  It's good to know there is so 
much interest in curves in the GIS community.

Thanks,
Regina

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Nyall Dawson
> Sent: Sunday, January 29, 2023 5:50 PM
> To: GEOS Development List 
> Subject: Re: [geos-devel] Writing a wrapper around LibGEOS
> 
> On Sun, 29 Jan 2023 at 23:20, Regina Obe  wrote:
> >
> > Even,
> >
> >
> >
> > You know the traction for viewing curves?  Last I checked a couple years ago
> it was pretty weak on the OpenLayers, Leaflet, QGIS front.  At a glance things
> seem better, but I haven’t heard people using curves beyond the CAD
> community.
> 
> For the record QGIS has comprehensive curved geometry support, including
> dozens of editing tools for creating and manipulating curved geometries.
> Again, we see a lot of demand for these from European users who need to
> work with official mandated data models.
> 
> I would **love** to see curved geometry support land in GEOS in the future so
> that we can migrate a lot of downstream logic up to GEOS (where it arguably
> belongs).
> 
> Nyall
> 
> 
> 
> >
> >
> >
> > So I’m assuming such work, to even gain traction, would require some more
> concerted effort on the viewing side of things.
> >
> >
> >
> > Regina
> >
> >
> >
> > From: Even Rouault [mailto:even.roua...@spatialys.com]
> > Sent: Sunday, January 29, 2023 6:19 AM
> > To: GEOS Development List ; Regina Obe
> > 
> > Subject: Re: [geos-devel] Writing a wrapper around LibGEOS
> >
> >
> >
> >
> >
> > Sad yes GEOS doesn’t handle curves, and GIS people seem to not care.
> >
> > Actually, that's quite the contrary. A number of people would love to see
> GEOS handle curves. They are part of a number of official GIS data models in
> Europe. But that would be a huge work undertaking. Would probably require a
> GEOS barn raising.
> >
> > Even
> >
> > --
> >
> > http://www.spatialys.com
> >
> > My software is free, but my time generally not.
> >
> > ___
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

Even,

 

You know the traction for viewing curves?  Last I checked a couple years ago it 
was pretty weak on the OpenLayers, Leaflet, QGIS front.  At a glance things 
seem better, but I haven’t heard people using curves beyond the CAD community.

 

So I’m assuming such work, to even gain traction, would require some more 
concerted effort on the viewing side of things.

 

Regina

 

From: Even Rouault [mailto:even.roua...@spatialys.com] 
Sent: Sunday, January 29, 2023 6:19 AM
To: GEOS Development List ; Regina Obe 

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

 

 

Sad yes GEOS doesn’t handle curves, and GIS people seem to not care.

Actually, that's quite the contrary. A number of people would love to see GEOS 
handle curves. They are part of a number of official GIS data models in Europe. 
But that would be a huge work undertaking. Would probably require a GEOS barn 
raising.

Even



-- 
http://www.spatialys.com
My software is free, but my time generally not.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

Graham,

 

At a glance looks good and I love the diagrams.

The doc doesn’t seem to mention how to use the API, more conceptual stuff. I 
assume that will come once your API is more fleshed out. Would be interesting 
to see the code. Probably easier to see major mistakes misunderstandings that 
way.

 

So which language are you creating this wrapper in?  I am assuming C since you 
mentioned in your document

 

“With these two constraints, there appeared to be nothing available that would 
offer the functionality I wanted in a pure C package. Or so I thought, until I 
discovered a feature of LibGEOS that I had overlooked in my original research. 
LibGEOS is written in C++, but - unlike many other C++ packages which are 
accessible from C only through complex interfacing methods (writing in C but 
compiling with a C++ compiler, or performing nasty name-mangling tricks at link 
time, or writing cross-calling interface procedures that can't access all the 
C++ procedures) - this package came with a plain C interface already built. It 
was accessible through a Unix header file and accompanying library that could 
be accessed from standard C with no C++ involvement at all other than building 
the initial library with the supplied make files, and for most target systems 
LibGEOS could in fact be installed with a simple 1-line command using the 
system's package manager.”

 

 

With that said, might be helpful to look at some other projects that use the 
C-API  like “PostGIS”, or maybe you have already (all the files in that folder 
with geos in the name are wrappers around GEOS api:

 

https://git.osgeo.org/gitea/postgis/postgis/src/branch/master/liblwgeom

 

and shapely comes to mind too

 

https://github.com/shapely/shapely/blob/main/src/geos.c

 

Sad yes GEOS doesn’t handle curves, and GIS people seem to not care.

We need CAD folks. :)

 

Funny you mention CNC machines, brought back some fond memories. In my high 
school we had a huge CNC machine

and it was my first reallish use of applying geometry lessons. The CNC machine 
was the only thing I liked about that Woodworking and Machine Shop class we 
were all required to take.

 

Hope that helps,

Regina

 

 

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of 
Graham Toal
Sent: Saturday, January 28, 2023 6:41 PM
To: geos-devel@lists.osgeo.org
Subject: [geos-devel] Writing a wrapper around LibGEOS

 

I'm writing an interface library to wrap around LibGEOS which I hope will 
simplify its use a little in other domains besides GIS. (Mainly for myself but 
I'm documenting it in case it's useful to anyone else.)

 

Rather than look at the (currently somewhat fluid) API, I was hoping one or two 
people familiar with the GEOS package would have a quick look over the first 
(incomplete) draft of the document that I'm writing for it, and pass on any 
major criticisms if I have got anything seriously wrong so far.

 

 http://gtoal.com/src/polygon/Manual.html

 

I haven't documented the API yet as it's not finalised; I'm making changes as I 
document everything. The 'TO DO' section at the end is not part of the document 
- those are just notes to myself.

 

Follow up by email (gt...@gtoal.com  ) or reply here, 
whichever you think is more appropriate.  Thanks,

 

Graham

 

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Patch Releases

[Regina Obe]

Can you roll out 3.6 too so we can end its life for good :)
https://github.com/libgeos/geos/blob/svn-3.6/NEWS

I know it has only 2 changes, 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.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Friday, January 27, 2023 4:42 PM
> To: GEOS Development List 
> Subject: [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
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

Just a side note to think about since we are discussing this.

The only issue I see possibly is with the Redhat/CentOS systems.

 

I know that yum.postgresql.org tries to offer the latest GEOS even on ancient 
systems such as CentOS 7 which sadly many of my clients are still on.  I think 
though it uses the GCC shipping with these.

 

Looking at one of these boxes, I see gcc 4.8.5 (and it’s running GEOS 3.10, 
PostGIS 3.1) – just cause I haven’t upgraded it.  I suspect I could upgrade 
this to PG 15 and would get GEOS 3.11/ PostGIS 3.3.1.  So I think that would 
mean some of these systems won’t be able to run say a GEOS 3.12.

Though I’m not saying that’s a reason to not push C++ 14.  Just throwing it out 
there as an observation point.  CentOS 7 is on its last legs anyway.

 

I haven’t checked what RHEL / Rocky Linux 8/9 ship with, I suspect it’s a C++ 
14 GCC so not a huge concern if that is the case.

 

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

[Regina Obe]

No concerns from me.  +1 for embracing C++14

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of 
Daniel Baston
Sent: Tuesday, January 17, 2023 7:56 PM
To: GEOS Development List 
Subject: [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 compelling advantage 
for reasons I described in a pull request [2]. I don't see a reason not to make 
the change now, since it should have no effect on the number of platforms that 
can build GEOS. (The only versions of gcc and MSVC that can build GEOS also 
support C++14. It's possible that GEOS builds on clang 3.3 and this change 
would require 3.4, though the earliest version we are currently testing with is 
7.) Are there any concerns with making this change?

 

Dan

 

[1] https://lists.osgeo.org/pipermail/geos-devel/2018-December/008768.html

[2] https://github.com/libgeos/geos/pull/800

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

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 breaking changes.

 

I personally don’t have an interest in MSVC in general and I only have MSVC 
2019 installed if I cared to use MSVC for anything.  So dropping MSVC2015 is 
fine with me.

 

FWIW MS changed their policy of visual studio redistributable, so the latest 
redistributable covers 2015, 2017, 2019, and 2022

 

https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

 

So dropping the MSVC2015 I see only as an inconvenience to developers who for 
whatever reason choose to stick with 2015, of those they probably don’t need to 
run newer GEOS either.  MSVC2015 main support ended 2 years ago and is now on 
extended life support. 
https://learn.microsoft.com/en-us/lifecycle/products/visual-studio-2015

 

Thanks,

Regina

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of 
Daniel Baston
Sent: Wednesday, November 16, 2022 7:19 PM
To: GEOS Development List 
Subject: [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 100% C++11 support. It 
also requires us to maintain an AppVeyor CI setup solely for this compiler. Is 
there any particular interest in this compiler, or can we remove it and save 
some effort implementing workarounds?

 

Dan

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

I’m fine with the behavior changing and agree it makes sense.  Only issue is 
with it breaking someone’s existing good.  Though I’d doubt if anyone would 
rely on that as an output, but you never know.

 

I think it’s still good to have a test for it in GEOS to catch these, so it can 
at least be noted in notes as a breaking change.

 

I’ll take the test out of PostGIS if the behavior is kept in GEOS.

 

Thanks,

Regina

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of 
Martin Davis
Sent: Friday, October 21, 2022 12:48 PM
To: GEOS Development List 
Subject: Re: [geos-devel] GEOS 3.12 regression failure in PostGIS

 

Validity is only tested in the XY dimensions.  So it's actually more 
appropriate that only the XY value is reported.

 

On Fri, Oct 21, 2022 at 7:35 AM Regina Obe mailto:l...@pcorp.us> > wrote:

Hi all,

PostGIS geos310 regression test, detailed here:

https://trac.osgeo.org/postgis/ticket/5260

Started failing around October 18th.

The test is this:
SELECT '#168', ST_NPoints(g), ST_AsText(g), ST_isValidReason(g)
FROM ( VALUES
('0106C001000103C001000300E3D9107E234F5041A3DB66BC97A30F
4122ACEF440DAF9440EFFFE3D9107E234F5041A3DB66BC97A30F4122ACEF440D
AF9440EFFFE3D9107E234F5041A3DB66BC97A30F4122ACEF440DAF9440FF
FFEFFF'::geometry)
) AS v(g);


I'm guessing might be caused by this commit -
https://github.com/libgeos/geos/commit/32348a68c5212c89cfefab46891d2b3aada4a 
<https://github.com/libgeos/geos/commit/32348a68c5212c89cfefab46891d2b3aada4ab40>
 
b40 
which happened around the same time tests started failing.

The difference from prior versions is that the 3.12 (main branch) now emits
for isValidReason one less coordinate

Too few points in geometry component[4275341.96977851 259186.966993061]

Instead of:
Too few points in geometry component[4275341.96977851 259186.966993061
1323.76295828331]


Which to me makes sense if we are only considering 2 dimensions for
validity.

Before I change the test, I want to confirm that this is an intentional
change.

Thanks,
Regina



___
geos-devel mailing list
geos-devel@lists.osgeo.org <mailto:geos-devel@lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

Dan,

 

Well if you are going to fix it, less work for me to do nothing :)

So I’ll keep.

 

Thanks for confirming,

Regina

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of 
Daniel Baston
Sent: Friday, October 21, 2022 11:52 AM
To: GEOS Development List 
Subject: 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 mailto:l...@pcorp.us> > wrote:

Hi all,

PostGIS geos310 regression test, detailed here:

https://trac.osgeo.org/postgis/ticket/5260

Started failing around October 18th.

The test is this:
SELECT '#168', ST_NPoints(g), ST_AsText(g), ST_isValidReason(g)
FROM ( VALUES
('0106C001000103C001000300E3D9107E234F5041A3DB66BC97A30F
4122ACEF440DAF9440EFFFE3D9107E234F5041A3DB66BC97A30F4122ACEF440D
AF9440EFFFE3D9107E234F5041A3DB66BC97A30F4122ACEF440DAF9440FF
FFEFFF'::geometry)
) AS v(g);


I'm guessing might be caused by this commit -
https://github.com/libgeos/geos/commit/32348a68c5212c89cfefab46891d2b3aada4a 
<https://github.com/libgeos/geos/commit/32348a68c5212c89cfefab46891d2b3aada4ab40>
 
b40 
which happened around the same time tests started failing.

The difference from prior versions is that the 3.12 (main branch) now emits
for isValidReason one less coordinate

Too few points in geometry component[4275341.96977851 259186.966993061]

Instead of:
Too few points in geometry component[4275341.96977851 259186.966993061
1323.76295828331]


Which to me makes sense if we are only considering 2 dimensions for
validity.

Before I change the test, I want to confirm that this is an intentional
change.

Thanks,
Regina



___
geos-devel mailing list
geos-devel@lists.osgeo.org <mailto:geos-devel@lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] GEOS 3.12 regression failure in PostGIS

[Regina Obe]

Hi all,

PostGIS geos310 regression test, detailed here:

https://trac.osgeo.org/postgis/ticket/5260

Started failing around October 18th.

The test is this:
SELECT '#168', ST_NPoints(g), ST_AsText(g), ST_isValidReason(g)
FROM ( VALUES
('0106C001000103C001000300E3D9107E234F5041A3DB66BC97A30F
4122ACEF440DAF9440EFFFE3D9107E234F5041A3DB66BC97A30F4122ACEF440D
AF9440EFFFE3D9107E234F5041A3DB66BC97A30F4122ACEF440DAF9440FF
FFEFFF'::geometry)
) AS v(g);


I'm guessing might be caused by this commit -
https://github.com/libgeos/geos/commit/32348a68c5212c89cfefab46891d2b3aada4a
b40 
which happened around the same time tests started failing.

The difference from prior versions is that the 3.12 (main branch) now emits
for isValidReason one less coordinate

Too few points in geometry component[4275341.96977851 259186.966993061]

Instead of:
Too few points in geometry component[4275341.96977851 259186.966993061
1323.76295828331]


Which to me makes sense if we are only considering 2 dimensions for
validity.

Before I change the test, I want to confirm that this is an intentional
change.

Thanks,
Regina



___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

Thank you, Thank you :)


> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Monday, October 3, 2022 11:14 AM
> To: GEOS Development List 
> Subject: 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 people know you have plans maybe / preferably before making big
> PR-sized contributions. If it's scary enough, the converstaion might lead
to an
> RFC. Or maybe the whole thing just resolves on emails. I do like emails. I
am
> old.
> 
> ATB,
> P
> 
> > On Sep 23, 2022, at 11:46 AM, Sandro Santilli  wrote:
> >
> > On Fri, Sep 23, 2022 at 02:29:12PM -0400, Regina Obe wrote:
> >>
> >> I just ask for votes when I feel whatever I am thinking of doing
> >> could be opposed by many or I myself are not sure it's a good idea,
> >> before I waste my time making the change.
> >
> > Asking on the mailing list is a great way to know what others think
> > about a proposal. Can't express a thought with 2 bits (which is what
> > you get with voting).
> >
> > -strk;
> > ___
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

> As you may have noticed I seem to be unable to keep up with the fast pace
> in which GEOS development and project organization is moving lately, so I
> think it is fair to step down from the PSC chair role to avoid becoming a
> bottleneck to decisions making.
> 
> I won't go anywhere but burocracy is not my thing.
> 
> Anyone up for the role ?
> 
> --strk;
> 
>   Libre GIS consultant/developer
>   https://strk.kbt.io/services.html

strk,

I guess I've been pushing a lot of motions of late.  I'd hate to think I've
turned GEOS into a bureaucracy.  I hate bureaucracies too.

If it's the busy work of voting that bothers you,
I am happy to make changes to the website etc when I feel like it, and just
notify by email a little before or after  I've made a change for people to
look.

I just ask for votes when I feel whatever I am thinking of doing could be
opposed by many or I myself are not sure it's a good idea, before I waste my
time making the change.


Thanks,
Regina

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

I have put links, expected final dates, and emojis on the download page

 

https://libgeos.org/usage/download/

 

Feel free to change if you don’t like them.

 

Also not sure if it’s worthwhile to add an initial release date or if it would 
make the page too crowded, so I left that out.

 

Thanks,

Regina

 

From: Regina Obe [mailto:l...@pcorp.us] 
Sent: Tuesday, September 20, 2022 10:31 AM
To: 'GEOS Development List' 
Subject: RE: [geos-devel] PSC Vote: RFC 11 Geos Versioning and EOL Policy - 
MOTION PASSED

 

Passed with:

 

Regina +1

Paul +1

Martin +1

Dan +1

Sandro – don’t care

 

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of 
Daniel Baston
Sent: Tuesday, September 20, 2022 10:18 AM
To: GEOS Development List mailto:geos-devel@lists.osgeo.org> >
Subject: Re: [geos-devel] PSC Vote: RFC 11 Geos Versioning and EOL Policy

 

+1

 

On Mon, Sep 19, 2022 at 4:59 PM Martin Davis mailto:mtncl...@gmail.com> > wrote:

+1. 

 

On Mon, Sep 12, 2022 at 11:34 AM Regina Obe mailto:l...@pcorp.us> > 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 https://libgeos.org/usage/download/  to that policy.
2) Put in a Final Release Date column on the download page (maybe
color-coded, though not sure how to color code in markdown so maybe we'll
skip that)
Red - past EOL
Yellow - EOL eminent
Not sure it's worth to color code newer

3) For releases not reached EOL yet, set the expected EOL to 3-4 years from
the .0 release.

Not sure what to do with 3.6 and 3.7, both are passed 4 years

3.6.0 was released 2016-10-25 (more than 5 years ago) (Dan mentioned this is
still in Ubuntu LTS 18, which will be eol'd in April 2023), do we wait or
just EOL it now.

3.7.0 was released 2018-09-10  -- about 4 years ago, so I would consider
this on the potential chopping block given the above proposed policy.


Thanks,
Regina







___
geos-devel mailing list
geos-devel@lists.osgeo.org <mailto:geos-devel@lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org <mailto:geos-devel@lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

Passed with:

 

Regina +1

Paul +1

Martin +1

Dan +1

Sandro – don’t care

 

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of 
Daniel Baston
Sent: Tuesday, September 20, 2022 10:18 AM
To: GEOS Development List 
Subject: Re: [geos-devel] PSC Vote: RFC 11 Geos Versioning and EOL Policy

 

+1

 

On Mon, Sep 19, 2022 at 4:59 PM Martin Davis mailto:mtncl...@gmail.com> > wrote:

+1. 

 

On Mon, Sep 12, 2022 at 11:34 AM Regina Obe mailto:l...@pcorp.us> > 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 https://libgeos.org/usage/download/  to that policy.
2) Put in a Final Release Date column on the download page (maybe
color-coded, though not sure how to color code in markdown so maybe we'll
skip that)
Red - past EOL
Yellow - EOL eminent
Not sure it's worth to color code newer

3) For releases not reached EOL yet, set the expected EOL to 3-4 years from
the .0 release.

Not sure what to do with 3.6 and 3.7, both are passed 4 years

3.6.0 was released 2016-10-25 (more than 5 years ago) (Dan mentioned this is
still in Ubuntu LTS 18, which will be eol'd in April 2023), do we wait or
just EOL it now.

3.7.0 was released 2018-09-10  -- about 4 years ago, so I would consider
this on the potential chopping block given the above proposed policy.


Thanks,
Regina







___
geos-devel mailing list
geos-devel@lists.osgeo.org <mailto:geos-devel@lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org <mailto:geos-devel@lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

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

I'll keep that in mind next time I want to push something I know Sandro will 
not agree with :)

Below is my request again.
If no one has an opinion against by EOD, I will mark the motion passed and make 
the adjustments accordingly.

Thanks,
Regina

---


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 https://libgeos.org/usage/download/  to that policy.
2) Put in a Final Release Date column on the download page (maybe
color-coded, though not sure how to color code in markdown so maybe we'll
skip that)
Red - past EOL
Yellow - EOL eminent
Not sure it's worth to color code newer

3) For releases not reached EOL yet, set the expected EOL to 3-4 years from
the .0 release.

Not sure what to do with 3.6 and 3.7, both are passed 4 years

3.6.0 was released 2016-10-25 (more than 5 years ago) (Dan mentioned this is
still in Ubuntu LTS 18, which will be eol'd in April 2023), do we wait or
just EOL it now.

3.7.0 was released 2018-09-10  -- about 4 years ago, so I would consider
this on the potential chopping block given the above proposed policy.


Thanks,
Regina







___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

> I would not take on the committment of "releases a new minor release every
> 1-2 years". It's really not a mandatory thing, as nobody has fixed funding
to
> implement new features while it may be possible we raise funds for more
> than one feature during a single year thus triggering 4 different minor
> releases in that period (what prevents that?).
> 
I revised the sentence to:

"generally releases a new minor release every 1-2 years"

So we are not held up to a commitment to do so.

> > If people are agreeable with it, I can put a link to it on the
> > download page -- https://libgeos.org/usage/download/
> 
> +1 I saw you already used EOL in the 3.5 record.
> I'd explain the acronym for the occasional reader too
> 
> --strk;
I was going to link to the RFC with a (End-of-Life (EOL) and Version Policy)
text so it's self-explanatory



___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

> Martin Davis  writes:
> 
> > Our development resource bandwidth, and also downstream pipeline size.
> >
> > I think we should have a policy of one minor release per year (if
> > needed) And (try to) make them somewhat scheduled (which we already
> do
> > informally, to align with PostGIS).
> 
In this case, I had specified 1-2 years  following our current behavior.

We could maybe soften that a bit by adding the word "generally" such as
below.

"The GEOS project generally releases a new minor release every 1-2 years.
Each minor release has a git repo dedicated branch for it named after the
minor version."

Our cadence is something I think is useful for users and packagers  of GEOS
to know, so they know when they can expect new features.
As  Greg stated, I would not want to say we absolutely follow this, though I
can't remember a time we haven't pushed out a new minor release for longer
than 2 years.



___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

> To me, this policy is about saying that after 4 years, it's basically out
of the
> question to have an updated version.

Yes that is my intent. 

So 

A) no one not willing to fork over money dares to ask us to backport a
change to what we consider "an ancient version"

B) As developers not have to think about which branches we have to backport
bug fixes.
Sure we have to think a little about "is this safe to backport to X", but if
we say as a general rule, things that have reached EOL, we never backport to
those and clearly spell out what we consider EOL.

C) Send a message to packagers that if you are packaging an end of life
version on a new distribution, you should think long and hard about that and
also what is the expected life of any version you deploy.  By packagers I'm
including DbaaS providers in this group.



___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

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 https://libgeos.org/usage/download/  to that policy.
2) Put in a Final Release Date column on the download page (maybe
color-coded, though not sure how to color code in markdown so maybe we'll
skip that)
Red - past EOL
Yellow - EOL eminent
Not sure it's worth to color code newer

3) For releases not reached EOL yet, set the expected EOL to 3-4 years from
the .0 release.

Not sure what to do with 3.6 and 3.7, both are passed 4 years

3.6.0 was released 2016-10-25 (more than 5 years ago) (Dan mentioned this is
still in Ubuntu LTS 18, which will be eol'd in April 2023), do we wait or
just EOL it now.

3.7.0 was released 2018-09-10  -- about 4 years ago, so I would consider
this on the potential chopping block given the above proposed policy.


Thanks,
Regina







___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

Sounds good to me.

Would you be okay if we put in an estimated EOL date for ones that haven't
released EOL?  
I assume so.  As a rule of thumb, I figure we can when we put up the first
micro, set that final to say 4 years in future or lower?

And then change it as needed once as we get closer to that date.

Thanks,
Regina

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Monday, September 12, 2022 1:57 PM
> To: GEOS Development List 
> Subject: Re: [geos-devel] End of Life Policy (EOL)
> 
> Final release is pretty Boss. It kind of nicely makes the policy clear w/o
having
> to wade through a bunch of text and then do mental math to answer the
> question "is this EOL" and "when will this EOL".
> 
> 
> 
> > On Sep 12, 2022, at 10:55 AM, Regina Obe  wrote:
> >
> > Here is my first pass at a policy.
> >
> > https://libgeos.org/development/rfcs/rfc11/
> >
> > If people are agreeable with it, I can put a link to it on the
> > download page -- https://libgeos.org/usage/download/
> >
> > I was also thinking we should put the First Release date on this pages
to
> make it easier to do the math of how old a minor release is.
> > I think having a Final Release column might be going too far, though
other
> projects do that.
> >
> >
> >
> > From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf
> > Of Kurt Schwehr
> > Sent: Monday, September 12, 2022 12:23 PM
> > To: GEOS Development List 
> > Subject: Re: [geos-devel] End of Life Policy (EOL)
> >
> > Regina,
> >
> > Thank you!  This will be a topic of discussion at the NumFocus funded
> projects later this month where I will be representing GDAL.  I will be
keeping
> an eye on the RFC and this thread for aspects that should be discussed at
the
> meeting.
> >
> > -kurt
> >
> > On Mon, Sep 12, 2022 at 9:19 AM Regina Obe  wrote:
> >> That works for me :)
> >>
> >> So I'll draft up an RFC to that effect.  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,
> >> Regina
> >>
> >> > -Original Message-
> >> > From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On
> >> > Behalf Of Paul Ramsey
> >> > Sent: Monday, September 12, 2022 11:37 AM
> >> > To: GEOS Development List 
> >> > Subject: Re: [geos-devel] End of Life Policy (EOL)
> >> >
> >> > As long as the word "support" does not appear in the text. Perhaps
> >> > "will
> >> not
> >> > have any further numbered releases" is more correct than "not
> supported".
> >> >
> >> > P
> >> >
> >> > > On Sep 12, 2022, at 8:34 AM, Regina Obe  wrote:
> >> > >
> >> > > I'm thinking simple fixes and serious security bugs.
> >> > >
> >> > > I think it's a given we won't break our backs to fix a particular
> >> > > bug if it is deemed "De-stabilizing".
> >> > > By De-stabilizing, I'm thinking enough code to risk causing a
> >> > > particular bigger issue.  Pretty much the same policy we have in
> >> > > PostGIS
> >> > no?
> >> > >
> >> > > But by saying EOL we are saying we will absolutely NEVER push
> >> > > fixes to
> >> it.
> >> > >
> >> > > If some corporate paying customer is running something as crazy
> >> > > as 3.4, you should just fork that for them and patch it there and
> >> > > deal with their upgrade issues some other day.
> >> > >
> >> > > Thanks,
> >> > > Regina
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >> -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 Life Policy (EOL)
> >> > >>
> >> > >>
> >> > >>
> >>

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

[Regina Obe]

Here is my first pass at a policy.

 

https://libgeos.org/development/rfcs/rfc11/

 

If people are agreeable with it, I can put a link to it on the download page -- 
https://libgeos.org/usage/download/

 

I was also thinking we should put the First Release date on this pages to make 
it easier to do the math of how old a minor release is.

I think having a Final Release column might be going too far, though other 
projects do that.

 

 

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of Kurt 
Schwehr
Sent: Monday, September 12, 2022 12:23 PM
To: GEOS Development List 
Subject: Re: [geos-devel] End of Life Policy (EOL)

 

Regina,

 

Thank you!  This will be a topic of discussion at the NumFocus funded projects 
later this month where I will be representing GDAL.  I will be keeping an eye 
on the RFC and this thread for aspects that should be discussed at the meeting.

 

-kurt

 

On Mon, Sep 12, 2022 at 9:19 AM Regina Obe mailto:l...@pcorp.us> > wrote:

That works for me :)

So I'll draft up an RFC to that effect.  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,
Regina

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org 
> <mailto:geos-devel-boun...@lists.osgeo.org> ] On Behalf Of
> Paul Ramsey
> Sent: Monday, September 12, 2022 11:37 AM
> To: GEOS Development List  <mailto:geos-devel@lists.osgeo.org> >
> Subject: Re: [geos-devel] End of Life Policy (EOL)
> 
> As long as the word "support" does not appear in the text. Perhaps "will
not
> have any further numbered releases" is more correct than "not supported".
> 
> P
> 
> > On Sep 12, 2022, at 8:34 AM, Regina Obe  > <mailto:l...@pcorp.us> > wrote:
> >
> > I'm thinking simple fixes and serious security bugs.
> >
> > I think it's a given we won't break our backs to fix a particular bug
> > if it is deemed "De-stabilizing".
> > By De-stabilizing, I'm thinking enough code to risk causing a
> > particular bigger issue.  Pretty much the same policy we have in PostGIS
> no?
> >
> > But by saying EOL we are saying we will absolutely NEVER push fixes to
it.
> >
> > If some corporate paying customer is running something as crazy as
> > 3.4, you should just fork that for them and patch it there and deal
> > with their upgrade issues some other day.
> >
> > Thanks,
> > Regina
> >
> >
> >
> >
> >> -Original Message-
> >> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org 
> >> <mailto:geos-devel-boun...@lists.osgeo.org> ] On
> >> Behalf Of Paul Ramsey
> >> Sent: Monday, September 12, 2022 11:20 AM
> >> To: GEOS Development List  >> <mailto:geos-devel@lists.osgeo.org> >
> >> Subject: Re: [geos-devel] End of Life Policy (EOL)
> >>
> >>
> >>
> >>> On Sep 12, 2022, at 8:12 AM, Regina Obe  >>> <mailto:l...@pcorp.us> > 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 bothered to try and
> >> fix (anything overlay pre 3.9, right? the fix there is to upgrade)
> >> but at the
> > same
> >> time, I don't really mind pulling back trivial stuff pretty far. What
> >> does
> > it mean
> >> to "support" this stuff anyways? Comes right down to it, if a paying
> > customer
> >> on 3.4 has an issue and is unable to upgrade, we'll break our fingers
> >> to
> > try and
> >> fix it. But that has to do with our corporate support, not some
> >> community commitment to support.
> >>
> >> ???
> >>
> >> P
> >>
> >>
> >>>
> >>> I'm thinking of a policy along the lines of
> >>>
> >>> We support a release generally at most X plus years after the first
> >>> version of it, but we have discretion to increase that if needed.
> >>>
> >>> X = 3 - 5 feels about right.
> >>>
> >>> How do people feel about that?
> >>>
> >>> If so I can draft up an RFC about that and we can edit if we are
>

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

[Regina Obe]

That works for me :)

So I'll draft up an RFC to that effect.  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,
Regina

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Monday, September 12, 2022 11:37 AM
> To: GEOS Development List 
> Subject: Re: [geos-devel] End of Life Policy (EOL)
> 
> As long as the word "support" does not appear in the text. Perhaps "will
not
> have any further numbered releases" is more correct than "not supported".
> 
> P
> 
> > On Sep 12, 2022, at 8:34 AM, Regina Obe  wrote:
> >
> > I'm thinking simple fixes and serious security bugs.
> >
> > I think it's a given we won't break our backs to fix a particular bug
> > if it is deemed "De-stabilizing".
> > By De-stabilizing, I'm thinking enough code to risk causing a
> > particular bigger issue.  Pretty much the same policy we have in PostGIS
> no?
> >
> > But by saying EOL we are saying we will absolutely NEVER push fixes to
it.
> >
> > If some corporate paying customer is running something as crazy as
> > 3.4, you should just fork that for them and patch it there and deal
> > with their upgrade issues some other day.
> >
> > Thanks,
> > Regina
> >
> >
> >
> >
> >> -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 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 bothered to try and
> >> fix (anything overlay pre 3.9, right? the fix there is to upgrade)
> >> but at the
> > same
> >> time, I don't really mind pulling back trivial stuff pretty far. What
> >> does
> > it mean
> >> to "support" this stuff anyways? Comes right down to it, if a paying
> > customer
> >> on 3.4 has an issue and is unable to upgrade, we'll break our fingers
> >> to
> > try and
> >> fix it. But that has to do with our corporate support, not some
> >> community commitment to support.
> >>
> >> ???
> >>
> >> P
> >>
> >>
> >>>
> >>> I'm thinking of a policy along the lines of
> >>>
> >>> We support a release generally at most X plus years after the first
> >>> version of it, but we have discretion to increase that if needed.
> >>>
> >>> X = 3 - 5 feels about right.
> >>>
> >>> How do people feel about that?
> >>>
> >>> If so I can draft up an RFC about that and we can edit if we are
> >>> comfortable with that and start EOL'ing other releases besides the
> >>> 3.5 I
> >> recently EOL'd.
> >>>
> >>> Thanks,
> >>> Regina
> >>>
> >>> ___
> >>> geos-devel mailing list
> >>> geos-devel@lists.osgeo.org
> >>> https://lists.osgeo.org/mailman/listinfo/geos-devel
> >>
> >> ___
> >> geos-devel mailing list
> >> geos-devel@lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/geos-devel
> >
> > ___
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

I'm thinking simple fixes and serious security bugs.

I think it's a given we won't break our backs to fix a particular bug if it
is deemed "De-stabilizing".
By De-stabilizing, I'm thinking enough code to risk causing a particular
bigger issue.  Pretty much the same policy we have in PostGIS no?

But by saying EOL we are saying we will absolutely NEVER push fixes to it.

If some corporate paying customer is running something as crazy as 3.4, you
should just fork that for them and patch it there and deal with their
upgrade issues some other day.

Thanks,
Regina




> -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 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 bothered to try and fix
> (anything overlay pre 3.9, right? the fix there is to upgrade) but at the
same
> time, I don't really mind pulling back trivial stuff pretty far. What does
it mean
> to "support" this stuff anyways? Comes right down to it, if a paying
customer
> on 3.4 has an issue and is unable to upgrade, we'll break our fingers to
try and
> fix it. But that has to do with our corporate support, not some community
> commitment to support.
> 
> ???
> 
> P
> 
> 
> >
> > I'm thinking of a policy along the lines of
> >
> > We support a release generally at most X plus years after the first
> > version of it, but we have discretion to increase that if needed.
> >
> > X = 3 - 5 feels about right.
> >
> > How do people feel about that?
> >
> > If so I can draft up an RFC about that and we can edit if we are
> > comfortable with that and start EOL'ing other releases besides the 3.5 I
> recently EOL'd.
> >
> > Thanks,
> > Regina
> >
> > ___
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

I'd like to make an RFC proposing a standardish End of Like Policy

Does anyone have an issue with that?

I'm thinking of a policy along the lines of

We support a release generally at most X plus years after the first version
of it, but we have discretion to increase that if needed.

X = 3 - 5 feels about right.

How do people feel about that?

If so I can draft up an RFC about that and we can edit if we are comfortable
with that and start EOL'ing other releases besides the 3.5 I recently EOL'd.

Thanks,
Regina

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

> > A key question is how to expose these operations in the GEOS C API.  I
> > see two options:
> > 1) Model a Polygonal Coverage as an array of simple Polygons (and
> > possibly
> > MultiPolygons)
> > 2) Provide a Polygonal Coverage datatype (which might contain internal
> > topology)
> 
> Could a coverage datatype allow performing operations on PostGIS
> Topologies w/out building the polygons for each face ? There's an ISO
> standard representation of topologies, maybe such representation could be
> used to transfer those topologies back and forth with GEOS ?
> 
> --strk;
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

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 sure how much extra overhead or difficulty that would cause for
other projects consuming such a new type.
Maybe for some it can have a mutator to convert it to a polygon array or
something, for projects that can't handle consuming additional types.

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.11.0 Release Vote

[Regina Obe]

+1

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Tuesday, June 28, 2022 7:28 PM
> To: GEOS Development List 
> Subject: [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

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] mingw64 file libs changed

[Regina Obe]

Back to old names now.

Thanks,
Regina

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Wednesday, June 15, 2022 1:08 PM
> To: GEOS Development List 
> Subject: Re: [geos-devel] mingw64 file libs changed
> 
> 
> 
> > On Jun 15, 2022, at 9:32 AM, Regina Obe  wrote:
> >
> > Now I see libgeos_c-1.dll and libgeos.dll.
> >
> > It's different from 3.9 and 3.10, which had libgeos_c.dll for the
> > c-api lib file but I'm fine with that.  Just want to make sure you
> > intended to keep that change.
> 
> 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 PM
> >> To: GEOS Development List 
> >> Cc: roger.biv...@nhh.no
> >> Subject: 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 code ends up having a dependency on libgeos_c-1.dll  (before
> >>> libgeos_c.dll) Which before linked to a unversioned libgeos.dll
> >>> (this libgeos.dll was always called that so could be cleanly removed
> >>> and
> >>> replaced)
> >>>
> >>> I don't care about if the c dll is called libgeos_c-1.dll or
> > libgeos_c.dll.
> >>> It's the annoyance of that c++ dll changing with every micro release.
> >>> Cause these are harder to predict and uninstall as part of an
> >>> install
> > process.
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Sandro Mani [mailto:manisan...@gmail.com]
> >>>> Sent: Tuesday, June 14, 2022 1:50 PM
> >>>> To: Regina Obe ; 'GEOS Development List'  >>>> de...@lists.osgeo.org>; roger.biv...@nhh.no
> >>>> Subject: Re: [geos-devel] mingw64 file libs changed
> >>>>
> >>>> Can you point me to the Makefile / ... which is doing this linking?
> >>>> It should never be necessary to point to a versioned shared library
> >>>> name in a link command line. Static libraries are unversioned, and
> >>>> for the dynamic libraries the corresponding import libraries are
> >>>> also
> >> unversioned.
> >>>>
> >>>> Sandro
> >>>>
> >>>> On 14.06.22 18:21, Regina Obe wrote:
> >>>>> In my case, I need the c++ library statically linked into the geos
> > C-api.
> >>>>> I need the geos c-API shared but not the c++ one.  The main reason
> >>>>> for need of c-api shared is all the extensions I ship rely on that.
> >>>>> So I don't want both statically linked.
> >>>>>
> >>>>> Also for regression testing I do want to replace the c-lib without
> >>>>> having to recompile all my extensions.
> >>>>>
> >>>>> Dan and strk had suggested a way to have the c++ be object .a so
> >>>>> it can be statically linked to the c lib.
> >>>>> I'm not sure how to do that in Cmake or if it is even currently
> > possible.
> >>>>>
> >>>>> So Sandro - my annoyance with your change is now I have this extra
> >>>>> c++ lib to worry about which was always a static name before and
> >>>>> c++ now
> >>>>> is changing with each micro release.
> >>>>>
> >>>>> Thanks,
> >>>>> Regina
> >>>>>
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On
> >>>>>> Behalf Of Sandro Mani
> >>>>>> Sent: Tuesday, June 14, 2022 8:00 AM
> >>>>>> To: roger.biv...@nhh.no; GEOS Development List  >

Re: [geos-devel] mingw64 file libs changed

[Regina Obe]

Now I see libgeos_c-1.dll and libgeos.dll.

It's different from 3.9 and 3.10, which had libgeos_c.dll for the c-api lib
file but I'm fine with that.  Just want to make sure you intended to keep
that change.

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 PM
> To: GEOS Development List 
> Cc: roger.biv...@nhh.no
> Subject: 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 code ends up having a dependency on libgeos_c-1.dll  (before
> > libgeos_c.dll) Which before linked to a unversioned libgeos.dll (this
> > libgeos.dll was always called that so could be cleanly removed and
> > replaced)
> >
> > I don't care about if the c dll is called libgeos_c-1.dll or
libgeos_c.dll.
> > It's the annoyance of that c++ dll changing with every micro release.
> > Cause these are harder to predict and uninstall as part of an install
process.
> >
> >
> >> -Original Message-
> >> From: Sandro Mani [mailto:manisan...@gmail.com]
> >> Sent: Tuesday, June 14, 2022 1:50 PM
> >> To: Regina Obe ; 'GEOS Development List'  >> de...@lists.osgeo.org>; roger.biv...@nhh.no
> >> Subject: Re: [geos-devel] mingw64 file libs changed
> >>
> >> Can you point me to the Makefile / ... which is doing this linking?
> >> It should never be necessary to point to a versioned shared library
> >> name in a link command line. Static libraries are unversioned, and
> >> for the dynamic libraries the corresponding import libraries are also
> unversioned.
> >>
> >> Sandro
> >>
> >> On 14.06.22 18:21, Regina Obe wrote:
> >>> In my case, I need the c++ library statically linked into the geos
C-api.
> >>> I need the geos c-API shared but not the c++ one.  The main reason
> >>> for need of c-api shared is all the extensions I ship rely on that.
> >>> So I don't want both statically linked.
> >>>
> >>> Also for regression testing I do want to replace the c-lib without
> >>> having to recompile all my extensions.
> >>>
> >>> Dan and strk had suggested a way to have the c++ be object .a so it
> >>> can be statically linked to the c lib.
> >>> I'm not sure how to do that in Cmake or if it is even currently
possible.
> >>>
> >>> So Sandro - my annoyance with your change is now I have this extra
> >>> c++ lib to worry about which was always a static name before and now
> >>> is changing with each micro release.
> >>>
> >>> Thanks,
> >>> Regina
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On
> >>>> Behalf Of Sandro Mani
> >>>> Sent: Tuesday, June 14, 2022 8:00 AM
> >>>> To: roger.biv...@nhh.no; GEOS Development List  >>>> de...@lists.osgeo.org>
> >>>> Subject: Re: [geos-devel] mingw64 file libs changed
> >>>>
> >>>> Just a note: library versioning only applies to shared libraries,
> >>>> static
> >>> libraries
> >>>> are unversioned. And FWIW, import libraries are also unversioned.
> >>>> So no
> >>> link
> >>>> command should be affected (unless you are linking against the dll
> >>>> shared library rather than the dll.a import library).
> >>>>
> >>>> Sandro
> >>>>
> >>>> On 14.06.22 12:59, Roger Bivand wrote:
> >>>>> In R >= 4.2, Windows static linked binary packages linking to GEOS
> >>>>> use MXE, locally updating the MXE use of GEOS 3.6.2 to 3.9.1:
> >>>>>
> >>>>> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/uc
> >>>>> rt
> >>>>> 3/
> >>>>> toolchain_libs/mxe/src/geos.mk
> >>>>>
> >>>>>
> >>>>> We currently hot-patch geos-config to modify it for static libs:
> >>>>>
> >>>>&g

Re: [geos-devel] mingw64 file libs changed

[Regina Obe]

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 code ends up having a dependency on libgeos_c-1.dll  (before 
libgeos_c.dll)
Which before linked to a unversioned libgeos.dll (this libgeos.dll was always 
called that so could be cleanly removed and replaced)

I don't care about if the c dll is called libgeos_c-1.dll or libgeos_c.dll.  
It's the annoyance of that c++ dll changing with every micro release.  
Cause these are harder to predict and uninstall as part of an install process.


> -Original Message-
> From: Sandro Mani [mailto:manisan...@gmail.com]
> Sent: Tuesday, June 14, 2022 1:50 PM
> To: Regina Obe ; 'GEOS Development List'  de...@lists.osgeo.org>; roger.biv...@nhh.no
> Subject: Re: [geos-devel] mingw64 file libs changed
> 
> Can you point me to the Makefile / ... which is doing this linking? It should
> never be necessary to point to a versioned shared library name in a link
> command line. Static libraries are unversioned, and for the dynamic libraries
> the corresponding import libraries are also unversioned.
> 
> Sandro
> 
> On 14.06.22 18:21, Regina Obe wrote:
> > In my case, I need the c++ library statically linked into the geos C-api.
> > I need the geos c-API shared but not the c++ one.  The main reason for
> > need of c-api shared is all the extensions I ship rely on that.
> > So I don't want both statically linked.
> >
> > Also for regression testing I do want to replace the c-lib without
> > having to recompile all my extensions.
> >
> > Dan and strk had suggested a way to have the c++ be object .a so it
> > can be statically linked to the c lib.
> > I'm not sure how to do that in Cmake or if it is even currently possible.
> >
> > So Sandro - my annoyance with your change is now I have this extra c++
> > lib to worry about which was always a static name before and now is
> > changing with each micro release.
> >
> > Thanks,
> > Regina
> >
> >
> >> -Original Message-
> >> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On
> >> Behalf Of Sandro Mani
> >> Sent: Tuesday, June 14, 2022 8:00 AM
> >> To: roger.biv...@nhh.no; GEOS Development List  >> de...@lists.osgeo.org>
> >> Subject: Re: [geos-devel] mingw64 file libs changed
> >>
> >> Just a note: library versioning only applies to shared libraries,
> >> static
> > libraries
> >> are unversioned. And FWIW, import libraries are also unversioned. So
> >> no
> > link
> >> command should be affected (unless you are linking against the dll
> >> shared library rather than the dll.a import library).
> >>
> >> Sandro
> >>
> >> On 14.06.22 12:59, Roger Bivand wrote:
> >>> In R >= 4.2, Windows static linked binary packages linking to GEOS
> >>> use MXE, locally updating the MXE use of GEOS 3.6.2 to 3.9.1:
> >>>
> >>> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt
> >>> 3/
> >>> toolchain_libs/mxe/src/geos.mk
> >>>
> >>>
> >>> We currently hot-patch geos-config to modify it for static libs:
> >>>
> >>> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt
> >>> 3/ toolchain_libs/mxe/src/geos-1-fixes.patch
> >>>
> >>>
> >>> We could hot-patch files in a GEOS >= 3.11.0 tarball to remove
> >>> instructions creating versioned libraries, but have not yet tested
> >>> RC1. R packages also need to list static linked libraries by name,
> >>> and revising each of a dozen or so at each GEOS release would be
> >>> error
> > prone.
> >>> Is a cmake option a way to satisfy both those needing versioned, or
> >>> unversioned library names?
> >>>
> >>> Does anyone else use MXE; if so, might it make sense to feed changes
> >>> in GEOS forward to MXE?
> >>>
> >>> Best wishes,
> >>>
> >>> Roger
> >>>
> >> ___
> >> geos-devel mailing list
> >> geos-devel@lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] mingw64 file libs changed

[Regina Obe]

Yap that works for me. 

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Tuesday, June 14, 2022 12:26 PM
> To: GEOS Development List 
> Cc: roger.biv...@nhh.no
> Subject: 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 DLL.
> But it's closer to what you were happy with before.
> ???
> P
> 
> > On Jun 14, 2022, at 9:21 AM, Regina Obe  wrote:
> >
> > In my case, I need the c++ library statically linked into the geos
C-api.
> > I need the geos c-API shared but not the c++ one.  The main reason for
> > need of c-api shared is all the extensions I ship rely on that.
> > So I don't want both statically linked.
> >
> > Also for regression testing I do want to replace the c-lib without
> > having to recompile all my extensions.
> >
> > Dan and strk had suggested a way to have the c++ be object .a so it
> > can be statically linked to the c lib.
> > I'm not sure how to do that in Cmake or if it is even currently
possible.
> >
> > So Sandro - my annoyance with your change is now I have this extra c++
> > lib to worry about which was always a static name before and now is
> > changing with each micro release.
> >
> > Thanks,
> > Regina
> >
> >
> >> -Original Message-
> >> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On
> >> Behalf Of Sandro Mani
> >> Sent: Tuesday, June 14, 2022 8:00 AM
> >> To: roger.biv...@nhh.no; GEOS Development List  >> de...@lists.osgeo.org>
> >> Subject: Re: [geos-devel] mingw64 file libs changed
> >>
> >> Just a note: library versioning only applies to shared libraries,
> >> static
> > libraries
> >> are unversioned. And FWIW, import libraries are also unversioned. So
> >> no
> > link
> >> command should be affected (unless you are linking against the dll
> >> shared library rather than the dll.a import library).
> >>
> >> Sandro
> >>
> >> On 14.06.22 12:59, Roger Bivand wrote:
> >>> In R >= 4.2, Windows static linked binary packages linking to GEOS
> >>> use MXE, locally updating the MXE use of GEOS 3.6.2 to 3.9.1:
> >>>
> >>> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt
> >>> 3/
> >>> toolchain_libs/mxe/src/geos.mk
> >>>
> >>>
> >>> We currently hot-patch geos-config to modify it for static libs:
> >>>
> >>> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt
> >>> 3/ toolchain_libs/mxe/src/geos-1-fixes.patch
> >>>
> >>>
> >>> We could hot-patch files in a GEOS >= 3.11.0 tarball to remove
> >>> instructions creating versioned libraries, but have not yet tested
> >>> RC1. R packages also need to list static linked libraries by name,
> >>> and revising each of a dozen or so at each GEOS release would be
> >>> error
> > prone.
> >>>
> >>> Is a cmake option a way to satisfy both those needing versioned, or
> >>> unversioned library names?
> >>>
> >>> Does anyone else use MXE; if so, might it make sense to feed changes
> >>> in GEOS forward to MXE?
> >>>
> >>> Best wishes,
> >>>
> >>> Roger
> >>>
> >> ___
> >> geos-devel mailing list
> >> geos-devel@lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/geos-devel
> >
> > ___
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] mingw64 file libs changed

[Regina Obe]

In my case, I need the c++ library statically linked into the geos C-api.
I need the geos c-API shared but not the c++ one.  The main reason for need
of c-api shared is all the extensions I ship rely on that.
So I don't want both statically linked.

Also for regression testing I do want to replace the c-lib without having to
recompile all my extensions.

Dan and strk had suggested a way to have the c++ be object .a so it can be
statically linked to the c lib.
I'm not sure how to do that in Cmake or if it is even currently possible.

So Sandro - my annoyance with your change is now I have this extra c++ lib
to worry about which was always a static name before and now is changing
with each micro release.

Thanks,
Regina


> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Sandro Mani
> Sent: Tuesday, June 14, 2022 8:00 AM
> To: roger.biv...@nhh.no; GEOS Development List  de...@lists.osgeo.org>
> Subject: Re: [geos-devel] mingw64 file libs changed
> 
> Just a note: library versioning only applies to shared libraries, static
libraries
> are unversioned. And FWIW, import libraries are also unversioned. So no
link
> command should be affected (unless you are linking against the dll shared
> library rather than the dll.a import library).
> 
> Sandro
> 
> On 14.06.22 12:59, Roger Bivand wrote:
> > In R >= 4.2, Windows static linked binary packages linking to GEOS use
> > MXE, locally updating the MXE use of GEOS 3.6.2 to 3.9.1:
> >
> > https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/
> > toolchain_libs/mxe/src/geos.mk
> >
> >
> > We currently hot-patch geos-config to modify it for static libs:
> >
> > https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/
> > toolchain_libs/mxe/src/geos-1-fixes.patch
> >
> >
> > We could hot-patch files in a GEOS >= 3.11.0 tarball to remove
> > instructions creating versioned libraries, but have not yet tested
> > RC1. R packages also need to list static linked libraries by name, and
> > revising each of a dozen or so at each GEOS release would be error
prone.
> >
> > Is a cmake option a way to satisfy both those needing versioned, or
> > unversioned library names?
> >
> > Does anyone else use MXE; if so, might it make sense to feed changes
> > in GEOS forward to MXE?
> >
> > Best wishes,
> >
> > Roger
> >
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] mingw64 file libs changed

[Regina Obe]

So what's your interest in mingw64?
Are you building mingw64 packages on Fedora?

The thing is libgeos_c.dll never changes (I'm fine with a c_1.dll for that) 
But the c++ api is unstable.
So why do I want this changing in every micro release when all that should be 
used is the C-API by packagers which is stable?



> -Original Message-
> From: Sandro Mani [mailto:manisan...@gmail.com]
> Sent: Monday, June 13, 2022 1:33 PM
> To: GEOS Development List ; Regina Obe
> 
> Subject: Re: [geos-devel] mingw64 file libs changed
> 
> Hi
> 
> I'm actually packaging for Fedora.
> 
> In short, autotools (and more recently, meson) both add suffixes to the
> shared library names with version number, cmake does not do so, but
> apparently just because no-one actually pursued it [1].
> 
> Why is it useful?
> 
> - Quickly picking out which packages need to be rebuild when a dependent
> package which carries an ABI incompatibilty is updated (i.e. dnf repoquery --
> whatrequires 'mingw64(libgeos_c-1.dll)'). This is *very* useful for packaging.
> - Actually even noticing when an ABI incompatibility arises. Packagers often
> spot ABI incompatibilities when the so version of a library is bumped. This
> clearly requires upstream to properly set and update the soversion.
> - For the same reason as above, versioned requires between packages
> - Potentially, allowing parallel versions without DLL name collisions
> 
> Thanks
> Sandro
> 
> 
> [1] https://gitlab.kitware.com/cmake/cmake/-/issues/21716
> 
> On 13.06.22 19:10, Regina Obe wrote:
> > Is there a way in CMake to make this an option.
> > I wouldn't want to inconvenience someone to satisfy me.
> > If I could have a switch I can turn on to get the old CMAKE behavior
> > I'd be very happy.
> >
> > My use case is different from Manisandro. He's probably packaging for
> > pacman.
> >
> > In my case, I can only ever have one geos version for each version of
> > PostgreSQL. Those all live in the respective PostgreSQL versioned
> > folders
> >
> > PostgreSQL/14/bin   , PostgreSQL/15/bin  ...
> >
> >
> >
> >> -Original Message-
> >> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On
> >> Behalf Of Paul Ramsey
> >> Sent: Monday, June 13, 2022 12:32 PM
> >> To: GEOS Development List 
> >> Subject: 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/927e442ab1da361d3f487e2b6
> >> 20a
> >>> 878dd1
> >>> 1f191d
> >>>
> >>> I'll have to live with it moving forward.
> >> I wouldn't say so necessarily. I took in a commit from someone with
> >> an opinion on MinGW (I had no opinion, so I took the commit) but the
> > discussion
> >> in GDAL shows other MinGW people with other opinions, and,
> >> importantly I think, the folks at CMake (who see a *lot* of build
> >> cases) have not chosen
> > to
> >> just slam in a file prefix on MinGW targets that have an SOVERSION
> >> set,
> > even
> >> though they do so on when generating outputs for other platforms.
> >>
> >> So I'd say it is very much up to you, as someone who has MinGW opinions.
> >>
> >> P
> >>
> >>
> >>> Thanks,
> >>> Regina
> >>>
> >>>> -Original Message-
> >>>> From: Regina Obe [mailto:l...@pcorp.us]
> >>>> Sent: Monday, June 13, 2022 12:01 PM
> >>>> To: 'GEOS Development List' 
> >>>> Subject: mingw64 file libs changed
> >>>>
> >>>> 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.  Why was this
> >>>> change made?
> >>>>
> >>>> The library files on mingw64 changed:
> >>>>
> >>>> For geos < 3.11 the files were
> >>>>
> >>>> libgeos.dll, libgeos_c.dll
> >>>>
> >>>>
> >>>> For geos 3.11 (including the just released 3.11.0beta1)
> >>>> libgeos_c-1.dll, libgeos-3.11.0.dll
> >>>
> >>> ___
> >>> geos-devel mailing list
> >>> geos-devel@lists.osgeo.org
> >>> https://lists.osgeo.org/mailman/listinfo/geos-devel
> >> ___
> >> geos-devel mailing list
> >> geos-devel@lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/geos-devel
> > ___
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] mingw64 file libs changed

[Regina Obe]

Is there a way in CMake to make this an option.
I wouldn't want to inconvenience someone to satisfy me.
If I could have a switch I can turn on to get the old CMAKE behavior I'd be
very happy.

My use case is different from Manisandro. He's probably packaging for
pacman.

In my case, I can only ever have one geos version for each version of
PostgreSQL. Those all live in the respective PostgreSQL versioned folders

PostgreSQL/14/bin   , PostgreSQL/15/bin  ...



> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Monday, June 13, 2022 12:32 PM
> To: GEOS Development List 
> Subject: 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/927e442ab1da361d3f487e2b6
> 20a
> > 878dd1
> > 1f191d
> >
> > I'll have to live with it moving forward.
> 
> I wouldn't say so necessarily. I took in a commit from someone with an
> opinion on MinGW (I had no opinion, so I took the commit) but the
discussion
> in GDAL shows other MinGW people with other opinions, and, importantly I
> think, the folks at CMake (who see a *lot* of build cases) have not chosen
to
> just slam in a file prefix on MinGW targets that have an SOVERSION set,
even
> though they do so on when generating outputs for other platforms.
> 
> So I'd say it is very much up to you, as someone who has MinGW opinions.
> 
> P
> 
> 
> >
> > Thanks,
> > Regina
> >
> >> -Original Message-
> >> From: Regina Obe [mailto:l...@pcorp.us]
> >> Sent: Monday, June 13, 2022 12:01 PM
> >> To: 'GEOS Development List' 
> >> Subject: mingw64 file libs changed
> >>
> >> 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.  Why was this
> >> change made?
> >>
> >> The library files on mingw64 changed:
> >>
> >> For geos < 3.11 the files were
> >>
> >> libgeos.dll, libgeos_c.dll
> >>
> >>
> >> For geos 3.11 (including the just released 3.11.0beta1)
> >> libgeos_c-1.dll, libgeos-3.11.0.dll
> >
> >
> > ___
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] mingw64 file libs changed

[Regina Obe]

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.

Thanks,
Regina

> -Original Message-
> From: Regina Obe [mailto:l...@pcorp.us]
> Sent: Monday, June 13, 2022 12:01 PM
> To: 'GEOS Development List' 
> Subject: mingw64 file libs changed
> 
> 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.  Why was this
> change made?
> 
> The library files on mingw64 changed:
> 
> For geos < 3.11 the files were
> 
> libgeos.dll, libgeos_c.dll
> 
> 
> For geos 3.11 (including the just released 3.11.0beta1) libgeos_c-1.dll,
> libgeos-3.11.0.dll


___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] mingw64 file libs changed

[Regina Obe]

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.  Why was this change
made?

The library files on mingw64 changed:

For geos < 3.11 the files were 

libgeos.dll, libgeos_c.dll


For geos 3.11 (including the just released 3.11.0beta1)
libgeos_c-1.dll, libgeos-3.11.0.dll


___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] DDISABLE_GEOS_INLINE

[Regina Obe]

None from me. 

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Thursday, June 9, 2022 3:10 PM
> To: GEOS Development List 
> Subject: [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@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.11.0beta1

[Regina Obe]

No objection from me.

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Monday, June 6, 2022 2:36 PM
> To: GEOS Development List 
> Subject: [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 mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Zero Copy Mafia

[Regina Obe]

> They are coming for us, they are in the ceiling, they are in the room wtih
us...
> 
> https://dewey.dunnington.ca/post/2022/building-bridges-arrow-parquet-and-
> geospatial-computing/
> 
> 
[Regina Obe] 
Yah I've been hearing a lot about GeoParquet in the last month or so.
I hadn't even heard about GeoParquet as a thing until recently

Of course you are partly to blame Paul :)  As you have been implicated in
that article with a link to your blog entry -
https://www.crunchydata.com/blog/parquet-and-postgres-in-the-data-lake



___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Stable Patch Releases

[Regina Obe]

> 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
[Regina Obe] 
+1

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Changes to the website and Github page

[Regina Obe]

Hearing no complaints I have reshuffled things as follows:

1) Created a new section - Communities (I called the folder community, not
sure how it became Communities)
2) Move the development, psc, and coc out of development into the community
folder
3) Renamed development.md to support.md
4) Linked to the support page from the home page.
5) Got rid of the Navigation header
6) Added community resources to the git README.md page.

Thanks,
Regina



> -Original Message-
> From: Regina Obe [mailto:l...@pcorp.us]
> Sent: Monday, February 21, 2022 1:20 PM
> To: 'GEOS Development List' 
> Subject: RE: [geos-devel] Changes to the website and Github page
> 
> > pdal.io, mapserver.org, gdal.org, and proj.org have a convention of
> > putting this stuff under a catch-all "Community" landing page. That
> > way it was a little more obvious it was a section about how to connect
> > or communicate with the project and could include more stuff than just a
> link to the mailing list.
> > One possible way to go about it.
> >
> > Howard
> >
> [Regina Obe]
> 
> This whole page should actually be called community
> 
> It's all about interacting with the community and a little about GEOS
> governance
> 
> https://libgeos.org/development/
> 
> So perhaps the best thing to do is, as you said, rename this page
community.
> Put it as a link directly on the home page - something like
> 
> If you need support or want to get involved, checkout our "Community and
> Support" page with link to the renamed page.
> 
> 
> And also add it to the side bar as a standalone  Community link.
> 
> I don't know how others feel about the header "Navigation", but I'd really
> like to get rid of it.
> Everytime I look at the word "Navigation"  I feel like it's a big use of
real
> estate to tell me the obvious.
> 
> Thanks,
> Regina

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Changes to the website and Github page

[Regina Obe]

> pdal.io, mapserver.org, gdal.org, and proj.org have a convention of
putting
> this stuff under a catch-all "Community" landing page. That way it was a
little
> more obvious it was a section about how to connect or communicate with
> the project and could include more stuff than just a link to the mailing
list.
> One possible way to go about it.
> 
> Howard
> 
[Regina Obe] 

This whole page should actually be called community 

It's all about interacting with the community and a little about GEOS
governance

https://libgeos.org/development/

So perhaps the best thing to do is, as you said, rename this page community.
Put it as a link directly on the home page - something like

If you need support or want to get involved, checkout our "Community and
Support" page with link to the renamed page.


And also add it to the side bar as a standalone  Community link.

I don't know how others feel about the header "Navigation", but I'd really
like to get rid of it.
Everytime I look at the word "Navigation"  I feel like it's a big use of
real estate to tell me the obvious.

Thanks,
Regina

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] Changes to the website and Github page

[Regina Obe]

Well touching the homepage and closing a ticket, I could not find where we
tell people how to get support from the project.

It wasn't on the home page -  https://libgeos.org/

But instead was buried in the Development header -

https://libgeos.org/development/


Can I move the geos chat / matrix /irc /slack links to the home page
Or have a support link for this

It's not intuitive that headers are even clickable since for example
"Development" header is clickable, but "News" header is not.

Also I would expect this channel/mailing list information to be repeated on
the readme here:

https://github.com/libgeos/geos

Where I assume where a good chunk of people first discover GEOS.

Anyone have issue with me making these changes?

Thanks,
Regina

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

+1 let's just copy it.

Thanks,
Regina

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Wednesday, February 16, 2022 11:46 AM
> To: GEOS Development List 
> Subject: 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 I'd like to see the GEOS project adopt a code of
> conduct. Sponsors look for one these days, right? It's probably a good
move
> for GEOS in the long run.
> >
> > On Tue, Feb 15, 2022 at 8:37 AM Howard Butler 
> wrote:
> > GDAL PSC,
> >
> > When we wrote the GDAL RFCs on sponsorship, we provided an escape
> clause to allow us to direct resources to other projects upon which GDAL
> depends. Our sponsorship numbers are still increasing, which provides us
an
> opportunity to directly support some of those projects, and one of them is
> obviously GEOS. GEOS provides all of the geometry algebra support for
> GDAL/OGR and many other open source geospatial softwares including
> Shapely, PostGIS, GeoPandas, MapServer, and more.
> >
> > Dan Baston of the GEOS PSC has been identified as the developer with
> capacity and interest in the next year to take on GEOS development on APIs
> and performance, which he has a long history of doing for the project.
This
> support should allow him to work longer, multi-release upgrades that will
> provide strong performance and convenience benefits for the project.
> >
> > I motion to provide the GEOS PSC with a $50,000 USD grant to address
> performance, API, and other work that does not attract directed funding in
> GEOS. The GEOS PSC will be responsible for coordinating work tasks, rates,
> and development timelines. Howard Butler or Even Rouault of the GDAL
> NumFocus liaison team will coordinate dispersement as directed by the
> GEOS PSC and NumFocus rules.
> >
> > Thank you again to the GDAL Sponsors
> https://gdal.org/sponsors/index.html who have made this kind of grant
> possible. A better GEOS makes for a better GDAL.
> >
> > Howard
> >
> >
> > --
> > Sean Gillies
> > ___
> > gdal-dev mailing list
> > gdal-...@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] GEOS Maintenance Grant

[Regina Obe]

GEOS PSC +1

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Howard Butler
> Sent: Tuesday, February 15, 2022 10:38 AM
> To: gdal dev 
> Cc: GEOS Development List 
> Subject: [geos-devel] GEOS Maintenance Grant
> 
> GDAL PSC,
> 
> When we wrote the GDAL RFCs on sponsorship, we provided an escape
> clause to allow us to direct resources to other projects upon which GDAL
> depends. Our sponsorship numbers are still increasing, which provides us
an
> opportunity to directly support some of those projects, and one of them is
> obviously GEOS. GEOS provides all of the geometry algebra support for
> GDAL/OGR and many other open source geospatial softwares including
> Shapely, PostGIS, GeoPandas, MapServer, and more.
> 
> Dan Baston of the GEOS PSC has been identified as the developer with
> capacity and interest in the next year to take on GEOS development on APIs
> and performance, which he has a long history of doing for the project.
This
> support should allow him to work longer, multi-release upgrades that will
> provide strong performance and convenience benefits for the project.
> 
> I motion to provide the GEOS PSC with a $50,000 USD grant to address
> performance, API, and other work that does not attract directed funding in
> GEOS. The GEOS PSC will be responsible for coordinating work tasks, rates,
> and development timelines. Howard Butler or Even Rouault of the GDAL
> NumFocus liaison team will coordinate dispersement as directed by the
> GEOS PSC and NumFocus rules.
> 
> Thank you again to the GDAL Sponsors https://gdal.org/sponsors/index.html
> who have made this kind of grant possible. A better GEOS makes for a
better
> GDAL.
> 
> Howard
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.10.2 release

[Regina Obe]

+1

Let's roll.

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Thursday, January 13, 2022 7:55 PM
> To: GEOS Development List 
> Subject: [geos-devel] 3.10.2 release
> 
> I should roll a new patch release, any objections? Will do it either
tomorrow
> or over the weekend.
> 
> P
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Killing Slack room ?

[Regina Obe]

> > On Jan 5, 2022, at 9:57 AM, Sandro Santilli  wrote:
> >
> > After upgrading the Matrix room versino from 1 to 9 we lost the Slack
> > bridge, and it I'm having trouble adding it back (glitches).
> >
> > Does anyone have problems with just removing references to that room
> > from the website ( http://libgeos.org/development/ ) and only keeping
> > the Matrix room ( https://matrix.to/#/#geos:osgeo.org ) ?
> 
> Well if it's never going to work or whatnot, I guess, but surprise, I'd
rather
> use the osgeo slack and deprecate the matrix.
> 
> P.
> 
[Regina Obe] 
We have the same issue with PostGIS by the way.
I prefer matrix.  That said, I think there is a way to keep slack going and
understand many people prefer it so we should probably keep it.

But it does take I think someone to resetup the bridge.  I have no idea what
that entails.


Thanks,
Regina



___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Example?

[Regina Obe]

+1 for simple STRTree example and if you want the http -- put in a separate 
repo.
Adding http examples into GEOS just feels like getting into too many waters.

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Wednesday, December 15, 2021 5:15 PM
> To: GEOS Development List 
> Subject: Re: [geos-devel] Example?
> 
> I did consider just packaging up the classes without the http service, but 
> that felt
> like less fun, though just as illustrative.
> 
> I should perhaps just do a simple STRtree C++ example.
> 
> P
> 
> > On Dec 15, 2021, at 2:10 PM, Darafei Kom?pa Praliaskouski
>  wrote:
> >
> > OSRM "library" had an "example" app that in the end they had to start
> supporting (patch security, scalability etc) and it is known as osrm-backend 
> by
> everyone now.
> >
> > I'd say if you don't want http CVEs in GEOS at least put it not into same 
> > tarball.
> >
> > ??, 16 ??? 2021, 01:03  Paul Ramsey
>  ???:
> > Is this a stupid example to add in the tree? It's kind of large, but it 
> > shows off a
> bunch of important things working together.
> >
> > https://github.com/pramsey/geos/tree/main-reverse-
> geocode/examples/lookup
> >
> > P
> > ___
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
> > ___
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0

[Regina Obe]

> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Monday, December 6, 2021 8:41 PM
> To: GEOS Development List 
> Subject: Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS
> 3.9.0
> 
> Semi worthless data point on this, but I did want to verify that
everything still
> worked at least for me, so I built against GEOS 3.6 and then swapped in
> everything from 3.6 to main at runtime, and it all worked fine.
> 
> P
[Regina Obe] 
What are your libraries called? Did the names stay the same? 

In case you got lost in my long rant.

Greg suggested looking at ldd and ldd showed the culprit.
I suspect it might just be a windows issue, possibly even  mingw64 cmake
issue.

The issue is the file names changed in my cmake builds between 3.10.0 to
3.10.1

So my 3.10.0 build had these files (and all versions I have built, including
GEOS 3.6 have had these names). 
The fact they never changed made me happy (and I kept my mouth shut at the
beauty of this bug).

c-api => libgeos_c.dll
c++ api ->  libgeos.dll

and from 3.10.1 forward, my files look like yuck:
c-api => libgeos_c-1.dll
c++ api -> libgeos-3.10.1.dll

One can rightfully argue, that the old 3.10.0 behavior was a bug (I call it
feature or a beautiful bug :) )
And that 3.10.1 is the proper way to version since the c++ abi is 
unstable it should be changing in each micro-release.

I'm just a bit irritated this changed happened in a micro-release.
Not a huge deal.

Thanks,
Regina




___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0

[Regina Obe]

>> I know it probably sucks for most people, but for me it was great, cause
it
>> meant I don't have to deal with removing those
>> Old 3.10.0, 3.9.0 etc when I build installers.

> I would expect some packaging system that would remove them at
> uninstall/replace time.

My installer does remove them at uninstall time.
The issue is people rarely uninstall, they just install new versions of
PostGIS
Which happen to need to be looking for the same compatible version of GEOS.
So these versioned dlls that are not needed just keep piling up.
Cause next install libgeos_c-1.dll will be tied to libgeos-3.10.1.dll
instead of libgeos-3.9.0.dll.

I'm okay with having a libgeos_c-1.dll and yes with mindset there might be a
libgeos_c-2.dll
I can live with that versioning.  It's this extra C++ baggage I don't need.

But my packaging of GEOS is a special case packaging.  
Its purpose is to just be used by PostGIS for a specific version of
PostgreSQL and include all the
dependencies that PostGIS needs to live that are not already shipped by EDB
(windows PostgreSQL installer).


>> Generally on windows people
>> have a habit of installing multiple versions of 
>> PostGIS in the same PostgreSQL instance, but they all have to share the
same
>> GEOS.  

> I had not idea that could be done, and surely they must have
> non-overlapping names?

They don't need non-overlapping names, cause they are installed in separate
folders.

If someone has 3 versions of PostgreSQL installed, then they have 3 installs
of geos all in the PostgreSQL system folder for that version.
e.g c:\program files\PostgreSQL\14\bin,  c:\program files\PostgreSQL\13\bin
and so on
 (cause it's not installed in system).  So in theory  each PostgreSQL
version can have a different version of geos.
However all versions of PostGIS installed in a specific PostgreSQL install
share the same geos regardless
So installing PostGIS 3.1 would upgrade your GEOS that was installed by
PostGIS 3.0 and so on.
Cause they'd all be in theory pointing at the one and only libgeos_c-1.dll
in the PostgreSQL//bin folder.


>>  I would love to just statically link those two together and have just
one
>> library to contend with.

> As soon as you do that it get really iffy about claiming new geos
> versions do not have an ABI change.  Part of the point is that the C++
> interface is not available to client programs.

> And, that would seem to be a workaround for confusion within Windows
> about shared library naming.

I don't think there is a confusion here, just don't like seeing yet another
library file :)
Windows points at the libgeos-3.10.1 whatever longish versioned names. 
Like I said though my use case is a little different, it's very isolated
from rest of windows environment.
So this extra junk (I know you and strk think it's not) is a nuisance.
I can see how it's useful in a system shared environment.  
Not so much when the environment is very isolated from the system.


> I wonder if someone can explain how windows dll versioning is supposed
> to work?   I don't understand it (and I bet strk doesn't either).
Do you really want to understand it?  Strk doesn't.
I think within a 2-3 year span, windows will morph into some forkish version
of Debian/Ubuntu
and then all that knowledge will not be that useful anyway.

I agree with you the new way is saner, just a little more inconvenient. 

So I guess nothing to fix.  The old way was broken in a way I considered a
"feature".
The new way is a saner solution but not as pleasant from where I am
standing.

Thanks for the help and thoughts and listening to my rants,
Regina

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0

[Regina Obe]

> This is probably my lack of windows knowledge, but is the postgis build
> somehow configured to find the needed shared libraries by looking in
> PATH?   On POSIXy systems, the libraries are looked for in DT_RPATH (or
> RUNPATH, a minor complication not that important).  E.g. objdump -x on
> /usr/pkg/bin/shp2pgsql has this output:
> 
[Regina Obe] 
It looks in the directory of the dependent executable first for dependencies
and then looks in PATH for what it couldn't find in the direct path.
I use the same trick (except export and $ signs)  on Debbie and Berrie (both
Debian bots) and it works there too just overriding the 
PATH

Here is what Berrie64 build script looks like for example:
https://git.osgeo.org/gitea/postgis/postgis/src/branch/master/ci/berrie64/co
nfigs.sh  #configuration where I flip the GEOS as needed
https://git.osgeo.org/gitea/postgis/postgis/src/branch/master/ci/berrie64/pg
_init_start.sh #postgresql startup script

Though I think I had to set the LD_LIBRAY_PATH for building otherwise it
would pick up the system installed GEOS and PostgreSQL  instead of my custom
compiled one.

> so postgis ends up with libgeos.so, but doesn't have a textual reference
> so replacing geos should still work.   I am not finding anything that
> has a direct reference to libgeos, but I remember that happening, and
there are
> notes in pkgsrc about it.  However it does not seeem to be happening any
more.
> >> Well, your real problem is that you are using windows!
> >>
> > [Regina Obe]
> > Is your other name Sandro.  I might not be able to tell you apart
> > anymore :)
> 
> Actually we've never met, but great minds think alike!
> 
> > You solved the problem :)
> >
> > Ldd Shows this:
> > ldd /projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll
> > :
> > ucrtbase.dll => /c/Windows/System32/ucrtbase.dll
(0x7ff966af)
> > libgeos_c.dll => not found
> > :
> >
> > and I see the newer GEOS from 3.10.1 on  have the file called
> > libgeos_c-1.dll copying libgeos_c-1.dll back to the original name of
> > libgeos_c.dll fixed the issue.
> 
> Well that seems messed up.   Renaming the library changes the ABI.
> 
> 
> > I also notice I am back to having this ugly libgeos-3.10.1.dll that I
> > was so happy to get rid of when I had switched my geos building from
> > autotools to CMake years ago.
> 
> Changing to an alternative build system should not result in an ABI
change, and
> if so, one of the build systems is buggy.
> 
> > In GEOS 3.10.0 the c++ one was called:  libgeos_c-1.dll Why is this
> > ugly creature back?
> 
> But you just said that was the name of the C library in 3.10.1.
> 
[Regina Obe] 
All of these were compiled with CMake.  I haven't used libtool on GEOS since
3.6 or so..
In GEOS 3.10.0 (and all cmake versions previous) -- the files in bin folder
are just the way I like them:
geos-config  geosop.exe  libgeos.dll  libgeos_c.dll

and ldd of libgeos_c.dll looks like:
ldd /projects/geos/rel-3.10.0w64gcc81/bin/libgeos_c.dll
ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff968c3)
KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff967c1)
KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll
(0x7ff9663f)
msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ff968a7)
libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x6144)
libgeos.dll => /projects/geos/rel-3.10.0w64gcc81/bin/libgeos.dll
(0x64c4)
libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc4)
libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x6494)
USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ff967a6)
win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ff96677)
GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ff966dd)
gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ff96695)
msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ff96635)
ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ff966af)
IMM32.DLL => /c/WINDOWS/System32/IMM32.DLL (0x7ff96756)


In GEOS 3.10.1 (where things started sucking as far as file names go)
geos-config  geosop.exe  libgeos-3.10.1.dll  libgeos_c-1.dll  
(I do recall my libtool builds having the full name at least for the c++
part and that libgeos_c-1.dll that is why I assumed it was to congeal the
two systems). 
$ ldd /projects/geos/rel-3.10.1w64gcc81/bin/libgeos_c-1.dll
ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff968c3)
KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff967c1)
KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll
(0x7ff9663f)
msvcrt.dll => /c/WINDOWS/Sy

Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0

[Regina Obe]

> > So my PostGIS is compiled with GEOS 3.9.0, but it should work with
> > GEOS 3.11.
> 
> You presumably have swapped out the geos implementation?  How?
> 
[Regina Obe] 
I test PostGIS / PostgreSQL with a PostgreSQL launch script that sets the
path of all the key dependencies.
So I have a compiled (lots of other old geos) , GEOS 3.9.0, GEOS 3.10.0,
GEOS 3.10.1, GEOS 3.11 (main) all just different in bin path by the version.

So when I want to compare differences I compile PostGIS with the lowest
version I want to compare
And then switch the paths in my PG launch script and then start up
PostgreSQL again.

Ignore the windowishness of this script, pretend you see export and $ signs
instead
-- START SCRIPT --
SET OS_BUILD=64
SET GCC_TYPE=gcc81
SET MINGW=C:\ming%OS_BUILD%%GCC_TYPE%\mingw%OS_BUILD%
SET PROJECTS=C:\ming%OS_BUILD%%GCC_TYPE%\projects
SET GDAL_VER=3.3.3
#I change this
SET GEOS_VER=3.10.1
SET PGDATA=%~dp0\data
SET PGDATABASE=postgres
SET PGUSER=postgres
SET PGPORT=5451
: lots of other dependencies cut out to keep this shorter
@SET
PATH=%PROJECTS%\zlib\rel-zlib-%ZLIB_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%
\CGAL\rel-cgal-%CGAL_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\cgal\rel-sfcga
l-%SFCGAL_VER%w%OS_BUILD%%GCC_TYPE%\bin;%MINGW%\bin;%~dp0bin;%PROJECTS%\gdal
\rel-%GDAL_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\geos\rel-%GEOS_VER%w%OS_
BUILD%%GCC_TYPE%\bin;%PROJECTS%\rel-libiconv-%ICONV_VER%w%OS_BUILD%%GCC_TYPE
%\bin;%PROJECTS%\proj\rel-%PROJ_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\lib
xml\rel-libxml2-%LIBXML_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\curl\rel-cu
rl-%CURL_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\expat\rel-expat-%EXPAT_VER
%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\freexl\rel-freexl-%FREEXL_VER%w%OS_BUI
LD%%GCC_TYPE%\bin;%PROJECTS%\v8\%V8_VER%;%PROJECTS%\ssl\rel-openssl-%OPENSSL
_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\sqlite\rel-sqlite%SQLite_VER%w%OS_
BUILD%%GCC_TYPE%\bin;%PROJECTS%\protobuf\rel-%PROTOBUF_VER%w%OS_BUILD%%GCC_T
YPE%\bin;%PROJECTS%\pcre\rel-%PCRE_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\
lz4\rel-lz4-%LZ4_VER%w%OS_BUILD%%GCC_TYPE%\bin;%~dp0\bin

"%~dp0\bin\initdb" -E UTF8 -U postgres -A trust
"%~dp0\bin\pg_ctl" -D "%~dp0/data" -l logfile_%PGPORT% start

ECHO "Click enter to stop"
pause
"%~dp0\bin\pg_ctl" -D "%~dp0/data" stop -m fast
-- END SCRIPT --

> > ERROR:  could not load library
> >
"C:/ming64gcc81/projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll":
> > The specified module could not be found.
> 
> Well, your real problem is that you are using windows!
> 
[Regina Obe]  
Is your other name Sandro.  I might not be able to tell you apart anymore :)

> That error doesn't show what couldn't be found, and I'd suggest the
equivalent
> of objdump and ldd.
> 
> But seriously, that doesn't sound right.
> 
> One issue is that the c library has a (on POSIX) DT_NEEDED for the C++,
and
> sometimes (libtool?) when building a program that links with libgeos_c,
the
> libraries that libgeos_c depend on are also added at DT_NEEDED to the
> program.
[Regina Obe] 
You solved the problem :)

Ldd Shows this:
ldd /projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll
:
ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7ff966af)
libgeos_c.dll => not found
:

and I see the newer GEOS from 3.10.1 on  have the file called
libgeos_c-1.dll
copying libgeos_c-1.dll back to the original name of libgeos_c.dll 
fixed the issue.

I also notice I am back to having this ugly libgeos-3.10.1.dll
that I was so happy to get rid of when I had switched my geos building from
autotools to CMake years ago.
In GEOS 3.10.0 the c++ one was called:  libgeos_c-1.dll
Why is this ugly creature back?

If it was to congeal the libtool / CMake worlds I guess I can learn to live
with this ugliness.

Thanks,
Regina



___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0

[Regina Obe]

I was always under the assumption that the C-API should be upward compatible
(only the C++ API is unstable).

Normally  I can do the following:

Compile PostGIS with GEOS say 3.9.0

Launch my PostgreSQL with GEOS 3.9.0

Then launch again with newer GEOS - in this case GEOS 3.11.

So my PostGIS is compiled with GEOS 3.9.0, but it should work with GEOS
3.11.

What I am finding is it is not.  I thought maybe I had the paths wrong so I
double-checked a couple of times.

This is what I get when I swap out the older GEOS 3.9.0 with newer GEOS 3.11
(main branch)

And then run any PostGIS function.

ERROR:  could not load library
"C:/ming64gcc81/projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll":
The specified module could not be found.

I then tried to swap with GEOS 3.10.0  and that worked okay.
POSTGIS="3.2.0dev 3.2.0beta3-2-g0b32bdd14" [EXTENSION] PGSQL="140"
GEOS="3.10.0-CAPI-1.16.0" PROJ="7.2.1" GDAL="GDAL 3.3.3, released
2021/10/25" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0
(Internal)" TOPOLOGY RASTER

GEOS 3.10.1 - errors
ERROR:  could not load library
"C:/ming64gcc81/projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll":
The specified module could not be found.

Can someone confirm that?  If it's just an issue with PostGIS 3.2, I guess
that is okay, though I would think it would mean just the newer features
like MakeValid would not be enabled by swapping out with a newer GEOS, but
it shouldn't break install.  Also why GEOS 3.10.0 works and GEOS 3.10.1
doesn't is very concerning.

FWIW:  all were built under CMake.  Though I think the ENABLE_INLINE
whatever that CMAKE switch is might be different between the working and
non-working versions.

Thanks,
Regina

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Issue references in git history

[Regina Obe]

> For GitHub it will still be a problem. How can we solve that ?
> According to
> https://docs.github.com/en/github/writing-on-github/working-with-
> advanced-formatting/autolinked-references-and-urls
> GitHub also understands the `GH-xxx` syntax to refer to GitHub
issues/pull-
> requests, did anyone test this ? Could a policy be to use these different
> syntax to refer to GitHub ?
> 
> --strk;
> 
>   Libre GIS consultant/developer
>   https://strk.kbt.io/services.html
[Regina Obe] 

I'm all for prefixing the new tickets with GH-
That will also solve the convergence issue of new GH tickets having the old
numbers of old trac tickets.

Does Gitlab and Gitea have a mechanism to make sense of GH-xxx?

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] RFC 10 (Move to GitHub) Next Steps

[Regina Obe]

#2) The  osgeo website (that is probably why google is ranking
geos.osgeo.org so highly)

https://www.osgeo.org/projects/geos/

Need to change visit website link to libgeos.org

> -Original Message-
> From: Regina Obe [mailto:l...@pcorp.us]
> Sent: Tuesday, November 9, 2021 4:31 PM
> To: 'GEOS Development List' 
> Subject: RE: [geos-devel] RFC 10 (Move to GitHub) Next Steps
> 
> > Wherewith a set of steps to take on the way to completing RFC10
> >
> > - Ensure all current committers are part of a new committer group on
> > github
> > - Turn off replication osgeo->github. Document new canonical location
> > in all places one can find (trac, website, etc)
> > - Complete migration of all current and useful content from the wiki
> > into the web site.
> > - Delete wiki content and replace front page with reference to new web
> > site location (libgeos.org)
> > - Set trac to read-only
> > - Scrape trac contents for posterity
> >
> > Anything I am missing here?
> [Regina Obe]
> I think the only thing missing on your list is:
> 
> 302 Redirect geos.osgeo.org -> libgeos.org It's the first entry that comes
up for
> me in websearch (google) when I type  "geos" so I think it's important to
> redirect (weird that google doesn't think trac is important) On bing -
it's
> trac.osgeo.org/geos (so guess we are set there) On duckduckgo -- (first
GEOS
> related link is trac.osgeo.org/geos)
> 
> 
> I think the only thing that were on geos.osgeo.org was:
> 1)  a the redirect to trac (no longer needed)
> 2) doxygen (now on libgeos.org)
> 3) 7 day daily snapshots -- which we can probably do without
> 
> 
> Thanks,
> Regina
> 


___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] RFC 10 (Move to GitHub) Next Steps

[Regina Obe]

> Wherewith a set of steps to take on the way to completing RFC10
> 
> - Ensure all current committers are part of a new committer group on
github
> - Turn off replication osgeo->github. Document new canonical location in
all
> places one can find (trac, website, etc)
> - Complete migration of all current and useful content from the wiki into
the
> web site.
> - Delete wiki content and replace front page with reference to new web
site
> location (libgeos.org)
> - Set trac to read-only
> - Scrape trac contents for posterity
> 
> Anything I am missing here?
[Regina Obe] 
I think the only thing missing on your list is:

302 Redirect geos.osgeo.org -> libgeos.org
It's the first entry that comes up for me in websearch (google) when I type
"geos" so I think it's important to redirect (weird that google doesn't
think trac is important)
On bing - it's trac.osgeo.org/geos (so guess we are set there)
On duckduckgo -- (first GEOS related link is trac.osgeo.org/geos)


I think the only thing that were on geos.osgeo.org was:
1)  a the redirect to trac (no longer needed)
2) doxygen (now on libgeos.org)
3) 7 day daily snapshots -- which we can probably do without


Thanks,
Regina



___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

> On Fri, Oct 29, 2021 at 12:13:19PM -0700, Paul Ramsey wrote:
> > http://libgeos.org/development/rfcs/rfc10/
> 
> That's a 404 for me.
> 
[Regina Obe] 
It will come back once pramsey has reset the config.  It's really because 
gh-pages is a branch of our core github branch
and that is not mirrored.  This problem will be solved once GEOS moves to 
Github.


> > GitHub has been the largest source of 3rd party code contribution via pull-
> requests for some time now.
> >
[Regina Obe] Yes it has, and we aren't going to get any more contributors than 
we have already because
a) We already have issues allowed to be made on Github. 
 One thing I would never agree to for PostGIS cause it just opens the flood 
gets for rando people to complain about how some piece doesn't work for them 
(whether it's packaging, I can't install, please help me do this, blah blah),
 because it's too much work to join a mailing list and complain there.

The other reason -- I like that when I do a google search for a bug the first 
entry that comes up has osgeo.org or postgis.net on it.
If PostGIS moved to github I'd get github.org/postgis which would just annoy me 
as hell "Why am I freely giving extra SEO juice to github"

b) We already accept pull requests

To the random contributor nothing has changed aside from we will only accept 
pull requests from Github.
But all contributors who we care about getting pull requests from already have 
an account on github so nothing lost here.
> >
> >   Easier path for new contributors to discover and assist with the
> > project

> > Moving to Github has the following components:
> >
> >   Move the canonical (writeable) repository to GitHub
> >   Migrate the (current, useful) contents of the Trac wiki to the new
> > web framework
> 
[Regina Obe] 
It won't be a wiki anymore, but it will be part of the core website, which 
honestly I do think is better.
So I'm fine with this.

> Meaning it would not be a wiki anymore ?
> 
> >   Deleting the migrated and out-of-date contents of the Trac wiki
> >   Switching the Trac tickets to read-only
> >   Web scraping the Trac ticket contents and placing in a
> > geos-old-tickets repo At that point:
> >
[Regina Obe] 
I honestly don't even know why this is even worth the effort.  Sounds like a 
lot of busy work.
Having an geos-old-tickets I think would just cause confusion.  You really 
should just start from scratch and copy over anything you think worthy of 
copying over.  If no one bothers to copy it over then it really wasn't that 
important.

> More dependence on single corporation being the only one which can do
> work on the infrastructure. Anyone can be a contributor on OSGeo
> infrastructure so "only they can do" is a misleading picture, as if "they" 
> would
> not be all of us...
> 
[Regina Obe] 
I'm fine with this.  I think Microsoft is a great steward and will be as long 
as there is marketing pressure for them to be.

That said -- I do worry a lot about the massive migration to Github.  
My main reason for worry (call it me being paranoid), is that eventually all 
open source projects will be forced to move to Github.
This means less pressure on Microsoft to be good, cause hey you have no choices.
This means people forgetting how to run their own infra, so you have no choices 
etc.
No need to work on making things like gitea or gitlab better, cause everyone is 
using Github anyway.

So everytime I hear "everyone is over here, follow us to the promised land", I 
loose my lunch.


> I'll only vote after reading the full RFC as I'd like to understand what the 
> new
> management would look like. A feature I often use is marking Trac tickets as
> blockers for a milestone (we only release when all important issues are
> released), I'd like to understand how would this work on github.
> 
> --strk;
> 
[Regina Obe] 
Despite all my reservations, I'm still a -0 

Because though I disagree I know I don't do much work on GEOS so I don't want 
my vote to count
and it's the easiest way for Paul and the other core contributors to work.

The decision should be left up to the doers.



___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] (Fewer) CI Tables

[Regina Obe]

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Monday, November 1, 2021 2:40 PM
> To: GEOS Development List 
> Subject: [geos-devel] (Fewer) CI Tables
> 
> We've got big master CI tables on the trac, in the web site (that
duplication will
> go away with RFC 10) and also in all the branch README files.
> 
> I'd like to propose stripping the README badges just down to the branch of
> interest (so main would have main badges only, 3.10 would have 3.10 badges
> only, etc), and keeping just the one master table in the web site. Seems
silly to
> have a big master CI table in 3.9 that includes 3.8, 3.7, etc.
> 
> P.
[Regina Obe] 
+1

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.9.2 Release?

[Regina Obe]

> Paul Ramsey
> Sent: Friday, October 29, 2021 9:43 PM
> To: GEOS Development List 
> Subject: [geos-devel] 3.9.2 Release?
> 
> 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
> 
> 
[Regina Obe]  +1

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Friday, October 29, 2021 3:13 PM
> To: GEOS Development List 
> Subject: [geos-devel] GEOS RFC 10 - Move Project to GitHub
> 
> 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 canonical (writeable) repository to GitHub
> Migrate the (current, useful) contents of the Trac wiki to the new
> web framework
> Deleting the migrated and out-of-date contents of the Trac wiki
> Switching the Trac tickets to read-only
> Web scraping the Trac ticket contents and placing in a geos-old-
> tickets repo At that point:
> 
> New code is pushed to GitHub
> New issues are filed at GitHub
> New documentation is committed to the repository This should
> unlock:
> 
> Easier path for new contributors to discover and assist with the
> project
> Easier collaboration with downstream projects
> Far easier story on  how to we manage the project  and  where the
> important things happen
> Far less dependence on individual contributors for infrastructure
> work that only they can do
> 
[Regina Obe] 

-0

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] NEWS.md

[Regina Obe]

I'm fine with it.

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Tuesday, October 26, 2021 10:40 AM
> To: GEOS Development List 
> Subject: [geos-devel] NEWS.md
> 
> Anyone have a strong objection to this?
> 
> https://github.com/libgeos/geos/pull/491
> 
> Ordinarily I'd probably just accept, but .md seems like one of those
things that
> sometimes stirs deep feelings.
> 
> P
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.10.0 Release Vote

[Regina Obe]

+1

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of 
Daniel Baston
Sent: Monday, October 18, 2021 6:20 PM
To: GEOS Development List 
Subject: Re: [geos-devel] 3.10.0 Release Vote

 

+1

 

On Mon, Oct 18, 2021 at 4:34 PM Paul Ramsey mailto:pram...@cleverelephant.ca> > 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
geos-devel@lists.osgeo.org  
https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.10.0rc2

[Regina Obe]

> Just for the record, the increased CMake version requirement is not met on
> Ubuntu bionic.
> 
>  https://launchpad.net/ubuntu/+source/cmake
> 
> Only focal will be able to have geos backports via the UbuntuGIS PPA.
> 
> Kind Regards,
> 
> Bas
> 
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
[Regina Obe] 
Okay that sucks :(
Looking at the story on debian
Bullseye (11) appears to be at 3.18.4 (fine)
Buster  (10) 3.13.4  (barely good enough)
Stretch already doesn't have the minimum so guess we don't care

Still though I feel few people will try to be compiling geos on older
platforms so still think it's worth the cmake version upgrade. 

Thanks,
Regina

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.10.0rc1 (static)

[Regina Obe]

> 
> Paul Ramsey  writes:
> 
> > OK, this is coming directly out of
> > https://trac.osgeo.org/geos/ticket/1103
> >
> > If I go back to using an "OBJECT" library in building ryu, then it
> > gets bundled right up into libgeos.a where we want it, and your link
> > line is nice and simple again. That implies a minimum cmake of 3.13,
> > whcih is 3+ years old now. My macports gives me 3.21 by default. I
> > dunno, we backed out of the OBJECT library to STATIC to keep the cmake
> > requirement low, but that implies generating two static libs and
> > sticking them both on the link line.
> >
> > I'm inclined to bias towards a newer cmake and still generating one
static
> library.
> 
> I'm usually in the camp of not wanting to have aggressive dependency
> requirements, so having a look and opining.
> 
> pkgsrc has 3.21.2 now (and it looks like 3.21.3 just came out).
> 
> 3.13.0 was released on 2018-11-20.  That's almost 5 years ago, and I
therefore
> think it's entirely reasonable to require it if it makes anything even a
little bit
> better.
[Regina Obe] 
FWIW I'm fine with upping the requirement too.  I'm running with cmake 3.18
at moment but since I just download it from cmake website, I can easily
upgrade too if needed.




___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] cmake detailed comments

[Regina Obe]

Okay discussed with pramsey on IRC and I think I understand now why this is
all fine.

The lib ones are pointing at system installed, which is fine cause they
aren't used for testing.

The bin test_geos_unit (is pointing at libgeos_c.so.1 and libgeos.so.3.10.0)
so all tests will be going against the just built versions.
Sorry for the noise.

Hopefully I got it right this time.

Thanks,
Regina

> ldd
> ~/workspace/GEOS_Worker_Run/label/bessie/4c38944f8b5ef440398ba5f8db
> 14b75489de5d68/build/bin/test_geos_unit
> >
>   libgeos_c.so.1 =>
> /usr/home/jenkins/workspace/GEOS_Worker_Run/label/bessie/4c38944f8b5
> ef440398ba5f8db14b75489de5d68/build/lib/libgeos_c.so.1 (0x8008a3000)
> libgeos.so.3.10.0 =>
> /usr/home/jenkins/workspace/GEOS_Worker_Run/label/bessie/4c38944f8b5
> ef440398ba5f8db14b75489de5d68/build/lib/libgeos.so.3.10.0 (0x8008e7000)
> libthr.so.3 => /lib/libthr.so.3 (0x800b57000)
> libc++.so.1 => /usr/lib/libc++.so.1 (0x800b84000)
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800c51000)
> libm.so.5 => /lib/libm.so.5 (0x800c73000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800ca5000)
> libc.so.7 => /lib/libc.so.7 (0x800cbf000)
>

> [Regina Obe]
> This is what I see when I look at her latest run folder
> 
> cd
> ~/workspace/GEOS_Worker_Run/label/bessie/4c38944f8b5ef440398ba5f8db
> 14b75489de5d68/build/lib]$
> ls
> 
> outputs
> libgeos.so  libgeos.so.3.10.0   libgeos_c.so
libgeos_c.so.1
> libgeos_c.so.1.16.0 libryu.alibtinyxml2.a
> 
> Then when I do ldd:
> 
> ldd libgeos_c.so
> 
> 
> libgeos_c.so:
> libgeos-3.9.1.so => /usr/local/lib/libgeos-3.9.1.so (0x800e0)
> libc++.so.1 => /usr/lib/libc++.so.1 (0x800702000)
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8007cf000)
> libm.so.5 => /lib/libm.so.5 (0x80130)
> libc.so.7 => /lib/libc.so.7 (0x80024e000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801332000)
> 
> ldd libgeos_c.so.1.16.0
> 
> ldd
> ~/workspace/GEOS_Worker_Run/label/bessie/4c38944f8b5ef440398ba5f8db
> 14b75489de5d68/build/bin/test_geos_unit
> >
>   libgeos_c.so.1 =>
> /usr/home/jenkins/workspace/GEOS_Worker_Run/label/bessie/4c38944f8b5
> ef440398ba5f8db14b75489de5d68/build/lib/libgeos_c.so.1 (0x8008a3000)
> libgeos.so.3.10.0 =>
> /usr/home/jenkins/workspace/GEOS_Worker_Run/label/bessie/4c38944f8b5
> ef440398ba5f8db14b75489de5d68/build/lib/libgeos.so.3.10.0 (0x8008e7000)
> libthr.so.3 => /lib/libthr.so.3 (0x800b57000)
> libc++.so.1 => /usr/lib/libc++.so.1 (0x800b84000)
> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800c51000)
> libm.so.5 => /lib/libm.so.5 (0x800c73000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800ca5000)
> libc.so.7 => /lib/libc.so.7 (0x800cbf000)
> 
> 
> If it's relevant cmake --version returns -  cmake version 3.19.6
> 
> 
> Script for reference - is here -
> https://git.osgeo.org/gitea/geos/geos/src/branch/main/tools/ci/bessie32.sh
> 
> Thanks,
> Regina
> 


___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] cmake detailed comments

[Regina Obe]

After all this talk decided to check Bessie (FreeBSD 64-bit) and I'm seeing
that the geos system installed is being hooked into the lib file, though the
test bin files at a glance look okay

The geos 3.9.1 on Bessie  was installed using FreeBSD packaging 


pkg install geos

and I see reference too it in the build/lib is that expected?

> > My list of conditions may sound odd, but it's basically all packaging
> > systems that aren't mac or linux, where the "base system" is in /usr
> > and packaging things are someplace else (/usr/pkg, /usr/ports,
> > /usr/local, varies).
> 
> I got myself a fresh FreeBSD and built there. Installed in both /usr/ and
in
> /usr/local. Ran ldd on the test binary in the build directory.
> 
> ec2-user@freebsd:~/geos-git-build $ ldd  ./bin/test_geos_unit
> ./bin/test_geos_unit:
>   libgeos_c.so.1 => /home/ec2-user/geos-git-build/lib/libgeos_c.so.1
> (0x800887000)
>   libgeos.so.3.10.0 => /home/ec2-user/geos-git-
> build/lib/libgeos.so.3.10.0 (0x8008cb000)
>   libthr.so.3 => /lib/libthr.so.3 (0x800b43000)
>   libc++.so.1 => /usr/lib/libc++.so.1 (0x800b7)
>   libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800c48000)
>   libm.so.5 => /lib/libm.so.5 (0x800c6a000)
>   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800ca1000)
>   libc.so.7 => /lib/libc.so.7 (0x800cbc000)
> 
> Also, when installing, got this note:
> 
> -- Set runtime path of "/usr/bin/geosop" to ""
> 
> Seems like it's actually doing exactly the right thing. Stuff in the build
> directory is all given a temporary run path to point into that directory
and for
> things being installed that path is stripped before install.
> 
> P.
> 
[Regina Obe] 
This is what I see when I look at her latest run folder

cd
~/workspace/GEOS_Worker_Run/label/bessie/4c38944f8b5ef440398ba5f8db14b75489d
e5d68/build/lib]$
ls 

outputs 
libgeos.so  libgeos.so.3.10.0   libgeos_c.so
libgeos_c.so.1  libgeos_c.so.1.16.0 libryu.a
libtinyxml2.a

Then when I do ldd:

ldd libgeos_c.so


libgeos_c.so:
libgeos-3.9.1.so => /usr/local/lib/libgeos-3.9.1.so (0x800e0)
libc++.so.1 => /usr/lib/libc++.so.1 (0x800702000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8007cf000)
libm.so.5 => /lib/libm.so.5 (0x80130)
libc.so.7 => /lib/libc.so.7 (0x80024e000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801332000)

ldd libgeos_c.so.1.16.0

ldd
~/workspace/GEOS_Worker_Run/label/bessie/4c38944f8b5ef440398ba5f8db14b75489d
e5d68/build/bin/test_geos_unit
> 
  libgeos_c.so.1 =>
/usr/home/jenkins/workspace/GEOS_Worker_Run/label/bessie/4c38944f8b5ef440398
ba5f8db14b75489de5d68/build/lib/libgeos_c.so.1 (0x8008a3000)
libgeos.so.3.10.0 =>
/usr/home/jenkins/workspace/GEOS_Worker_Run/label/bessie/4c38944f8b5ef440398
ba5f8db14b75489de5d68/build/lib/libgeos.so.3.10.0 (0x8008e7000)
libthr.so.3 => /lib/libthr.so.3 (0x800b57000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x800b84000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800c51000)
libm.so.5 => /lib/libm.so.5 (0x800c73000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800ca5000)
libc.so.7 => /lib/libc.so.7 (0x800cbf000)


If it's relevant cmake --version returns -  cmake version 3.19.6


Script for reference - is here -
https://git.osgeo.org/gitea/geos/geos/src/branch/main/tools/ci/bessie32.sh

Thanks,
Regina



___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] OSGeo>GH Replicator

[Regina Obe]

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Friday, October 1, 2021 12:38 PM
> To: GEOS Development List 
> Subject: [geos-devel] OSGeo>GH Replicator
> 
> Last commit to GEOS as shown in GH is now two days old, notwithstanding my
> pushing a lot of stuff in as we move to release.
> Is the replicator not running?
> P
[Regina Obe] 
Should be fixed now

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.10.0beta1

[Regina Obe]

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Friday, October 1, 2021 12:39 PM
> To: GEOS Development List 
> Subject: Re: [geos-devel] 3.10.0beta1
> 
> Thanks for all these, I've committed them.
> 
> P
> 
> > On Oct 1, 2021, at 2:41 AM, Sebastiaan Couwenberg 
> wrote:
> >
> > The lintian QA tool reported a spelling error for the Debian package
build:
> >
> > * nunber -> number
> >
> > The attached patch fixes the issue.
> >
> > Kind Regards,
> >
> > Bas
[Regina Obe] 
BTW trac is fixed now. 
Still have to fix the GH replicator which I suspect is caused by the same
LetsEncrypt issue.

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] The Road to 3.10

[Regina Obe]

> > > I'm on it now, will be ready (it's just stubs) in a few hours.
> >
> > The implication being we'll roll a big change into a micro release later
on?
> This is also Less Than Ideal, even if the API remains constant, I would
think.
> 
> I'll try making it less than a stub.
> I just discovered we DO have a Geometry::isWithinDistance(), which is
> basically also a stub, as it does NOT currently use the DistanceOp support
for
> early terminating the computations. Might improve that as well.
> 
> Not sure how to possibly improve the PreparedWithinDistance though, as
> maybe there's not much to improve there.
> 
> --strk;
[Regina Obe] 
If you are simply exposing functionality that was already in C++ API in the
C-API then I retract my -1.  If you are doing more than that - like planning
to rewrite said C++ logic, my -1 stands.

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] The Road to 3.10

[Regina Obe]

> On Wed, Sep 29, 2021 at 11:19:46AM -0700, Paul Ramsey wrote:
> >
> >
> > > On Sep 29, 2021, at 10:19 AM, Sandro Santilli  wrote:
> > >
> > > On Wed, Sep 29, 2021 at 09:15:46AM -0700, Paul Ramsey wrote:
> > >> So the next step on the road to 3.10 is an interim release. I'd
> > >> like to go right to beta1. If I don't hear any howls in the next
> > >> 24-48 hours, I will cut that package so we can get our packager
friends to
> take it for a spin.
> > >
> > > I guess I'll try to sneak in a DistanceWithin and
> > > PreparedDistanceWithin signature, to improve later, do you mind ?
> >
> > A little... I mean, we do want to roll this to release in time for
PostGIS 3.2 to
> sit on top of it. What's your planned schedule?
> 
> I'm on it now, will be ready (it's just stubs) in a few hours.
> 
> --strk;
> _______
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
[Regina Obe] 
So you are putting in non-functional features to be functional in 3.10.1?
I don't like that idea at all.  Reason is then we'd have to worry about
3.10.0 can not do something that 3.10.1 can do.

It really should wait for 3.11 after Paul has flipped release version.

-1 to sneaking in a stub

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] The Road to 3.10

[Regina Obe]

> > On Sep 29, 2021, at 10:19 AM, Sandro Santilli  wrote:
> >
> > On Wed, Sep 29, 2021 at 09:15:46AM -0700, Paul Ramsey wrote:
> >> So the next step on the road to 3.10 is an interim release. I'd like
> >> to go right to beta1. If I don't hear any howls in the next 24-48
> >> hours, I will cut that package so we can get our packager friends to
take it
> for a spin.
> >
> > I guess I'll try to sneak in a DistanceWithin and
> > PreparedDistanceWithin signature, to improve later, do you mind ?
> 
> A little... I mean, we do want to roll this to release in time for PostGIS
3.2 to
> sit on top of it. What's your planned schedule?
> 
> P
> 
> >
> > --strk;
> > ___
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
>
[Regina Obe] 
Improve later like in 3.10.1?  What applications will be exercising it?
How long do you need to sneak in the change?

BTW according to Myon, they are planning to release PostgreSQL 14 this
Thursday (tomorrow) so I think our PostGIS 3.2.0 is going to be a little
later than PostgreSQL 14 release but hopefully we can coax packagers to
release it.

That said PostGIS release isn't really that impacted by GEOS 3.10 release.
Few packagers are going to be jumping to carry  GEOS 3.10 as I think we
already missed the big OS release cycles.

Packagers please speak up if I have misspoken.

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] [Mobilitydb-dev] Problem with ST_FrechetDistance in PostGIS/GEOS

[Regina Obe]

I do get 2.23606 on PostGIS so we are in agreement there.

 

As to what the right answer is I have no clue and reading math equations gives 
me a headache.

 

I’ve added geos-develop to mailing list for comment.

 

Thanks,

Regina

 

From: Mobilitydb-dev [mailto:mobilitydb-dev-boun...@lists.osgeo.org] On Behalf 
Of Esteban Zimanyi
Sent: Saturday, September 11, 2021 4:35 AM
To: mobilitydb-...@lists.osgeo.org
Subject: [Mobilitydb-dev] Problem with ST_FrechetDistance in PostGIS/GEOS

 

Dear Regina

 

We started the implementation of the discrete Frechet distance in MobilityDB 
and found out that we obtain a different result than PostGIS/GEOS.

 

test=# select frechetDistance(tgeompoint '[Point(1 1)@2000-01-01, Point(2 
2)@2000-01-02, Point(3 1)@2000-01-03]',
tgeompoint '[Point(1 4)@2000-01-01, Point(2 3)@2000-01-02, Point(3 
4)@2000-01-03, Point(4 3)@2000-01-04]');
 frechetdistance
-
   3
(1 row)

test=# select ST_FrechetDistance(geometry 'Linestring(1 1,2 2,3 1)',
test(#   geometry 'Linestring(1 4,2 3,3 4,4 3)');
 st_frechetdistance

   2.23606797749979
(1 row)

 

We used the simple algorithm referenced in the PostGIS manual

https://postgis.net/docs/ST_FrechetDistance.html

and according to our understanding the correct result is 3.

 

Indeed the matrix of Euclidean distances between a vertex of the first 
linestring and a vertex of the second linestring is as follows

 

3.6 2.23 2.23
3.6 2.23 3
2.23 1 2.23
3 2.23 3.6 

And the matrix of the computation of the Frechet distance (ca in the algorithm) 
is as follows

3.6 3 3
3.6 3 3
3 3 3
3 3 3.6

Could you please have a look ? If you confirm that there is a problem I will 
post a ticket in PostGIS and/or GEOS mailing lists.

 

Many thanks

 

Esteban

 

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] PSC Vote: Host geos.osgeo.org on GH pages

[Regina Obe]

> You guys hate the evil GitHub empire, but the way to do this is to create
a
> GitHub action that pushes the site whenever  the branch that contains the
> active docs is pushed. See PROJ, PDAL, GDAL, and others for examples of
this
> pattern working successfully for large projects.
> 
> A cron on some random computer somewhere with cached credentials is
> fragile, brittle, tied to the person who knows the details of it, and
probably
> insecure.
> 
> Howard
> 
[Regina Obe] 
Howard -- I don't know who you are thinking of.  I don't hate the Github
empire.  I just don't want all my eggs in the github empire.
I'm fine with some (even a lot) of my eggs in there, just not all.
Preferably I'd like only eggs that are easy to shift in there.

Yes I harbor a certain (I'd like to think, healthy dose) of distrust for
corporations but that is not to say I won't accept an easy opportunity that
is easy to opt out of later.
This one is pretty easy to opt out of cause we own geos.osgeo.org so we can
easily change our minds later if things don't quite work out.

Thanks,
Regina

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] PSC Vote: Host geos.osgeo.org on GH pages

[Regina Obe]

> On Mon, Aug 23, 2021 at 09:28:38AM -0700, Martin Davis wrote:
> > Under what GH account?  If it's hosted under a personal account there
> > is a bus factor issue.
> 
> Is there any specific advantage in using GH rather than having it sitting
in one
> of the existing LXC containers with letsencrypt and NGIX setup ?
> 
> Setting up a cron job or git hook to build & publish the site upon commit
to a
> git repository would be easy (under Gitea).
>
[Regina Obe] 
I think GH has a mechanism for autogenerating sites triggered on commit or
using a GH action.  Maybe we should ask gdal.org how they publish theirs for
guidance unless Paul already knows.
So main benefit is less sysadmin intervention needed, and easier for GH
users to contribute.
If we wanted to we could always have a job to publish it on a hook or cron.
We already do that with postgis-workshops which is hosted on GitHub (not GH
pages though)

 [Regina Obe] 
I still plan to setup a mirror on gitea for it, like we do for:

https://github.com/postgis/postgis-workshops (
https://git.osgeo.org/gitea/postgis/postgis-workshops )  of course that is
only like every day or so.
But still simpler than a full fledged hook.


Thanks,
Regina


___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] PSC Vote: Host geos.osgeo.org on GH pages

[Regina Obe]

Yap will be under https://github.com/libgeos  (which already has geos.osgeo.org 
as the verified link)

 

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of 
Martin Davis
Sent: Monday, August 23, 2021 12:53 PM
To: GEOS Development List 
Subject: Re: [geos-devel] PSC Vote: Host geos.osgeo.org on GH pages

 

Oh, of course, under the project site.  Too early in the morning...

 

+1 from me.

 

On Mon, Aug 23, 2021 at 9:28 AM Martin Davis mailto:mtncl...@gmail.com> > wrote:

Under what GH account?  If it's hosted under a personal account there is a bus 
factor issue.

 

 

On Mon, Aug 23, 2021 at 9:08 AM Regina Obe mailto:l...@pcorp.us> > wrote:

As Paul mentioned he already has put in work for a new geos site.

Plan is to just host it on GH pages.

I'll start with a +1 from me.

Thanks,
Regina

___
geos-devel mailing list
geos-devel@lists.osgeo.org <mailto:geos-devel@lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Having a real site? and fixing doxygen

[Regina Obe]

> > On Aug 23, 2021, at 9:49 AM, Sandro Santilli  wrote:
> >
> > On Mon, Aug 23, 2021 at 08:47:46AM -0700, Paul Ramsey wrote:
> >> I have the beginnings of a separate site on a branch. I was honestly
> planning on hosting on GH pages. There is a solid purpose to a separate
site,
> as a clean place for examples and documentation beyond just header doco
> and doxygen.
> >
> > Thanks Paul!
> > Does GH pages still let us use geos.osgeo.org as a domain ?
> 
> My cleverelephant.ca site is on GH pages, for example. There are
definitely
> corner cases in the "hosting your own domain" aspects of GH pages, so a
bit
> of a research project.
> 
[Regina Obe] 
Yes it does -- aka gdal.org  https://gdal.org
The only issue with (at least when GDAL was setup is that GH couldn't SSL
gdal.org and www.gdal.org so we had to setup a redirect on osgeo7 to
redirect all www.gdal.org pages to gdal.org.
That is a none issue with geos.osgeo.org since we've never publicized a www
anything.

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] PSC Vote: Host geos.osgeo.org on GH pages

[Regina Obe]

As Paul mentioned he already has put in work for a new geos site.

Plan is to just host it on GH pages.

I'll start with a +1 from me.

Thanks,
Regina

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Having a real site? and fixing doxygen

[Regina Obe]

I'm fine with hosting on GH pages.  I'll start a separate vote call on that
and then repoint geos.osgeo.org to whatever we decide.

+1

Thanks,
Regina

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Monday, August 23, 2021 11:48 AM
> To: GEOS Development List 
> Subject: Re: [geos-devel] Having a real site? and fixing doxygen
> 
> I have the beginnings of a separate site on a branch. I was honestly
planning
> on hosting on GH pages. There is a solid purpose to a separate site, as a
> clean place for examples and documentation beyond just header doco and
> doxygen.
> 
> > On Aug 22, 2021, at 11:16 PM, Regina Obe  wrote:
> >
> > Right now GEOS does not have a real site.
> >
> > geos.osgeo.org  is sitting on OSGeo6, which the index page simply
> > redirects to trac.osgeo.org/geos.
> > The snapshot and doxygen build was done under pramsey's account on
> > osgeo6 and that's the only thing that is hosted on geos.osgeo.org
> > (which is on osgeo6).
> >
> > This is all fine except for the fact I want to get rid of osgeo6 (or
> > at least move all project related stuff off of it so it's just
> > dedicated to mailman).
> > It also has a cmake that is older than what we support (Cmake 3.7 vs.
> > our minimal 3.8 for main branch). Though I guess that will be fixed
> > when I upgrade osgeo6 to buster in a couple of months.
> >
> > I have this ticket in place - https://trac.osgeo.org/geos/ticket/1123
> > Which I'd like some feedback on.
> >
> > The big thing that is sorely missed is our doxygen build which someone
> > already complained about a couple months ago.
> > The daily snapshots I'm guessing most people can use that generated by
> > our git or git mirrors.
> >
> > What are people's thoughts.
> >
> > 1) Is there a benefit to having a dedicated website for geos?
> > 2) Alternatively could just have Jenkins build the doxygen as part of
> > regression run and be the redirector to trac.
> >
> > Thanks,
> > Regina
> >
> >
> >
> > ___
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] Having a real site? and fixing doxygen

[Regina Obe]

Right now GEOS does not have a real site.

geos.osgeo.org  is sitting on OSGeo6, which the index page simply redirects
to trac.osgeo.org/geos.
The snapshot and doxygen build was done under pramsey's account on osgeo6
and that's the only thing that is hosted on geos.osgeo.org (which is on
osgeo6).

This is all fine except for the fact I want to get rid of osgeo6 (or at
least move all project related stuff off of it so it's just dedicated to
mailman).
It also has a cmake that is older than what we support (Cmake 3.7 vs. our
minimal 3.8 for main branch). Though I guess that will be fixed when I
upgrade osgeo6 to buster in a couple of months.

I have this ticket in place - https://trac.osgeo.org/geos/ticket/1123 Which
I'd like some feedback on.

The big thing that is sorely missed is our doxygen build which someone
already complained about a couple months ago.
The daily snapshots I'm guessing most people can use that generated by our
git or git mirrors.

What are people's thoughts.  

1) Is there a benefit to having a dedicated website for geos? 
2) Alternatively could just have Jenkins build the doxygen as part of
regression run and be the redirector to trac.

Thanks,
Regina

 

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Gitea 3.10.0dev cmake broken

[Regina Obe]

> Thanks - what would be the best way for me to patch my instance of the
> gitea repo to check that this works? Can I get a regular diff from a git
PR?
> 
> Roger
> 
> On Thu, 6 May 2021, Mike Taves wrote:
> 
> > Hi Roger,
> >
> > See https://github.com/libgeos/geos/pull/447 for a possible fix for
> > these issues.
> >
> > Cheers,
> > Mike
> >
 [Regina Obe] 

Just add a diff to the end like so?

https://github.com/libgeos/geos/pull/447.diff

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.8.2 ?

[Regina Obe]

+1

 

From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of Paul 
Ramsey
Sent: Friday, April 9, 2021 2:16 PM
To: GEOS Development List 
Subject: [geos-devel] 3.8.2 ?

 

I'd like to do a release of 3.8.2, there is a shockingly large backlog and some 
crashers hiding in there and it's been 12 months, so I'm just going to get 
started and push the button tomorrow unless someone lights their hair on fire.

 

https://github.com/libgeos/geos/blob/3.8/NEWS

 

Thanks!

P

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.9.1 Release?

[Regina Obe]

> > That last one is quite a nasty one, do take a look. The fact that we
have a
> major correctness issue argues for quick release.
> >
> > https://github.com/libgeos/geos/issues/408
> 
> With the soft freeze this Friday, it's too late to get this into the next
Debian
> stable release.
> 
> Patches for the latter three issues could be included if they don't break
the
> C++ ABI. Do they?
> 
> Kind Regards,
> 
> Bas
> 
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

Do we still have projects that rely on GEOS C++ABI being stable?
I thought we made it clear -- packagers will not carry your crap if you
choose to code against the C++ API.
So C++ API should only be used for those who choose to ship their own stuff.

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.9.1 Release?

[Regina Obe]

+1

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Tuesday, February 9, 2021 6:56 PM
> To: GEOS Development List 
> Subject: [geos-devel] 3.9.1 Release?
> 
> I'd like to release 3.9.1 tomorrow. Some important fixes have piled up.
> 
> - Bug fixes / improvements:
>   - Windows memory management quirk in createPolygon CAPI (#1050, Paul
> Ramsey)
>   - Allow build on Apple ARM64 (Taras Zakharko)
>   - Fix buffer to use largest enclosed area for invalid rings (#732, Paul
Ramsey)
>   - Preserve ordering of lines in overlay results (Martin Davis)
>   - Fix overlay handling of flat interior lines (JTS-685, Martin Davis)
> 
> That last one is quite a nasty one, do take a look. The fact that we have
a
> major correctness issue argues for quick release.
> 
> https://github.com/libgeos/geos/issues/408
> 
> Also I think getting the M1 Apple support out will be useful for our
bleeding
> edge buddies (and maybe I want to buy one of those things, just sayin').
> 
> +1 from me
> 
> P
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

I'm fine with having only cmake if the issue Paul raised below is fixed.
That is what I currently use for building.

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Friday, January 8, 2021 12:30 PM
> To: GEOS Development List 
> Subject: Re: [geos-devel] RFC7: Discontinue use of autotools
> 
> 
> 
> > On Jan 8, 2021, at 9:25 AM, Daniel Baston  wrote:
> >
> > I think the question we need to resolve is whether, after 11 years of
> working with and 5 years of officially supporting two build systems, we
need
> to continue to spend developer effort maintaining both systems in order to
> accommodate those preferences.
> 
> I agree. I can think of only one further technical task, which is ensuring
that
> the outputs of the cmake 'make dist' target are run through to 'make
check'
> in CI. Being able to bundle a release via 'make dist' is a very handy
thing and
> makes 'tag to release automatically' a potential CI target which would
also be
> nice.
> 
> P.
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] beta2 still needs --enable-overlayng

[Regina Obe]

+1 for getting rid of the compile time switch.

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Thursday, December 10, 2020 12:17 PM
> To: roger.biv...@nhh.no
> Cc: GEOS Development List 
> Subject: Re: [geos-devel] beta2 still needs --enable-overlayng
> 
> I can make it more deterministic by just removing the compile-time option
> altogether. That way, you build 3.9, you get NG, no question about it. I
don't
> see any purpose in the compile-time switch anymore, it was convenient
> during development, but now that we've done all teh changes in regresion
> etc, both in GEOS and in PostGIS and so on (BTW, don't forget to
aggressively
> add normalize to your tests) the utility of the compile-time switch is
much
> lower, and we can just leave the #define in place and manually flip it if,
for
> some reason, we want to test old behaviour.
> 
> Thoughts?
> 
> P
> 
> > On Dec 10, 2020, at 8:46 AM, Roger Bivand  wrote:
> >
> > Thanks for responding. The motivation is that users of R (and others)
> packages, using R packages interfacing GEOS will see changes in output
> geometries. We can agree that the new engine is preferable, but when their
> unit tests fail, they need to know why. They cannot run make check, and in
> the case of most they will not have a dll or dylib either, as the CRAN
package
> binaries for Windows and MacOS are built static. The lack of a convienient
> and deterministic route to knowing that the reason for the different
result is
> that GEOS is on OverlayNG is a problem, because we cannot give easy self-
> help (run sf or rgeos function x to tell you if OverlayNG is operating).
All we
> can do is assume for all cases that 3.9.0 is OverlayNG.
> >
> > Roger
> >
> > On Thu, 10 Dec 2020, Paul Ramsey wrote:
> >
> >> I am loath to add a live run-time API end point to check for a
"feature"
> that is actually the core engine. It's not like we're ever going to allow
people
> to swap engines. The old engine is going to eventually be ripped out. The
> way you know you have NG is that you can run "make check" and it works,
> because if you run "make check" with the old engine, regression is going
to
> fail. I can ensure there is configure-time output on the status, but
that's
> really about as far as I'm willing to go.
> >>
> >> P
> >>
> >>> On Dec 10, 2020, at 12:56 AM, Roger Bivand 
> wrote:
> >>>
> >>> Even with --enable-overlayng, the ring orders are different from those
> generated by OverlayNG in late October. At that stage we could
differentiate
> by typical ring order patterns, now something else has changed and we
> cannot see whether OverlayNG is operative or not. Lots of tests in R
> packages built against GEOS have relied on operations returning ring-order
> identical polygons (or coord-order identical line segments) compared with
> stored expected values.
> >>>
> >>> Please clarify urgently: OverlayNG is not mentioned in NEWS, nor does
it
> appear as the last line in ./configure output; all I can see is --disable-
> overlayng as a configure option. How can we test for the presence of
> OverlayNG in the runtime? Recall that any user compiling from source or
any
> packager may use the configure argument.
> >>>
> >>> Please do not simply rely on the version number, it is sufficiently
robust.
> >>>
> >>> Roger
> >>>
> >>> On Thu, 10 Dec 2020, Roger Bivand wrote:
> >>>
>  Hi,
> 
>  Please confirm that the 3.9.0 release will as advertised enable
> OverlayNG by default. As lately as beta2 configure still seemed to need --
> enable-overlayng. Ad-hoc tests from late October to detect ring order fail
> without --enable-overlayng. I repeat that it is necessary to provide a
clear
> way to interrogate the runtime to find out whether it supports OverlayNG.
> 
>  Next question - why no RC, is it fair to just go from beta to
release?
> 
>  Best wishes,
> 
>  Roger
> 
> 
> >>>
> >>> --
> >>> Roger Bivand
> >>> Department of Economics, Norwegian School of Economics, Helleveien
> >>> 30, N-5045 Bergen, Norway.
> >>> voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
> >>> https://orcid.org/-0003-2392-6140
> >>> https://scholar.google.no/citations?user=AWeghB0J=en
> >>> ___
> >>> geos-devel mailing list
> >>> geos-devel@lists.osgeo.org
> >>> https://lists.osgeo.org/mailman/listinfo/geos-devel
> >>
> >>
> >
> > --
> > Roger Bivand
> > Department of Economics, Norwegian School of Economics, Helleveien 30,
> > N-5045 Bergen, Norway.
> > voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
> > https://orcid.org/-0003-2392-6140
> > https://scholar.google.no/citations?user=AWeghB0J=en
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list

Re: [geos-devel] 3.9.0 Train Departing

[Regina Obe]

Yeh +1

> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Paul Ramsey
> Sent: Wednesday, December 9, 2020 11:47 AM
> To: GEOS Development List 
> Subject: [geos-devel] 3.9.0 Train Departing
> 
> I am going to package a release today, and unless someone lights their
hair
> on fire in the intervening 24 hours release tomorrow morning.
> 
> P.
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel