Re: [geos-devel] MacOS DYLD Fix

[Paul Ramsey via geos-devel]

An exciting possibility, I haven’t poked that bear yet.

> On Nov 10, 2023, at 3:57 PM, Regina Obe  wrote:
> 
> Hmm what about GDAL built with GEOS on Mac, anything fun happen there? 
>  
> From: Paul Ramsey  
> Sent: Friday, November 10, 2023 6:51 PM
> To: Regina Obe 
> 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

[Paul Ramsey via geos-devel]

> On Nov 10, 2023, at 3:46 PM, Regina Obe  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

[Paul Ramsey via geos-devel]

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  wrote:
> 
> I’ll hold off on releasing until there is consensus on this issue.
>  
> From: geos-devel  On Behalf Of Paul 
> Ramsey via geos-devel
> Sent: Thursday, November 9, 2023 4:47 PM
> To: GEOS Development List 
> Cc: Paul Ramsey 
> 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

[geos-devel] MacOS DYLD Fix

[Paul Ramsey via geos-devel]

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

[Paul Ramsey via geos-devel]

OK doke

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

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

[Paul Ramsey via geos-devel]

+1. I can do the releases if you wish


> On Nov 6, 2023, at 11:52 AM, Martin Davis via geos-devel 
>  wrote:
> 
> +1 
> 
> On Mon, Nov 6, 2023 at 11:48 AM Regina Obe via geos-devel 
> mailto:geos-devel@lists.osgeo.org>> wrote:
>> According to our chart here:
>> 
>> 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
> ___
> 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] Buffering with obstacles

[Paul Ramsey via geos-devel]

Feels like a raster problem… each cell in your picture is a fixed distance from 
the starting cell.

> On Oct 11, 2023, at 3:49 PM, Nyall Dawson via geos-devel 
>  wrote:
> 
> Hi list!
> 
> (Apologies in advance for the embedded image, I couldn't write this
> post sensibly without it).
> 
> I had a novel request this week for calculation of buffers which
> respect obstacle geometries. Given input features (the red dot below,
> but could also be line/polygon features), and a layer of "obstacles"
> (the blue line, but could be either lines or polygons), then the
> buffer must respect the obstacles and not be allowed to cross over the
> blue line. Ie the desired result is the red shaded area in the
> attached image.
> 
> Every point in the buffer should be within the buffer distance of the
> original geometry by paths which don't cross any of the obstacle
> features.
> 
> There's some prior related discussion at
> https://gis.stackexchange.com/questions/390958/buffering-with-obstacles
> 
> Is this something which could potentially belong in JTS / GEOS? Is it
> even possible? And if so, is it something my customer could fund the
> development of?
> 
> Cheers,
> Nyall
> ___
> 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] cmake => 3.15?

[Paul Ramsey]

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] GEOS 3.12.0 Released

[Paul Ramsey]

Exciting news, geometry processors, the latest feature release of GEOS is now 
available.

http://libgeos.org/posts/2023-06-27-geos-3-12-released/

This release includes the following new features in the C API (and of course 
underlying changes to the C++ code to support these features):

* GEOSDisjointSubsetUnion, anptimized union algorithm for inputs that can be 
divided into subsets.
* GEOSLineSubstring, to clip a line using a start and end fractional length.
* GEOSEqualsIdentical, to test exact equality (with regards to order, 
structure, etc) of two geometries.
* GEOSOrientPolygons, to enforce a ring orientation on all polygonal elements 
in the input geometry.
* GEOSSTRtree_build, to force an immediate build of an STRtree.
* GEOSConcaveHullByLength, to build a concave hull by removing the longest 
outer edges of the Delaunay Triangulation of the space between the polygons, 
until the specified maximm edge length is reached
* GEOSGeomGetM, to read the M-dimensional value of a geometry.
* GEOSVoronoiDiagram, returns the Voronoi polygons or edges of the vertices of 
the given geometry.
* GEOSCoverageSimplifyVW, GEOSCoverageUnion, GEOSCoverageIsValid for working 
with “polygonal coverages”, collections of polygons that follow coverage rules 
(no overlaps, exact vertex equivalence on shared edges).
* GEOSGeom_releaseCollection, to free a collection while leaving the 
sub-geometries intact.
* GEOSMinimumRotatedRectangle, a rework of the minimum rectangle code to be 
faster and more correct.

GEOS has been updated to read and write “M” dimension. As with the “Z” 
coordinate support, not all operations can preserve the “M” dimension, but best 
efforts are made to retain it through calculations, input and output.

Much infrastructure work on GEOS this cycle was funded by a GDAL maintenance 
grant, and carried out by the amazing Dan Baston. Read a summary of the work 
accomplished here.

https://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg39018.html 

Full news file for this release is available here.

https://github.com/libgeos/geos/blob/3.12.0/NEWS.md

For the very impatient, direct code download is here.

https://download.osgeo.org/geos/geos-3.12.0.tar.bz2


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

[geos-devel] Vote on 3.12.0 Release

[Paul Ramsey]

Does anyone object to a 3.12.0 release on Monday/Tuesday?

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

Re: [geos-devel] 3.12 release warning

[Paul Ramsey]

> On Jun 20, 2023, at 10:28 AM, Paul Ramsey  wrote:
> 
> 
> 
>> On Jun 20, 2023, at 9:29 AM, Greg Troxel  wrote:
>> 
>> Sebastiaan Couwenberg  writes:
>> 
>>> Warning message:
>>> In fun(libname, pkgname) :
>>> rgeos: versions of GEOS runtime 3.12.0beta2-CAPI-1.18.0
>>> and GEOS at installation 3.11.1-CAPI-1.17.1differ
>> 
>> Also, I found that geoe does not use the just-built library when running
>> tests, due to inadequate RPATH/LD_LIBRARY_PATH, so if you are testing
>> 3.12 on a system with 3.11 installed, the tests may be running 3.11
>> code.
> 
> It would be helpful if this finding were qualified with the particular 
> platform it was found on, and the steps to reproduce, since I’ve never 
> managed to make it happen myself, and my computer is chock full of different 
> versions of GEOS in different places.

So what I have found in MacOS and just now trying out ArchLinux is that we are 
getting the default cmake behaviour, which is to set the rpath to the absolute 
path to the build library directory. So for example, here’s the output for 
ArchLinux

readelf -d ./bin/geosop | head -20

  TagType Name/Value
 0x0001 (NEEDED) Shared library: [libgeos_c.so.1]
 0x0001 (NEEDED) Shared library: [libgeos.so.3.12.0]
 0x0001 (NEEDED) Shared library: [libstdc++.so.6]
 0x0001 (NEEDED) Shared library: [libm.so.6]
 0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
 0x0001 (NEEDED) Shared library: [libc.so.6]
 0x001d (RUNPATH)Library runpath: 
[/home/arch/geos/_build/lib]

And for MacOS

Load command 18
  cmd LC_RPATH
  cmdsize 56
 path /Users/pramsey/Code/geos-git/_build/lib (offset 12)

The internet concurs that this is the normal behaviour for cmake builds. 

With that runpath in place, I’ve never had a problem with builds getting 
confused when running testing. 

It is worth noting that on INSTALL, cmake will re-write the rpath for the 
installed binaries, so for example, after doing ‘make install’ on ArchLinux, 
the library info now has a path relative to ORIGIN.

readelf -d /usr/local/bin/geosop | head -20

Dynamic section at offset 0x75d50 contains 32 entries:
  TagType Name/Value
 0x0001 (NEEDED) Shared library: [libgeos_c.so.1]
 0x0001 (NEEDED) Shared library: [libgeos.so.3.12.0]
 0x0001 (NEEDED) Shared library: [libstdc++.so.6]
 0x0001 (NEEDED) Shared library: [libm.so.6]
 0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
 0x0001 (NEEDED) Shared library: [libc.so.6]
 0x001d (RUNPATH)Library runpath: [$ORIGIN/../lib]

I can make the linker unhappy by doing a manual move of the build directory…

cd ..
mv _build _build2
cd _build2
./bin/geosop

Since the build rpath is absolute, the rpath no longer resolves, and yes, the 
binaries will resolve to linking any other geos it can find on linker path. 
Which if you have installed some other version or have an LD_LIBRARY_PATH set 
pointing to some other place, will result in you “testing” something other than 
the contents of your ./lib directory.

So, the build directory is “special”, and the library in the builddir/lib is 
not the same as one in installdir/lib
So, use an actual install to get an installed copy to test against, don’t 
manually move the build directory around and treat it as equivalent to an 
install, it is not.

P.


> 
> P
> 
> 
>> ___
>> 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] 3.12 release warning

[Paul Ramsey]

> On Jun 20, 2023, at 9:29 AM, Greg Troxel  wrote:
> 
> Sebastiaan Couwenberg  writes:
> 
>> Warning message:
>> In fun(libname, pkgname) :
>>  rgeos: versions of GEOS runtime 3.12.0beta2-CAPI-1.18.0
>> and GEOS at installation 3.11.1-CAPI-1.17.1differ
> 
> Also, I found that geoe does not use the just-built library when running
> tests, due to inadequate RPATH/LD_LIBRARY_PATH, so if you are testing
> 3.12 on a system with 3.11 installed, the tests may be running 3.11
> code.

It would be helpful if this finding were qualified with the particular platform 
it was found on, and the steps to reproduce, since I’ve never managed to make 
it happen myself, and my computer is chock full of different versions of GEOS 
in different places.

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.12 release warning

[Paul Ramsey]

> On Jun 20, 2023, at 9:16 AM, Sebastiaan Couwenberg  wrote:
> 
> On 6/20/23 17:58, Paul Ramsey wrote:
>>> On Jun 20, 2023, at 8:55 AM, Sebastiaan Couwenberg  
>>> wrote:
>>> On 6/20/23 00:04, Paul Ramsey wrote:
>>>> Please, test 3.12beta2 and let us know if you’re finding any issues, I am 
>>>> planning to release 3.12 at the end of the week, if there are no reports 
>>>> of issues with the last beta release.
>>> 
>>> r-cran-rgeos 0.6-1 is failing its test suite with beta2:
>>> 
>>> https://qa.debian.org/excuses.php?experimental=1=geos
>> Can you break this down for me? What GEOS function is failing on what 
>> inputs? I cannot do a lot with
>>> run-unit-testFAIL non-zero exit status 1
>> Thanks!
> 
> You need to scroll up for the output of the failing test:
> 
> autopkgtest [23:08:41]: test run-unit-test: [---
> 
> R version 4.3.1 (2023-06-16) -- "Beagle Scouts"
> Copyright (C) 2023 The R Foundation for Statistical Computing
> Platform: x86_64-pc-linux-gnu (64-bit)
> 
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
> 
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
> 
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
> 
> > library(testthat)
> > library(rgeos)
> Loading required package: sp
> rgeos version: 0.6-1, (SVN revision 692)
> GEOS runtime version: 3.12.0beta2-CAPI-1.18.0
> Please note that rgeos will be retired during 2023,
> plan transition to sf functions using GEOS at your earliest convenience.
> GEOS using OverlayNG
> Linking to sp version: 1.5-1
> Polygon checking: TRUE
> 
> Warning message:
> In fun(libname, pkgname) :
>  rgeos: versions of GEOS runtime 3.12.0beta2-CAPI-1.18.0
> and GEOS at installation 3.11.1-CAPI-1.17.1differ
> >
> > set_do_poly_check(FALSE)
> > #test_dir(system.file("tests", package = "rgeos"), 
> > StopReporter)#SummaryByContextReporter)
> > #test_package("rgeos")
> > test_check("rgeos")
> [ FAIL 1 | WARN 28 | SKIP 0 | PASS 116 ]
> 
> == Failed tests 
> 
> -- Error ('test-misc.R:50'): gNearestPoints works with different geometries 
> as inputs --
> Error: Unable to parse: MULTIPOLYGON(((34 54, 60 34, 60 54, 34 54),   
>(50 50, 52 50, 52 48, 50 48, 50 50)), 
> ((100 100, 150 100, 150 150, 100 150, 100 100),   
> (120 120, 120 130, 130 130, 130 120, 120 120
> GEOS reported: "rgeos_readWKT: unable to read wkt"

There’s a typo in the test, there should only be three closing parens at the 
end. It is in fact invalid WKT.

P.


> Backtrace:
>x
> 1. \-rgeos::readWKT("MULTIPOLYGON(((34 54, 60 34, 60 54, 34 54),\n
>(50 50, 52 50, 52 48, 50 48, 50 50)),\n
> ((100 100, 150 100, 150 150, 100 150, 100 100),\n 
>   (120 120, 120 130, 130 130, 130 120, 120 120") at test-misc.R:50:2
> 2.   \-base::tryCatch(...)
> 3. \-base (local) tryCatchList(expr, classes, parentenv, handlers)
> 4.   \-base (local) tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 5. \-value[[3L]](cond)
> 
> [ FAIL 1 | WARN 28 | SKIP 0 | PASS 116 ]
> Error: Test failures
> Execution halted
> autopkgtest [23:08:43]: test run-unit-test: ---]
> autopkgtest [23:08:43]: test run-unit-test:  - - - - - - - - - - results - - 
> - - - - - - - -
> run-unit-testFAIL non-zero exit status 1
> 
> 
> 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

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

Re: [geos-devel] 3.12 release warning

[Paul Ramsey]

> On Jun 20, 2023, at 8:55 AM, Sebastiaan Couwenberg  wrote:
> 
> On 6/20/23 00:04, Paul Ramsey wrote:
>> Please, test 3.12beta2 and let us know if you’re finding any issues, I am 
>> planning to release 3.12 at the end of the week, if there are no reports of 
>> issues with the last beta release.
> 
> r-cran-rgeos 0.6-1 is failing its test suite with beta2:
> 
> https://qa.debian.org/excuses.php?experimental=1=geos

Can you break this down for me? What GEOS function is failing on what inputs? I 
cannot do a lot with 
> run-unit-testFAIL non-zero exit status 1
Thanks!

P


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

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

Re: [geos-devel] 3.12 release warning

[Paul Ramsey]

> On Jun 19, 2023, at 8:20 PM, Sebastiaan Couwenberg  wrote:
> 
> On 6/20/23 00:04, Paul Ramsey wrote:
>> Please, test 3.12beta2 and let us know if you’re finding any issues, I am 
>> planning to release 3.12 at the end of the week, if there are no reports of 
>> issues with the last beta release.
> 
> Going straight from beta to release without one or more RC in between?

Yes, that’s just the kind of dirty mess I am.
As of now, there are zero (0) changes since beta2, so I’m not pushing any 
untested changes. If there are any changes, I’ll push another tarball, whether 
it be called “rc1” or “beta3” seems a second order concern.
ATB,
P.



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

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

[geos-devel] 3.12 release warning

[Paul Ramsey]

Please, test 3.12beta2 and let us know if you’re finding any issues, I am 
planning to release 3.12 at the end of the week, if there are no reports of 
issues with the last beta release.

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

Re: [geos-devel] 3.12.0beta1

[Paul Ramsey]

> On Jun 16, 2023, at 8:03 AM, Roger Bivand  wrote:
> 
> Using the https://github.com/libgeos/geos/tree/3.11 codebase, I'm afraid that 
> the same issue was present with the R terra package as in 3.12.0beta1 
> reported earlier. Following defensive changes in the development version of 
> terra, its current HEAD does however pass. 
> 
> Both released and development versions of terra pass with 3.12.0beta2. 
> 
> I think that this means that the 3.11 branch does not have the mitigations 
> for the multiple dimension problem.

Well, the fix for a separate problem brings this one up to visibility. Going to 
have to wriggle around to find an optimum compromise.
Thanks for confirming!

P


> 
> Roger
> 
> --
> Roger Bivand
> Emeritus Professor
> Norwegian School of Economics
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> roger.biv...@nhh.no
> 
> 
> From: Paul Ramsey 
> Sent: 15 June 2023 21:26
> To: Roger Bivand
> Cc: geos-devel@lists.osgeo.org; Robert Hijmans; Edzer Pebesma
> Subject: Re: [geos-devel] 3.12.0beta1
> 
> 
> 
>> On Jun 15, 2023, at 12:08 PM, Roger Bivand  wrote:
>> 
>> Paul, will try tomorrow morning my time. Does this 3.11 contain the fix for 
>> gcc 13 - I had to switch to devel on upgrading to Fedora 38 so if that 
>> commit is also present here, it should be feasible, if not rather harder.
> 
> There are patches for gcc 13 in the head of the 3.11 branch, so hopefully 
> will just Work.
> 
> P
> 
>> 
>> Roger
>> 
>> --
>> Roger Bivand
>> Emeritus Professor
>> Norwegian School of Economics
>> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
>> roger.biv...@nhh.no
> 

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

Re: [geos-devel] 3.12.0beta1

[Paul Ramsey]

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

There are patches for gcc 13 in the head of the 3.11 branch, so hopefully will 
just Work.

P

> 
> Roger
> 
> --
> Roger Bivand
> Emeritus Professor
> Norwegian School of Economics
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> roger.biv...@nhh.no

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

Re: [geos-devel] 3.12.0beta2

[Paul Ramsey]

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

Super! Yes, this new implementation is “different but better” than the old one. 
We had some tickets that explicitly pointed out places the old one was wrong.

P

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

Re: [geos-devel] 3.12.0beta1

[Paul Ramsey]

Roger, if you could check the current 3.11 branch against your tests,
that would be very helpful.

https://github.com/libgeos/geos/tree/3.11

There is a patch in there for an issue that appeared in some very rare
cases in PostGIS that I think might be an issue in your use cases, and
I'd like to confirm that the change is benign for you.

P

On Wed, Jun 14, 2023 at 11:57 AM Paul Ramsey  wrote:
>
>
>
> > On Jun 14, 2023, at 1:26 AM, Roger Bivand  wrote:
> >
> > Thanks, Paul, for responding so quickly.
> >
> > Having built GEOS with 
> > https://github.com/pramsey/geos/tree/main-collection-overlay, the issues in 
> > released and development versions of R package terra appear resolved.
>
> Super, thanks for testing. I have merged the PR.
>
> P
>
> >
> > The sf package remains unaffected by 3.12.
> >
> > Roger
> >
> > --
> > Roger Bivand
> > Emeritus Professor
> > Norwegian School of Economics
> > Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> > roger.biv...@nhh.no
> > ___
> > 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.12.0beta2

[Paul Ramsey]

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

[geos-devel] 3.12.0beta2

[Paul Ramsey]

Thank you everyone who tested and gave feedback on the first beta
release. Having incorporated all the feedback thus far, the next beta
is available:

https://download.osgeo.org/geos/geos-3.12.0beta2.tar.bz2

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

Re: [geos-devel] 3.12.0beta1

[Paul Ramsey]

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

Super, thanks for testing. I have merged the PR.

P

> 
> The sf package remains unaffected by 3.12.
> 
> Roger
> 
> --
> Roger Bivand
> Emeritus Professor
> Norwegian School of Economics
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> roger.biv...@nhh.no
> ___
> 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.12.0beta1

[Paul Ramsey]

I have taken a swipe at it here.

https://github.com/libgeos/geos/pull/923



> On Jun 12, 2023, at 6:01 AM, Daniel Baston  wrote:
> 
> Thanks for raising this. There was some discussion of the issue at 
> https://github.com/libgeos/geos/issues/797 and other tickets linked from 
> there, but it was never really resolved.
> 
> Dan
> 
> On Mon, Jun 12, 2023 at 8:52 AM Roger Bivand  > wrote:
>> An R packages built against GEOS is showing new test failures with 
>> 3.12.0beta1. The important terra package fails first at a union on a 
>> buffered object, other failures may occur later, but testing stops at first 
>> error. The error is:
>> 
>> Error: IllegalArgumentException: Overlay input is mixed-dimension
>> 
>> The abbreviated input in R is:
>> 
>> library(terra)
>> gdal(lib="geos")
>> # [1] "3.12.0beta1"
>> v <- vect(system.file("ex/lux.shp", package="terra"))
>> b <- buffer(v, 1000) # 1000m even though v are in degrees
>> u <- union(b)
>> # Error: IllegalArgumentException: Overlay input is mixed-dimension
>> 
>> The input shapefile may be found at 
>> https://github.com/rspatial/terra/tree/master/inst/ex/lux.*
>> 
>> I'm unsure whether this is change intentional, should I provide a WKT of the 
>> shapefile geometries, possibly planar?
>> 
>> Best wishes,
>> 
>> Roger
>> 
>> --
>> Roger Bivand
>> Emeritus Professor
>> Norwegian School of Economics
>> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
>> roger.biv...@nhh.no 
>> ___
>> 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] 3.12.0beta1

[Paul Ramsey]

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

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

Re: [geos-devel] 3.12.0beta1

[Paul Ramsey]

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

Done. Just copy pasta.
Thanks,
P

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

Re: [geos-devel] 3.12.0beta1

[Paul Ramsey]

done

curl -I https://download.osgeo.org/geos/geos-3.12.0beta1.tar.bz2

HTTP/2 200 
server: nginx/1.18.0 (Ubuntu)
date: Thu, 08 Jun 2023 16:00:18 GMT
content-type: application/octet-stream
content-length: 6718651
last-modified: Wed, 07 Jun 2023 19:24:17 GMT
etag: "6480d961-6684bb"
accept-ranges: bytes
front-end-https: on


> On Jun 8, 2023, at 8:59 AM, Paul Ramsey  wrote:
> 
> If that's required I can do that now...
> 
> On Thu, Jun 8, 2023 at 8:58 AM Sebastiaan Couwenberg  
> wrote:
>> 
>> On 6/7/23 22:05, Paul Ramsey wrote:
>>> First tagged release auto built and available at
>>> 
>>> https://github.com/libgeos/geos/releases/tag/3.12.0beta1
>> When can we expect the tarballs at:
>> 
>>  https://download.osgeo.org/geos/
>> 
>> ?
>> 
>> --
>>  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

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

Re: [geos-devel] 3.12.0beta1

[Paul Ramsey]

If that's required I can do that now...

On Thu, Jun 8, 2023 at 8:58 AM Sebastiaan Couwenberg  wrote:
>
> On 6/7/23 22:05, Paul Ramsey wrote:
> > First tagged release auto built and available at
> >
> > https://github.com/libgeos/geos/releases/tag/3.12.0beta1
> When can we expect the tarballs at:
>
>   https://download.osgeo.org/geos/
>
> ?
>
> --
>   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
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] 3.12.0beta1

[Paul Ramsey]

> On Jun 8, 2023, at 8:42 AM, Greg Troxel  wrote:
> 
> Paul Ramsey  writes:
> 
>>> On Jun 7, 2023, at 5:26 PM, Greg Troxel  wrote:
>>> 
>>> If I install the 3.12.0beta1 package, then the tests pass.  So there is
>>> a bug, but it is that the tests appaprently refer to installed files,
>>> rather than being controlled to use only files in the build tree.  
>> 
>> We had this out last release, it’s specific to a particular OS. Happy to 
>> look over a cmake patch.
>> 
>> https://lists.osgeo.org/pipermail/geos-devel/2022-June/010723.html
> 
> I didn't remember anything from the last release...
> 
> Are you saying that on every other OS, including some other BSD, that if
> one has installed to a prefix not in the default search paths, and has
> the old version installed, and runs the tests after building the new
> version, that they succeed?  I did not absorb that from reading the
> archives.

This is what I’m saying, though I personally only sling MacOS and Linux 
regularly. You’re the only one I have heard complaints about our source 
tarballs from on this issue.

> I am not particularly skilled at cmake, but I did find a note (that I
> managed not to read this time) that the problem is misordering RPATH
> args, so that the rpath passed in from a packaging system that says to
> find any depending libs in $prefix/lib happens before the special test
> rpath that says to get libs from something like builddir/lib.  If that's
> true, this isn't OS specific (and is a regression from the autotools
> build).

> 
> But I understand where you are coming from as ENOPATCH.

Er, not sure what that means. If it means I think things are *mostly* fine, 
then yes. I’d like for you also to not have problems running build/check but I 
lack the visibility on the problem to attack it personally.

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

Re: [geos-devel] 3.12.0beta1

[Paul Ramsey]

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

Yep, all changes confirmed. We’re a header-happy project.

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

Re: [geos-devel] 3.12.0beta1

[Paul Ramsey]

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

We had this out last release, it’s specific to a particular OS. Happy to look 
over a cmake patch.

https://lists.osgeo.org/pipermail/geos-devel/2022-June/010723.html


> This
> requires alternate rpath processing, etc., and in the autoconf world is
> usually handled by libtool relinking at install time.
> 
> Therefore, I have no reason to think 3.12.0beta1 is more troubled than
> any previous release -- this is likely not a regression.
> 
> My only question then about 3.12.0beta1 is if the comings-and-goings
> diff of .h files is what the authors intend.

Probably! I’ll look at that diff.

P

> 
> I am kicking off a process to rebuild everything that depends on geos
> (that I have installed, but that extends all the way to postis and
> qgis).
> 

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

Re: [geos-devel] 3.12.0beta1

[Paul Ramsey]

First tagged release auto built and available at

https://github.com/libgeos/geos/releases/tag/3.12.0beta1

P.

> On Jun 7, 2023, at 11:00 AM, Regina Obe  wrote:
> 
> 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

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

[geos-devel] 3.12.0beta1

[Paul Ramsey]

Any objections to my cutting a source release for packagers to play with?

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

Re: [geos-devel] Release Time!

[Paul Ramsey]

Nevermind, I see you’re way ahead of me pushing things into the 3.13 milestone, 
Dan :)

P

> On Jun 7, 2023, at 9:10 AM, Paul Ramsey  wrote:
> 
> HotPixelIndex: Use STRtree instead of KdTree 
> <https://github.com/libgeos/geos/pull/769>
> CoordinateSequence: create using external buffer 
> <https://github.com/libgeos/geos/pull/747>
> 
> These are both new-release worthy, but neither has generated much enthusiasm. 
> Close? Dan?
> 
> P
>  <https://github.com/libgeos/geos/pull/747#partial-pull-merging> 
> <https://github.com/libgeos/geos/pull/747#partial-pull-merging>
> 
>> On Jun 5, 2023, at 8:57 AM, Paul Ramsey  wrote:
>> 
>> I would like to get us to a 3.12 release state over the next few
>> weeks... are there tickets outstanding that anyone feels are critical
>> to release? Things you are working on that you'd like to complete?
>> Please call them out in this thread...
>> 
>> Thanks!
>> 
>> P
> 

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

Re: [geos-devel] Release Time!

[Paul Ramsey]

HotPixelIndex: Use STRtree instead of KdTree 
<https://github.com/libgeos/geos/pull/769>
CoordinateSequence: create using external buffer 
<https://github.com/libgeos/geos/pull/747>

These are both new-release worthy, but neither has generated much enthusiasm. 
Close? Dan?

P
 <https://github.com/libgeos/geos/pull/747#partial-pull-merging> 
<https://github.com/libgeos/geos/pull/747#partial-pull-merging>

> On Jun 5, 2023, at 8:57 AM, Paul Ramsey  wrote:
> 
> I would like to get us to a 3.12 release state over the next few
> weeks... are there tickets outstanding that anyone feels are critical
> to release? Things you are working on that you'd like to complete?
> Please call them out in this thread...
> 
> Thanks!
> 
> P

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

[geos-devel] Release Time!

[Paul Ramsey]

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

Thanks!

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

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

[Paul Ramsey]

Good job Mike, I think you’ve found some good historical nonsense underbrush to 
clear out of the forest. The future will thank you.

P

> On May 10, 2023, at 5:09 PM, Mike Taves  wrote:
> 
> Hi All,
> 
> Since not everyone is subscribed to GitHub changes, this email is to
> provide a "heads up" to proposed breaking changes to WKT output for
> GEOS 3.12.
> 
> The first is to change MultiPoint WKT to use parentheses in
> sub-members https://github.com/libgeos/geos/pull/903
> 
> E.g. from "MULTIPOINT (2 8, 3 9)" to "MULTIPOINT ((2 8), (3 9))"
> 
> While the former is deprecated, it will continue to be supported by WKTReader.
> 
> 
> A second suite of changes I've been scheming is to modify the defaults
> for WKTWriter:
> - Change trim from 0 for 'off' to 1 for 'on'
> - Change OutputDimension from 2 to 4
> 
> This would allow the default WKTWriter to produce familiar output,
> whereas the current default only produces 2D WKT usually with many
> decimals.
> 
> For example, take an XYZ point with x=1.1, y=2.2, z=3.3, these are the
> default WKTWriter results:
> - Current: POINT (1.1001 2.2002)
> - Proposed: POINT Z (1.1 2.2 3.3)
> 
> Additionally WKBWriter's OutputDimension could be changed from 2 to 4
> too. E.g. via writeHEX:
> - Current: 0101009A99F13F9A990140
> - Proposed: 0101809A99F13F9A9901400A40
> 
> Note that OutputDimension for WKT and WKB writers will always write 2D
> for XY geometries, regardless of setting.
> 
> These changes don't have any pull request yet, as they are subject to
> discussion first.
> 
> Opinions welcome!
> 
> Cheers,
> Mike
> ___
> 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] CoverageUnion

[Paul Ramsey]

I put it in. I'm going to flip over to the ng coverage union for CAPI,
with the area test in place now.

On Sat, Apr 29, 2023 at 5:15 PM Daniel Baston  wrote:
>>
>> We have not been able to conjure up a way to note non-coverage inputs
>> without incurring a huge performance penalty.
>
>
> I think the area test we have been using catches many non-contrived cases 
> with essentially no penalty. What is the benefit to removing it?
>
> Dan
> ___
> 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] [postgis-devel] Coverage Functions

[Paul Ramsey]

For context, the GEOS discussions were here.
https://lists.osgeo.org/pipermail/geos-devel/2023-April/010887.html
P

On Fri, Apr 28, 2023 at 3:00 PM Paul Ramsey  wrote:
>
>
>
> On Apr 28, 2023, at 2:57 PM, Martin Davis  wrote:
>
> On Fri, Apr 28, 2023 at 7:18 AM Sandro Santilli  wrote:
>>
>>
>> As mentioned in chat, I'm thinking having a GEOSCoverage
>> datatype would be advisible here, with one constructor
>> taking a vector of Geometry pointer for now but eventually
>> getting more constructors.
>
>
> Sandro, are you suggesting a GEOSCoverage type containing a *topological* 
> structure, or one containing a set of Polygons/MultiPolygons?
>
> For a topological structure, that may be useful, but that is a fair bit of 
> work and is NOT required by the recent coverage functions.  If and when this 
> is done, I suggest it is called GEOSTopology to be totally clear.
>
> For a coverage type that simply contains a list of polygonal geometries, that 
> is what I have called a Simple Features Coverage.  GEOSCoverage would be a 
> fine name for this.  This is actually what I considered at the start of 
> developing the various coverage operations.  I backed away from this in order 
> to keep things simple.  But it does have some advantages for understanding 
> and documenting the concept of a simple coverage.
>
>
> We had a little discussion of something much like this when bringing these 
> functions into GEOS CAPI, whether to use a GeometryList as a container, which 
> except for the name, is basically all a GEOSSimpleCoverage container would be 
> doing too. In the end, I was persuaded that a super lightweight approach was 
> better than adding another scruff of a type.
>
> P
>
>
>
> ___
> postgis-devel mailing list
> postgis-de...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Paul Ramsey]

> On Apr 28, 2023, at 2:57 PM, Martin Davis  wrote:
> 
> On Fri, Apr 28, 2023 at 7:18 AM Sandro Santilli  > wrote:
>> 
>> As mentioned in chat, I'm thinking having a GEOSCoverage
>> datatype would be advisible here, with one constructor
>> taking a vector of Geometry pointer for now but eventually
>> getting more constructors.
> 
> Sandro, are you suggesting a GEOSCoverage type containing a *topological* 
> structure, or one containing a set of Polygons/MultiPolygons?
> 
> For a topological structure, that may be useful, but that is a fair bit of 
> work and is NOT required by the recent coverage functions.  If and when this 
> is done, I suggest it is called GEOSTopology to be totally clear.
> 
> For a coverage type that simply contains a list of polygonal geometries, that 
> is what I have called a Simple Features Coverage.  GEOSCoverage would be a 
> fine name for this.  This is actually what I considered at the start of 
> developing the various coverage operations.  I backed away from this in order 
> to keep things simple.  But it does have some advantages for understanding 
> and documenting the concept of a simple coverage.

We had a little discussion of something much like this when bringing these 
functions into GEOS CAPI, whether to use a GeometryList as a container, which 
except for the name, is basically all a GEOSSimpleCoverage container would be 
doing too. In the end, I was persuaded that a super lightweight approach was 
better than adding another scruff of a type.

P


>  
> ___
> postgis-devel mailing list
> postgis-de...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

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

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

[Paul Ramsey]

Cc’ing over to geos-devel too

> On Apr 28, 2023, at 8:21 AM, Paul Ramsey  wrote:
> 
> 
> 
>> On Apr 28, 2023, at 7:18 AM, Sandro Santilli  wrote:
>> 
>> On Tue, Apr 25, 2023 at 05:03:25PM -0700, Paul Ramsey wrote:
>>> The first coverage functions are ready to merge.
>>> 
>>> https://github.com/postgis/postgis/pull/731/files
>> 
>> As mentioned in chat, I'm thinking having a GEOSCoverage
>> datatype would be advisible here, with one constructor
>> taking a vector of Geometry pointer for now but eventually
>> getting more constructors.
>> 
>> Validation could be performed in the constructor itself OR
>> delegated to the validator function. Simplification could be
>> a method taking that datatype, and possibly return again a
>> (simplified) GEOSCoverage from which one could derive a single
>> GEOSGeometry as the current proposed return from the simplification
>> function.
>> 
>> I've the feeling there will be more coverage-related functions,
>> that's why I'm suggesting to have a datatype for it.
> 
> I used to think this too, but I changed my mind. I made “logical sense” to me 
> that there should be an intermediate stage of “built out” coverage hanging 
> around that one then asks to do things. It turns out, though, that just 
> having “clean inputs” is sufficient to achieve what people really want, which 
> is really just replacing map shaper and being able to do polygon 
> simplification that respects neighbours. That’s the use case, pretty much 
> full stop. Secondarily, high-speed union is a benefit to having a set of 
> cleaned polygons lying around.
> 
> Isn’t that inefficient? Well, marginally perhaps, but I can run through very 
> large inputs (150MB, 2M vertices) and get results in under a second. The 
> “having a real coverage” buys me nothing.
> 
> Also worth noting, these operations run on pretty distinct code lines. There 
> isn’t an edge/node/face abstraction being built under the covers, mostly it’s 
> sets of edges. If we build up a “coverage object” it will be a Potemkin 
> structure, because it won’t have underneath the kinds of things people expect 
> it to have.
> 
> On the PostGIS side, exposing this as operations against SF collections cuts 
> down the friction to people using it in their normal lives. They just want 
> map shaper. Persisting a topology is overkill. Once we have a basic cleaner, 
> the work flow will become: load shape file; clean; simplify; run various 
> (high speed) unions for outputs. All with SF data.
> 
> In summary, if we in fact *need* an explicit coverage object, if for example 
> we are going to start having an in-memory modifiable edge/node/face object, 
> then we should then make it, but until then this SF approach makes a great 
> deal of sense to me.
> 
> P.
> 
> 
> 
> 
>> 
>> --strk;
>> ___
>> postgis-devel mailing list
>> postgis-de...@lists.osgeo.org <mailto:postgis-de...@lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel

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

Re: [geos-devel] CoverageUnion

[Paul Ramsey]

On Tue, Apr 18, 2023 at 5:24 PM Daniel Baston  wrote:
>
>  I think it would be a good idea to apply an area post-check to the NG 
> version so that we retain the error.

We have not been able to conjure up a way to note non-coverage inputs
without incurring a huge performance penalty. The NG coverage union
does not return empty on non-valid inputs, it frequently just mirrors
the non-valid parts back on the output. An area test won't catch those
cases necessarily, since the area of the input will equal the area of
the output for example if you feed in two polygons with an overlap and
no shared edges. I am tempted to change the contract and document that
a validity check is a precondition for getting "sensible" results on
output.

> I have also noticed cases (TIGER county boundaries) where the NG algorithm 
> takes about 2x as long as the old algorithm but performs better than the old 
> algorithm if the inputs are pre-sorted (as they are in the old algorithm). 
> Maybe the same sorting should be added to the NG version.

I have added the sorting, and have not yet found a case where the NG
version is slower. Also I have found that doing a union on my 5000
voting area test set, the algorithms are close in speed when
aggregating to one big output, but slower when aggregating 80 smaller
outputs. There must be a somewhat larger fixed cost per calculation in
the operation/union version than the NG one.

(for clarity, this is similar for both implementations, just one output)

  SELECT ST_CoverageUnion(geom) FROM vas;

(and this is 10x slower on the operation/union implementation, 85 outputs)

  SELECT edavbbr ST_CoverageUnion(geom) FROM vas GROUP BY edabbr;

Anyways, question for going forward: OK to change the contract on
GEOSCoverageUnion?

P

>
> Otherwise I have no reservations about switching.
>
> Dan
>
> On Tue, Apr 18, 2023 at 7:05 PM Martin Davis  wrote:
>>
>> geos/coverage/CoverageUnion in fact delegates to 
>> geos/operation/overlayng/CoverageUnion.  It's there to provide an API which 
>> is the same as the other coverage operations.
>>
>> overlayng/CoverageUnion seems to be quite a bit faster than 
>> geos/operation/union/CoverageUnion, by my testing.  So it has my vote.(They 
>> are both exposed in geosop, so independent verification is welcome.)
>>
>> On Tue, Apr 18, 2023 at 3:56 PM Paul Ramsey  
>> wrote:
>>>
>>> We have quite a few of them? Which one should be keep and bind into CAPI?
>>>
>>> geos/operation/union/CoverageUnion.h
>>> geos/operation/overlayng/CoverageUnion.h
>>> geos/coverage/CoverageUnion.h
>>> ___
>>> geos-devel mailing list
>>> geos-devel@lists.osgeo.org
>>> 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] Fedora 38 GCC 13 3.11.2 build failure

[Paul Ramsey]

Put up a PR with the changes needed to support Gcc13 in older branches, I’ll 
merge it in. I just don’t have easy access to gcc13 to do the build/test cycle 
with.

P

> On Apr 25, 2023, at 5:48 AM, Roger Bivand  wrote:
> 
> Having just  upgraded to F38, which comes with GCC 13, I deleted my unpacked 
> tarball, uncompressed 3.11.2, and tried to build. It stopped at 
> [ 51%] Building CXX object 
> CMakeFiles/geos.dir/src/shape/fractal/HilbertEncoder.cpp.o
> In file included from 
> /home/rsb/topics/geos/geos-3.11.2/src/shape/fractal/HilbertEncoder.cpp:15:
> /home/rsb/topics/geos/geos-3.11.2/include/geos/shape/fractal/HilbertEncoder.h:40:28:
>  error: expected ‘)’ before ‘p_level’
>   40 | HilbertEncoder(uint32_t p_level, geom::Envelope& extent);
>  |   ~^~~~
>  |)
> /home/rsb/topics/geos/geos-3.11.2/include/geos/shape/fractal/HilbertEncoder.h:41:5:
>  error: ‘uint32_t’ does not name a type
>   41 | uint32_t encode(const geom::Envelope* env);
>  | ^~~~
> /home/rsb/topics/geos/geos-3.11.2/include/geos/shape/fractal/HilbertEncoder.h:21:1:
>  note: ‘uint32_t’ is defined in header ‘’; did you forget to 
> ‘#include ’?
>   20 | #include 
>  +++ |+#include 
>   21 | 
> 
> The HEAD on github builds OK, and ctest runs cleanly; it has the #include 
>  declaration. Would this indicate that Fedora 38 users should build 
> from github rather than 3.11.2, since I doubt that GCC 13 fixes are a general 
> requirement?
> 
> Sorry for the distraction,
> 
> Roger
> 
> 
> --
> Roger Bivand
> Emeritus Professor
> Norwegian School of Economics
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> roger.biv...@nhh.no
> ___
> 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] CoverageUnion

[Paul Ramsey]

We have quite a few of them? Which one should be keep and bind into CAPI?

geos/operation/union/CoverageUnion.h
geos/operation/overlayng/CoverageUnion.h
geos/coverage/CoverageUnion.h
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] Coverage Operations API

[Paul Ramsey]

Having a little discussion on GH about the first two coverage functions, for 
validation and simplification, and some opinions from downstream consumers 
might be good ;)

https://github.com/libgeos/geos/pull/866

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

Re: [geos-devel] CAPI \since

[Paul Ramsey]

There’s an issue if anyone wants to pick it up.

https://github.com/libgeos/geos/issues/854

P

> On Mar 24, 2023, at 9:43 AM, Paul Ramsey  wrote:
> 
> If anyone feels like annotating the doxygen, here’s a list of the CAPI 
> function additions from 2.2 (start of CAPI) to present.
> 
> P

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

[geos-devel] CAPI \since

[Paul Ramsey]

If anyone feels like annotating the doxygen, here’s a list of the CAPI function 
additions from 2.2 (start of CAPI) to present.

P## 2.2

GEOSArea
GEOSBoundary
GEOSBuffer
GEOSContains
GEOSConvexHull
GEOSCoordSeq_clone
GEOSCoordSeq_create
GEOSCoordSeq_destroy
GEOSCoordSeq_getDimensions
GEOSCoordSeq_getOrdinate
GEOSCoordSeq_getSize
GEOSCoordSeq_getX
GEOSCoordSeq_getY
GEOSCoordSeq_getZ
GEOSCoordSeq_setOrdinate
GEOSCoordSeq_setX
GEOSCoordSeq_setY
GEOSCoordSeq_setZ
GEOSCrosses
GEOSDifference
GEOSDisjoint
GEOSDistance
GEOSEnvelope
GEOSEquals
GEOSGeomFromWKB_buf
GEOSGeomFromWKT
GEOSGeomToWKB_buf
GEOSGeomToWKT
GEOSGeomType
GEOSGeomTypeId
GEOSGeom_clone
GEOSGeom_createCollection
GEOSGeom_createLineString
GEOSGeom_createLinearRing
GEOSGeom_createPoint
GEOSGeom_createPolygon
GEOSGeom_destroy
GEOSGeom_getCoordSeq
GEOSGeom_getDimensions
GEOSGetCentroid
GEOSGetExteriorRing
GEOSGetGeometryN
GEOSGetInteriorRingN
GEOSGetNumCoordinates
GEOSGetNumGeometries
GEOSGetNumInteriorRings
GEOSGetSRID
GEOSHasZ
GEOSIntersection
GEOSIntersects
GEOSLength
GEOSLineMerge
GEOSOverlaps
GEOSPointOnSurface
GEOSPolygonize
GEOSRelate
GEOSRelatePattern
GEOSSetSRID
GEOSSymDifference
GEOSTouches
GEOSUnion
GEOSWithin
GEOS_setWKBOutputDims
GEOSisEmpty
GEOSisRing
GEOSisSimple
GEOSisValid
GEOSversion
finishGEOS
initGEOS

## 3.0

GEOSEqualsExact
GEOSGeomFromHEX_buf
GEOSGeomToHEX_buf
GEOSNormalize
GEOSSimplify
GEOSTopologyPreserveSimplify
GEOSWKBReader_create
GEOSWKBReader_destroy
GEOSWKBReader_read
GEOSWKBReader_readHEX
GEOSWKBWriter_create
GEOSWKBWriter_destroy
GEOSWKBWriter_getByteOrder
GEOSWKBWriter_getIncludeSRID
GEOSWKBWriter_getOutputDimension
GEOSWKBWriter_setByteOrder
GEOSWKBWriter_setIncludeSRID
GEOSWKBWriter_setOutputDimension
GEOSWKBWriter_write
GEOSWKBWriter_writeHEX
GEOSWKTReader_create
GEOSWKTReader_destroy
GEOSWKTReader_read
GEOSWKTWriter_create
GEOSWKTWriter_destroy
GEOSWKTWriter_write
GEOS_getWKBByteOrder
GEOS_getWKBOutputDims
GEOS_setWKBByteOrder

## 3.1

GEOSArea_r
GEOSBoundary_r
GEOSBuffer_r
GEOSContains_r
GEOSConvexHull_r
GEOSCoordSeq_clone_r
GEOSCoordSeq_create_r
GEOSCoordSeq_destroy_r
GEOSCoordSeq_getDimensions_r
GEOSCoordSeq_getOrdinate_r
GEOSCoordSeq_getSize_r
GEOSCoordSeq_getX_r
GEOSCoordSeq_getY_r
GEOSCoordSeq_getZ_r
GEOSCoordSeq_setOrdinate_r
GEOSCoordSeq_setX_r
GEOSCoordSeq_setY_r
GEOSCoordSeq_setZ_r
GEOSCrosses_r
GEOSDifference_r
GEOSDisjoint_r
GEOSDistance_r
GEOSEnvelope_r
GEOSEqualsExact_r
GEOSEquals_r
GEOSFree
GEOSFree_r
GEOSGeomFromHEX_buf_r
GEOSGeomFromWKB_buf_r
GEOSGeomFromWKT_r
GEOSGeomToHEX_buf_r
GEOSGeomToWKB_buf_r
GEOSGeomToWKT_r
GEOSGeomTypeId_r
GEOSGeomType_r
GEOSGeom_clone_r
GEOSGeom_createCollection_r
GEOSGeom_createLineString_r
GEOSGeom_createLinearRing_r
GEOSGeom_createPoint_r
GEOSGeom_createPolygon_r
GEOSGeom_destroy_r
GEOSGeom_getCoordSeq_r
GEOSGeom_getDimensions_r
GEOSGetCentroid_r
GEOSGetExteriorRing_r
GEOSGetGeometryN_r
GEOSGetInteriorRingN_r
GEOSGetNumCoordinates_r
GEOSGetNumGeometries_r
GEOSGetNumInteriorRings_r
GEOSGetSRID_r
GEOSHasZ_r
GEOSIntersection_r
GEOSIntersects_r
GEOSLength_r
GEOSLineMerge_r
GEOSNormalize_r
GEOSOverlaps_r
GEOSPointOnSurface_r
GEOSPolygonize_r
GEOSPolygonizer_getCutEdges
GEOSPolygonizer_getCutEdges_r
GEOSPrepare
GEOSPrepare_r
GEOSPreparedContains
GEOSPreparedContainsProperly
GEOSPreparedContainsProperly_r
GEOSPreparedContains_r
GEOSPreparedCovers
GEOSPreparedCovers_r
GEOSPreparedGeom_destroy
GEOSPreparedGeom_destroy_r
GEOSPreparedIntersects
GEOSPreparedIntersects_r
GEOSRelatePattern_r
GEOSRelate_r
GEOSSetSRID_r
GEOSSimplify_r
GEOSSymDifference_r
GEOSTopologyPreserveSimplify_r
GEOSTouches_r
GEOSUnionCascaded
GEOSUnionCascaded_r
GEOSUnion_r
GEOSWKBReader_create_r
GEOSWKBReader_destroy_r
GEOSWKBReader_readHEX_r
GEOSWKBReader_read_r
GEOSWKBWriter_create_r
GEOSWKBWriter_destroy_r
GEOSWKBWriter_getByteOrder_r
GEOSWKBWriter_getIncludeSRID_r
GEOSWKBWriter_getOutputDimension_r
GEOSWKBWriter_setByteOrder_r
GEOSWKBWriter_setIncludeSRID_r
GEOSWKBWriter_setOutputDimension_r
GEOSWKBWriter_writeHEX_r
GEOSWKBWriter_write_r
GEOSWKTReader_create_r
GEOSWKTReader_destroy_r
GEOSWKTReader_read_r
GEOSWKTWriter_create_r
GEOSWKTWriter_destroy_r
GEOSWKTWriter_write_r
GEOSWithin_r
GEOS_getWKBByteOrder_r
GEOS_getWKBOutputDims_r
GEOS_setWKBByteOrder_r
GEOS_setWKBOutputDims_r
GEOSisEmpty_r
GEOSisRing_r
GEOSisSimple_r
GEOSisValidReason
GEOSisValidReason_r
GEOSisValid_r
finishGEOS_r
initGEOS_r


## 3.2

GEOSBufferWithStyle
GEOSBufferWithStyle_r
GEOSHausdorffDistance
GEOSHausdorffDistanceDensify
GEOSHausdorffDistanceDensify_r
GEOSHausdorffDistance_r
GEOSInterpolate
GEOSInterpolateNormalized
GEOSInterpolateNormalized_r
GEOSInterpolate_r
GEOSProject
GEOSProjectNormalized
GEOSProjectNormalized_r
GEOSProject_r
GEOSSTRtree_create
GEOSSTRtree_create_r
GEOSSTRtree_destroy
GEOSSTRtree_destroy_r
GEOSSTRtree_insert
GEOSSTRtree_insert_r
GEOSSTRtree_iterate
GEOSSTRtree_iterate_r
GEOSSTRtree_query
GEOSSTRtree_query_r
GEOSSTRtree_remove
GEOSSTRtree_remove_r
GEOSSingleSidedBuffer
GEOSSingleSidedBuffer_r


## 3.3

Re: [geos-devel] 3.10.5 and 3.11.2 released

[Paul Ramsey]

This is expected, they came along for the backport of 

  - Fix handling of odd cases in PolygonHoleJoiner (JTS-946, Paul Ramsey, 
Martin Davis)

P

> On Mar 17, 2023, at 6:23 AM, Brian M Hamlin  wrote:
> 
> I  confirm that 3.11.3 build shows two new header files, called 
> PolygonNoder.h and PolygonNodeTopology.h
> 
>   --Brian M Hamlin/  MAPLABS  /  OSGeoLive PSC
> 
> 
> On 3/17/23 04:51, Greg Troxel wrote:
>> In 3.11.2 vs 3.11.1 I find new files installed
>> 
>> ERROR: The following files are in 
>> /tmp/work/geography/geos/work/.destdir/usr/pkg but not in the PLIST:
>> ERROR: 
>> /tmp/work/geography/geos/work/.destdir/usr/pkg/include/geos/algorithm/PolygonNodeTopology.h
>> ERROR: 
>> /tmp/work/geography/geos/work/.destdir/usr/pkg/include/geos/triangulate/polygon/PolygonNoder.h
>> 
>> and do not immediately see adding new interfaces in NEWS, so I wanted to
>> check that this is intended/correct before I push the update to pkgsrc.
>> 
>> 
>> 
>> ___
>> 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] 3.10.5 and 3.11.2 released

[Paul Ramsey]

Lots of little fixes and a potential performance regression in overlay.

## Changes in 3.11.2
2023-03-16

- Fixes/Improvements:
  - GEOSIntersection: Fix FE_INVALID exception on intersection of disjoint 
geometries
(GH-791, Joris Van den Bossche & Dan Baston)
  - Fix incorrect result from Envelope::disjoint (GH-791, Dan Baston)
  - Fix handling of odd cases in PolygonHoleJoiner (JTS-946, Paul Ramsey, 
Martin Davis)
  - Support gcc-13 (GH-743, Sergei Trofimovich)
  - Disallow Inf envelopes in Quadtree, avoid inf loop (Paul Ramsey)
  - GEOSUnaryUnion: Fix crash on collection containing empty point (GH-830, Dan 
Baston)
  - GEOSSTRtree_iterate: Do not return removed items (GH-833, Dan Baston)
  - IndexedFacetDistance: Fix crash with Inf coordinates (GH-821, Dan Baston)
  - HausdorffDistance: Fix crash on collection containing empty point (GH-840, 
Dan Baston)
  - MaximumInscribedCircle: Fix infinite loop with non-finite coordinates 
(GH-843, Dan Baston)
  - DistanceOp: Fix crash on collection containing empty point (GH-842, Dan 
Baston)
  - Guard against non-finite distances in Buffer/OffsetCurve (GH-661, Paul 
Ramsey)


Changes in 3.10.5
2023-03-16

- Fixes/Improvements:
  - Support gcc-13 (GH-743, Sergei Trofimovich)
  - Disallow Inf envelopes in Quadtree, avoid inf loop (Paul Ramsey)
  - GEOSUnaryUnion: Fix crash on collection containing empty point (GH-830, Dan 
Baston)
  - GEOSSTRtree_iterate: Do not return removed items (GH-833, Dan Baston)
  - IndexedFacetDistance: Fix crash with Inf coordinates (GH-821, Dan Baston)
  - HausdorffDistance: Fix crash on collection containing empty point (GH-840, 
Dan Baston)
  - DistanceOp: Fix crash on collection containing empty point (GH-842, Dan 
Baston)

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

[geos-devel] Release 3.11.2, 3.10.5?

[Paul Ramsey]

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] Preserving Collection Type on Precision Reduction

[Paul Ramsey]

Anyone have opinions on this one? https://github.com/libgeos/geos/issues/662

On the one hand it’s easily worked around in PostGIS. On the other hand, it’s a 
biter for anyone working with homogeneous geometry type.

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

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

[Paul Ramsey]

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] External CS Buffer

[Paul Ramsey]

Some eyes on this, and opinions would be helpful!

https://github.com/libgeos/geos/pull/747

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

Re: [geos-devel] Patch Releases

[Paul Ramsey]

Actually I was wrong, there are very few changed stacked into 3.11,
3.10, 3.9. I released a final 3.6 and marked EOL in the downloads.

On Fri, Jan 27, 2023 at 2:19 PM Paul Ramsey  wrote:
>
> No, I'll push it out, the items are crashers so they should be released.
> P
>
> > On Jan 27, 2023, at 2:12 PM, Regina Obe  wrote:
> >
> > 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
>
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Patch Releases

[Paul Ramsey]

No, I'll push it out, the items are crashers so they should be released.
P

> On Jan 27, 2023, at 2:12 PM, Regina Obe  wrote:
> 
> 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

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

[geos-devel] Patch Releases

[Paul Ramsey]

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

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

[Paul Ramsey]

So far all sounds very safe and sound... +1

> On Jan 18, 2023, at 5:37 AM, Daniel Baston  wrote:
> 
> What is the current lowest version?  C++11 requires gcc 4.9, strictly,
> but 4.8 is often enough.   Is this "4.9 worked before and will still
> work", or something else.
> 
> The lowest gcc version we test is 5. We know that GEOS does not build with 
> gcc 4.8
> because we sometimes return std::unique_ptr from functions with 
> return 
> type std::unique_ptr. I have not tried building this pull request with 
> gcc 4.9 
> (it does not appear to be available on the GitHub runner), but C++14 auto 
> lambdas 
> are claimed to be supported beginning in 4.9.
> 
>  Dan
> ___
> 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 support for Visual Studio 2015

[Paul Ramsey]

I have no skin in the game, so I'm OK for dropping MSVC 2015 going forward... 
for what that's worth (nothing).
P

> On Nov 16, 2022, at 4:44 PM, Regina Obe  wrote:
> 
> I vote for drop for GEOS 3.12+
> I guess technically we can’t drop for 3.11 and below since those would be 
> considered 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

___
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

[Paul Ramsey]

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

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

[Paul Ramsey]

+1

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

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

[Paul Ramsey]

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

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

[Paul Ramsey]

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

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

[Paul Ramsey]

> On Sep 12, 2022, at 8:28 AM, Daniel Baston  wrote:
> 
> 
> What does it mean to "support" this stuff anyways?
> 
> It's useful for maintainers to have a guideline to follow when backporting. 
> Do I backport only as far as I can apply the patch cleanly? Or is there a 
> list of "supported" releases I should try to cover?

As a "loose guide to effort" makes sense. But frankly "support" is a loaded 
term, and a "support policy" just makes it seem less flimsy than it really is.

P.



> 
> Dan
> ___
> 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)

[Paul Ramsey]

> 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

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

[Paul Ramsey]

> On Sep 7, 2022, at 3:50 PM, Martin Davis  wrote:
> 
> You read my mind.  I'm fine with an additional type in PostGIS.
> 
> Along the lines with what Dan Baston said, the idea of having a special
> coverage type that multiple operations can be applied to is very appealing
> to me.
> 
> But not 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.
> 
> I'm actually thinking the opposite!  My goal is to provide operations which 
> can be used to process sets of records in PostGIS with polygonal geometry, 
> which *implicity* form a coverage.  That fits in better with the relational 
> and SQL paradigm, I think.  In particular, coverage polygon attributes are 
> simply represented by the table rows.  By using window functions coverage 
> operations can run over sets of rows and produce new values for the geometry 
> in each row (for example:
> 
> - linework indicating coverage errors
> - a coverage-clean version of the input
> - a simplified version of the input

There a half-way meeting point in here somewhere, in which some of the 
operations that are quite intense in the postgis_topology (add an edge to an 
existing topology within a tolerance, add a polygon to an existing topology) 
might be delegated to GEOS if the API was rich enough to round-trip the 
structures. The Oracle topology module has/had the idea of a "working area", so 
that a portion of the structure could be pulled out and edited (with topology 
rules) and then stuffed back in and re-integrated very cheaply (presumably 
because the edges of the "working area" were held invariant in the operations. 
The upside of such an approach would be the "holy grail" of larger-than-memory 
coverages that could still be operated on. The downside is complexity. I think 
we'll find that enough use cases fit inside a "polygon[] -> (opaque engine) -> 
polygon[]" that the limitations are generally worth putting up 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] GEOS C API for Polygonal Coverage operations?

[Paul Ramsey]

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

I wonder if having the userData survive the trip from 
polygon->coverage->polygon would be sufficient?

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

[geos-devel] CoordinateArraySequence == CoordinateSequence

[Paul Ramsey]

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

Like, if one were going to (as one does on every single CoordinateSequence that 
enters the overlay code) 
(1) test if there are repeated points and 
(2a) remove any if there are
(2b) just return the untouched CoordinateSequence if there aren't
a useful pattern would be for ::hasRepeatedPoints() to return/populate a list 
of indexes at which repeated points appear and for ::removeRepeatedPoints() to 
do bulk copies of all the points in between those indexes. This is foreclosed 
by the CoordinateSequence API, you can play this trick nicely with a 
std::vector living underneath, but the API doesn't let us see that (in fact) 
that's what we have 99.9% of the time.

So, one obvious thing to do would be to remove the virtual methods in 
CoordinateSequence and pull the implementation up to that level, std::vector 
and all, and give up on the idea of an abstract interface that we don't 
actually use. For a handful of use cases, where data access cost is greater 
than computation cost (area, length, distance(?), some others (?)) this might 
be "bad" in some theoretical way, but note that currently we still don't 
actually have that abstract layer in place for a zero copy computation. 
Removing the virtual methods and inheritance from CoordinateSequence would 
foreclose an option that (a) we seem unlikely to ever deliver on and (b) has 
narrow performance benefits even if we did deliver on it.

Meanwhile, the flip case seems to likely have a *lot* of performance benefits 
just hanging around waiting to be harvested. Coordinate access without going 
through the inheritance structure; access to some bulk operations like the 
repeated points case.

For the "zero copy" crew, I feel like a big chunk of gains for them could be 
harvested by ensuring that point-based operations are available and don't 
require construction of a full Point() object. So things like 
PreparedGeometry->intersects(x, y). Sure, you still have to copy in your 
polygon feature and prepare it, but much of the overhead in that would still 
exist in a "zero copy" paradigm (all the internal index buildings). Meanwhile 
you'd no longer need to create a full Point() to do a point-in-poly test, and 
that would hopefully be a big win for most users.

Random thoughs on a sunny day,
P

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

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

[Paul Ramsey]

Forgot to note the source of the test framework, for those interesting
in running themselves:

https://github.com/pramsey/geos-performance

On Mon, Jul 4, 2022 at 11:43 AM Paul Ramsey  wrote:
>
> I thought I'd run the "standard" performance comparison set over the
> latest release. We haven't really done any broad-based performance
> work this cycle, so anything we picked up is incidental, and in
> general the changes were quite small.
>
> The only performance regression was in basic STRtree queries. (Which
> should probably be renamed for clarity, since it's a query on the
> default CAPI tree, which is now the TemplateRtree). The measurements
> were all pretty stable, which was gratifying, so for the differences
> of 4% or so I feel pretty confident of them. The < 1% differences
> should probably be read as "samesame".
>
> Not sure what/where a next best place to attach performance
> systematically is. For overlay, I'd say the spare copy of the data we
> make in the NodedSegmentString could be a target. Would require a
> difference lifecycle contract for the Noder, however, but could yield
> some widely effective gains, since it's such heavily used code.
>
> P.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] GEOS 3.11.0 Released

[Paul Ramsey]

Happy Canada Day! 

The 3.11.0 release of GEOS is now available to download at 
http://libgeos.org/usage/download/

This release includes new features for building "concave hulls" for both point 
and polygon input. For polygon input, the hull will be guaranteed to not cross 
into the interiors of the input polygons.

The line merger has been enhanced to support a mode that only merges lines 
which share orientation.

The offset curve algorithm has been updated to be more reliable for different 
kinds of semi-degenerate inputs, and may output different curves than the 
previous implementation, for those kinds of inputs. For "normal" inputs, the 
results should look very much like the old implementation.

As usual, numerous bugs have been fixed, and a few performance improvements 
discovered and implemented.

- New things:
  - OffsetCurve (GH-530, Paul Ramsey/Martin Davis)
  - ConcaveHull (GH-549, Paul Ramsey/Martin Davis)
  - PolygonHull (GH-603, Paul Ramsey/Martin Davis)
  - LineMerger directed option (GH-597, Sergei Sh)
  - CAPI: GEOSHilbertCode (GH-556, Brendan Ward)
  - CAPI: GEOSGeom_createRectangle (GH-558, Brendan Ward)
  - CAPI: GEOSGeom_transformXY (GH-563, Dan Baston/Brendan Ward)
  - CAPI: GEOSRemoveRepeatedPoints (GH-599, Paul Ramsey)
  - CAPI: GEOSLineMergeDirected (GH-597, Sergei Sh)
  - CAPI: setFixStructure for WKB/WKT readers to automatically repair
structural errors in the input (GH-639, Paul Ramsey)

- Fixes/Improvements:
  - Fix unaryUnion to avoid segfault with empty polygon (GH-501, Mike Taves)
  - Fix SnapRoundingNoder to use tolerance in noding; also fixes 
GeometryPrecisionReducer (GH-504, Sergei)
  - Allow direct setting of grid size (GH-513, Martin Davis)
  - Allow GEOS to be used as a CMake subproject (GH-518, Robert Coup)
  - Remove .inl inline files in favour of header declaration (GH-543, Paul 
Ramsey)
  - Add SnappingNoder seeding (Martin Davis)
  - Add OverlayNG area check heuristic (JTS-812, Paul Ramsey)
  - Fix RelateOp (and intersects predicate) for lines with intersections very 
near boundary (GH-570, Martin Davis)
  - Fix IsValidOp to handle repeated node points (JTS-845, Martin Davis)
  - Fix IsSimpleOp to handle closed LineStrings with repeated endpoints 
(JTS-851, Martin Davis)
  - Fix LengthIndexedLine (via LengthLocationMap fix) (JTS-859, Martin Davis)
  - Fix PolygonHoleJoiner (JTS-862, Martin Davis)
  - Improve `test_geos_unit` application error checking and reporting
  - Fix MinimumDiameter getMinimumRectangle for flat input (JTS-875, Martin 
Davis)
  - Fix BufferOp inverted ring check (JTS-878, Martin Davis)
  - Fix OverlayNG geomunion to avoid lines in result (Martin Davis)



___
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

[Paul Ramsey]

That said, since Greg found a versioning issue on the CAPI I've cut an
rc0 anyways, it is at the usual place, please check if that's what you
would like to do, as I am going to cut the release Friday.

http://libgeos.org/usage/download/

P.

On Wed, Jun 29, 2022 at 8:03 AM Paul Ramsey  wrote:
>
> No, there's only slightly more than zero code commits since beta2, CI is 
> green, I'm fine w/ the state of things.
>
> P.
>
> > On Jun 28, 2022, at 8:19 PM, Sebastiaan Couwenberg  
> > wrote:
> >
> > On 6/29/22 01:27, Paul Ramsey wrote:
> >> 3.11.0beta2 has been out for a week, and no complaints. This is the vote 
> >> on final release of 3.11.0
> >
> > Shouldn't there be an 3.11.0rc1 first?
> >
> > 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
>
___
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

[Paul Ramsey]

Thanks, this all looks good except the CAPI_INTERFACE_CURRENT and
CAPI_INTERFACE_AGE need to be bumped so the CAPI minor increments..
I really wonder why we retain this super confusing numbering system
for the CAPI, which needs it's own little documentation to explain. I
think we got it from libtool maybe, but it does nothing for me.
P.

On Tue, Jun 28, 2022 at 5:19 PM Greg Troxel  wrote:
>
>
> Paul Ramsey  writes:
>
> > 3.11.0beta2 has been out for a week, and no complaints. This is the vote on 
> > final release of 3.11.0
>
> I didn't get to it because it was pkgsrc's quarterly freeze week.  It
> builds on NetBSD 9 amd64, and I've included the diff to the set of
> installed files, minus noise.  The set of include changes is somewhat
> explainable from NEWS, but I'm not following.  I don't mean to push on
> that; really I'm asking "is this what is expected?".
>
> +include/geos.h
> +include/geos/algorithm/hull/ConcaveHull.h
> +include/geos/algorithm/hull/ConcaveHullOfPolygons.h
> +include/geos/algorithm/hull/HullTri.h
> +include/geos/algorithm/hull/HullTriangulation.h
> +include/geos/geom/util/GeometryMapper.h
> +include/geos/index/VertexSequencePackedRtree.h
> +include/geos/noding/SegmentExtractingNoder.h
> +include/geos/operation/buffer/BufferCurveSetBuilder.h
> +include/geos/operation/buffer/OffsetCurve.h
> -include/geos/operation/buffer/OffsetCurveSetBuilder.h
> +include/geos/operation/buffer/SegmentMCIndex.h
> +include/geos/operation/overlayng/CoverageUnion.h
> -include/geos/operation/valid/ConnectedInteriorTester.h
> +include/geos/simplify/LinkedRing.h
> +include/geos/simplify/PolygonHullSimplifier.h
> +include/geos/simplify/RingHull.h
> +include/geos/simplify/RingHullIndex.h
> -include/geos/triangulate/polygon/VertexSequencePackedRtree.h
> -lib/libgeos.so.3.10.3
> +lib/libgeos.so.3.11.0
>  lib/libgeos_c.so
>  lib/libgeos_c.so.1
> -lib/libgeos_c.so.1.16.1
> +lib/libgeos_c.so.1.16.0
>  lib/pkgconfig/geos.pc
___
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

[Paul Ramsey]

No, there's only slightly more than zero code commits since beta2, CI is green, 
I'm fine w/ the state of things.

P.

> On Jun 28, 2022, at 8:19 PM, Sebastiaan Couwenberg  wrote:
> 
> On 6/29/22 01:27, Paul Ramsey wrote:
>> 3.11.0beta2 has been out for a week, and no complaints. This is the vote on 
>> final release of 3.11.0
> 
> Shouldn't there be an 3.11.0rc1 first?
> 
> 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

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

[geos-devel] 3.11.0 Release Vote

[Paul Ramsey]

3.11.0beta2 has been out for a week, and no complaints. This is the vote on 
final release of 3.11.0

+1 Paul


P


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

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

[Paul Ramsey]

Thanks!
Going to run this through the CI grinder.

https://github.com/libgeos/geos/pull/641

P

> On Jun 21, 2022, at 3:30 PM, Even Rouault  wrote:
> 
> Since C++11, std::sqrt() is required to have an integral overload. See 
> https://en.cppreference.com/w/cpp/numeric/math/sqrt
> 
> Looking at 
> https://github.com/google/sentencepiece/issues/432#issuecomment-639434698, it 
> seems this is a known defect of Solaris world
> 
> Using 5.0 should be a no-brainer and portable fix.
> 
> Le 22/06/2022 à 00:22, Greg Troxel a écrit :
>> Paul Ramsey  writes:
>> 
>>> Well, it's super rare, platformwise so I don't really categorize it as
>>> "our problem", but it's nice to be clearer. What's the simplest way to
>> I said smartos but this is almost certainly most if not all solaris.
>> 
>>> even find out if a change fixes this? I'm tempted to make everything
>>> std::sqrt() on some kind of principle, but I have no idea if that will
>>> actually change anything. Probably just changing the 5 to 5.0 would do
>>> the trick.
>> With a candidate change, I can apply it and see what happens.   I don't
>> know the C++ rules well enough to pick something that is correct by
>> spec.
>> 
>> If your preferred approach is changing to 5.0 (which I presume is a
>> double constant since it is not 5.0f), then I can try that.
>> 
>> ___
>> geos-devel mailing list
>> geos-devel@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
> 
> -- 
> 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] build failure of 3.10.3 on smartos (= illumos)

[Paul Ramsey]

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

P

> On Jun 21, 2022, at 3:44 AM, Greg Troxel  wrote:
> 
> 
> pkgsrc is getting ready for quarterly branch, and I noticed geos fails
> to build on smartos.
> 
>  
> https://us-central.manta.mnx.io/pkgsrc/public/reports/upstream-trunk/20220620.2256/geos-3.10.3/build.log
> 
> The issue is sqrt(5) leading to ambiguous overload with long double,
> double, float.
> 
> Appparently that is supposed to be ok, and maybe cmath is supposed to be
> included, maybe using std::sqrt, maybe neither.   And maybe c++11 is
> supposed to handle int as an arg to sqrt.
> 
> Opinions as to whether this is a geos issue vs a smartos toolchain issue
> vs ?
> 
> 
> 
> 
> ___
> 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] 3.11.0beta2 Released

[Paul Ramsey]

Available wherever fine computational geometries are sold.

https://github.com/libgeos/geos/releases/tag/3.11.0beta2
http://download.osgeo.org/geos/geos-3.11.0beta2.tar.bz2
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] mingw64 file libs changed

[Paul Ramsey]

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

Re: [geos-devel] mingw64 file libs changed

[Paul Ramsey]

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

Re: [geos-devel] mingw64 file libs changed

[Paul Ramsey]

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

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

Re: [geos-devel] mingw64 file libs changed

[Paul Ramsey]

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

I wouldn't say so necessarily. I took in a commit from 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

Re: [geos-devel] mingw64 file libs changed

[Paul Ramsey]

https://github.com/manisandro/geos/commit/927e442ab1da361d3f487e2b620a878dd11f191d#commitcomment-75986489

> On Jun 13, 2022, at 9:00 AM, Regina Obe  wrote:
> 
> I mentioned this on IRC, and Paul is looking into why the change was made.
> 
> I'm mentioning here in case someone knows the reason.  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] 3.11.0beta1 Released

[Paul Ramsey]

Testing out release-on-tag, seems to work.

https://github.com/libgeos/geos/releases/tag/3.11.0beta1

Also available at the usual download location.

http://download.osgeo.org/geos/geos-3.11.0beta1.tar.bz2

We need to unravel the mystery of the MinGW versioning change for
Regina, and presumably we'll have some packaging issues to clean up,
but hopefully on track for a final release before the month ends or
sooner.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

[geos-devel] DDISABLE_GEOS_INLINE

[Paul Ramsey]

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] 3.11.0beta1

[Paul Ramsey]

Any objection to a beta release? We are feature complete for this release, so a 
quick packaging check release makes sense.

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

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

[Paul Ramsey]

Hot and tasty downloads available! 

https://libgeos.org/posts/2022-06-03-geos-3-10-3-released/

Mostly in 3.10, as one would expect.


- Fixes/Improvements:
- VoronoiDiagramBuilder::setSites(const CoordinateSequence&) return sorted 
(GH-551)
- Add SnappingNoder seeding (Martin Davis)
- Fix RelateOp (and intersects predicate) for lines with intersections very 
near boundary (GH-570, Martin Davis)
- Fix segfault in Hausdorff distance with empty geometries (GH-569)
- Fix inf loop in PolygonTriangulator (GH-574, Andrew Stelter)
- Fix short circuit from TemplateSTRtree query (GH-577, Andrew Stelter)
- Fix IsValidOp to handle repeated node points (JTS-845, Martin Davis)
- Fix IsSimpleOp to handle closed LineStrings with repeated endpoints (JTS-851, 
Martin Davis)
- Add OverlayNG area check heuristic (JTS-812, Paul Ramsey)
- Improve test_geos_unit application error checking and reporting (Martin Davis)
- Fix LengthIndexedLine (via LengthLocationMap fix) (JTS-859, Martin Davis)
- Fix PolygonHoleJoiner (JTS-862, Martin Davis)
- Fix crash in GeometryNoder on empty intpu (GH-601, Paul Ramsey)
- Handle case where user sets explicit absolute lib and include dirs (GH-608, 
Paul Ramsey)
- Fix MinimumDiameter getMinimumRectangle for flat input (JTS-875, Martin Davis)
- Fix HilbertEncoder difference in ARM vs x64 (GH-579, Paul Ramsey)
- Fix BufferOp inverted ring check (JTS-878, Martin Davis)
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [geos-devel] Stable Patch Releases

[Paul Ramsey]

Hearing no objection, I'm going to start chewing through these.
P

On Wed, Jun 1, 2022 at 2:57 PM Regina Obe  wrote:
>
> > Just getting the last changes to the CAPI into main, but in the meanwhile,
> > would like approval to push out all the extant stable patch releases, 3.7,
> 3.8,
> > 3.9, 3.10.
> >
> > +1!
> >
> > P
> [Regina Obe]
> +1
>
> ___
> 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] Stable Patch Releases

[Paul Ramsey]

Just getting the last changes to the CAPI into main, but in the meanwhile, 
would like approval to push out all the extant stable patch releases, 3.7, 3.8, 
3.9, 3.10.

+1!

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

Re: [geos-devel] MSVC / Error C2280

[Paul Ramsey]

Thanks Even, now that you point it out, that makes perfect sense. 

P.

> On May 7, 2022, at 4:34 PM, Even Rouault  wrote:
> 
> Paul,
> 
> I'd say you should add a deleted default copy constructor and assignment 
> operator in PolygonHull:
> 
> PolygonHull(const PolygonHull&) = delete;
> PolygonHull& operator=(const PolygonHull&) = delete;
> 
> Even
> 
> Le 08/05/2022 à 01:11, Paul Ramsey a écrit :
>> Hi all,
>> 
>> I have again been defeated by MSVC and the nuances of unique_ptr and copy 
>> ... the build error is here:
>> 
>> https://github.com/pramsey/geos/runs/6336639337?check_suite_focus=true#step:3:97
>> 
>> The relevant files are
>> 
>> https://github.com/pramsey/geos/blob/main-jts-polyhull/include/geos/algorithm/hull/PolygonHull.h#L137
>> https://github.com/pramsey/geos/blob/main-jts-polyhull/include/geos/algorithm/hull/RingHull.h
>> 
>> Any pointers you can provide would be much appreciated.
>> 
>> Thanks!
>> 
>> P
>> ___
>> geos-devel mailing list
>> geos-devel@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
> 
> -- 
> 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] MSVC / Error C2280

[Paul Ramsey]

Hi all,

I have again been defeated by MSVC and the nuances of unique_ptr and copy ... 
the build error is here:

https://github.com/pramsey/geos/runs/6336639337?check_suite_focus=true#step:3:97

The relevant files are 

https://github.com/pramsey/geos/blob/main-jts-polyhull/include/geos/algorithm/hull/PolygonHull.h#L137
https://github.com/pramsey/geos/blob/main-jts-polyhull/include/geos/algorithm/hull/RingHull.h

Any pointers you can provide would be much appreciated.

Thanks!

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

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

[Paul Ramsey]

Muthu,
While more effective handling of higher dimensions is something we are 
considering in the near/medium term, actually doing volumetric calculations is 
something that goes far beyond simply handling the extra coordinate dimensions, 
and is not in any developers roap map to my knowledge.
Your best bet, in python, would be researching Python bindings into CGAL, which 
not only already handles the extra dimensionality but also already has numerous 
algorithms for calculations against volumetric types.
P

> On Mar 29, 2022, at 8:04 AM, Muthu Vallinayagam  
> wrote:
> 
> Dear GEOS developers and users,
> 
> first, I thank developers for developing geos. I am using it, but indirectly, 
> via the Shapely package.
> 
> I am using Shapely for my project, which deals with 2-dimensional Polygons. I 
> need such a package
> for 3-dimensional polyhedra and in later cases for 4-d, 5-d, etc., But 
> presently Shapely supports only
> 2-dimensional polygons since GEOS supports only 2-dimension.
> 
> so I would like to request the developers about the addition of a 3-dimension 
> feature in GEOS.
> I hope that it is to activate one more dimension in the C/C++ array and 
> change respective algorithms
> in set operation definitions. 
> 
> Also using calloc and malloc we can leave array dimensions to be filled 
> dynamically. for example, if Geos
> is exported as a module in python script, the first thing user can set the 
> array dimension as per the needs. 
> If they deal with polygons the dimension is set to be 2 and for polyhedra, it 
> is 3.
> 
> 
> My overall needs are Polygon, Multipolygons, Union, and the intersection of 
> multipolygons. So 
> 
> If I want to change the libs in GEOS what are the libs should I change first?
> is it enough, if I change only the dimension of the array and Set operation 
> definitions in GEOS library for further applications in higher dimensions? 
> 
> Looking forward to your hearing 
> 
> thank you 
> 
> Best regards
> Muthu Vallinayagam,
> Postdoctorate,
> Institute for Experimental physics,
> TU Freiberg, Germany
> ___
> 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] GDAL>GEOS development funding priorities

[Paul Ramsey]

All,

Below is the list of priorities for GEOS improvement work that Dan will be 
attacking under the funding provided from the GDAL project. I think these all 
meet the general definition of being generally infrastructural and unlikely to 
be dealt with in the ordinary course of affairs: aka good targets for infra 
funding. As the project contact for the GDAL funding, I can approve this list, 
and it looks fine to me, so this is mostly a FYI, with an added layer of 
"hopefully not missing anything obvious". 

ATB,
P

--

> Howard Butler requested that I provide you with a proposed statement of work 
> describing maintenance to be performed on the GEOS library under a grant from 
> the GDAL project. Specifically, he requested that the proposed work target 
> performance improvements and API enhancements that do not typically attract 
> external funding.
> 
> The specific changes made to the library will be identified during the course 
> of the work based on code review and community input. However, based on past 
> discussions with the community and experience contributing to the library 
> since 2015, I recommend the areas of focus listed below.
> 
> Priority 1: Improving storage and access of Coordinates. Like JTS, GEOS 
> requires all coordinates to contain three dimensions and be stored in a 
> container that implements the CoordinateSequence interface. A stated purpose 
> of the CoordinateSequence interface is to allow different underlying 
> representations to be used for coordinate storage, such as an array of XYZ 
> values or parallel arrays of X, Y and Z values. This flexibility comes with a 
> cost of slow Coordinate access through virtual methods. However, other 
> assumptions of GEOS code effectively require the XYZ representation. The 
> result is that GEOS pays a performance penalty without gaining a commensurate 
> amount of implementation flexibility. Converting CoordinateSequence into a 
> concrete class backed by a vector of Coordinates is expected to improve 
> performance throughout the library. Further, many commonly used operations 
> only support two-dimensional coordinates. A CoordinateSequence backed by a 
> vector of doubles, mimicking the P
 ostGIS POINTARRAY type, may also provide improved performance while removing 
the storage penalty of Z and/or M values where they are not required.
> 
> Priority 2: Exploring applications of non-exclusive object ownership. Unlike 
> JTS, GEOS generally relies on an exclusive ownership model whereby an object 
> such as a GeometryCollection has exclusive ownership over its component 
> Geometry objects, which in turn have exclusive ownership over their 
> CoordinateSequences. While this provides simple and predictable memory 
> management, it may also result in extra copies of objects being generated so 
> that they can be used by an operation that may need to modify them (e.g., 
> noding) or by an operation that requires a specific input representation 
> (e.g., unary union). Using const shared pointers may provide opportunities to 
> reduce copying in a way that mimics JTS. However, the need to expose raw 
> pointers through the C API may limit the application of this technique.
> 
> Priority 3: Removing inheritance from portions of the code where it may 
> reduce performance, such as in SegmentString classes. This would need to be 
> done in coordination with JTS and would be contingent on the availability of 
> Martin Davis during the project period. No work is proposed for classes 
> supporting spatial predicates, as it is expected that these will be replaced 
> in a future release of JTS.
> 
> Priority 4: Reorganization of the C API such that reentrant and non-reentrant 
> versions of a function are in the same translation unit, thereby allowing the 
> compiler to inline trivial functions.
> 
> Priority 5: Removing remaining usage of raw pointer types in favor of managed 
> pointers that communicate lifecycle and ownership.
> 
> Priority 6: Defining a C++ API that can feasibly remain stable between 
> releases. It is challenging for projects to incorporate GEOS via C++ because 
> the library does not promise API or ABI stability between versions. It is not 
> possible to maintain complete API and ABI stability while closely following 
> JTS code without using cumbersome patterns such as PIMPL. However, GEOS could 
> improve its usability for C++ clients by clearly defining limited portions of 
> the API for which the project can support a stability contract (e.g., methods 
> of Geometry) and avoiding the export of internal classes that are not 
> intended for external use.
> 
> As needed, work may also include tasks such as researching and resolving 
> issues reported to GitHub, reviewing pull requests, and supporting projects 
> such as GDAL and shapely in their use of GEOS.
> 
> Proposed changes to GEOS will be described in GitHub issues and/or GitHub 
> pull requests.


___
geos-devel 

Re: [geos-devel] JTS Harmony

[Paul Ramsey]

> On Feb 18, 2022, at 4:31 PM, Paul Ramsey  wrote:
> 
> 
>> On Feb 18, 2022, at 4:15 PM, Andrew Bell  wrote:
>> 
>> Has the attitude about keeping the codebase in sync with the JTS code 
>> changed? I would potentially do some work on this project if this isn't a 
>> requirement -- it seemed difficult to make changes that would make the code 
>> more accessible with strict adherence to the JTS structure.
>> 
>> Sorry if this isn't the right thread for this question.
> 
> I think a new thread title makes sense.
> 
> I guess it depends a lot on what those changes are, because one thing we 
> don't want is making porting out of JTS a whole pile harder. 
> 
> Is that a strict restriction, or something else?

Like, there's already affordances for C++ lying around that result in 
differences. JTS has lots of places where it returns a null Coordinate pointer 
to indicate a failure, and GEOS ends up working around that with things like 
Coordinate::isNull(). Similar stuff for Envelopes. The access of Coordinate out 
of CoordinateArray is a little mismatched to how JTS does it because it's 
returnng a const Coordinate& instead of a pointer to a Coordinate. Each of 
these makes porting a wee bit more of a brain exercise, but the trade-offs are 
worth it in terms of being to stack-allocate things more, work with references, 
etc.

??

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

[geos-devel] JTS Harmony

[Paul Ramsey]

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

I think a new thread title makes sense.

I guess it depends a lot on what those changes are, because one thing we don't 
want is making porting out of JTS a whole pile harder. 

Is that a strict restriction, or something else?

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

Re: [geos-devel] GEOS Maintenance Grant

[Paul Ramsey]

While I appreciate the sentiment behind this, I do not believe the particular 
breakdown below is reflective of the current needs of this project.

- This is a library. The users of the project are not pro-sumers or 
non-technical, they are C and C++ developers. Users who are not C and C++ 
developers are supported by the particular project that is embedding the 
library, whether it be PostGIS, QGID, GDAL or Shapely. The documentation 
requirements are therefore relatively meagre. 
- This is a library with 15 years of technical debt. From its very birth, GEOS 
was built on foundations of sand. Hewing over-closely to the JTS code, it built 
up a burden of heal-allocations that have only been slowly pared back. The 
first professional services contract I let for improvements was... to track 
down the huge piles of memory leaks generated by that festival of heap 
allocations. Between the date of birth in the early 2000's to now, the C++ 
language itself has been transformed (several times), leaving the code base in 
a somewhat mish-mash state, some "modern" other ... not.
- This is a library with some big jobs that are no fun and yet fairly 
foundational. Off the top of my  head: support for M coordinates and 
rationalizing that against an efficient implementation of coordinatesequences, 
support for ISO circular arc geometry structures, efficient use of in-place 
data for more 'no-copy' operations.

The breakdown below perhaps makes sense for a project like QGIS, but for a this 
particular project with this projects current needs, focussing on development 
and developer-level documentation needs (good/better doxygen, example programs, 
consistent and clear in-code commenting) for this round is where we are going 
to go.

ATB,

P


> On Feb 17, 2022, at 1:20 PM, Jeff McKenna  
> wrote:
> 
> Dear GEOS PSC,
> 
> Great to hear about a grant to help the project along.
> 
> My feedback is to make sure that the funds are spread around, not just to one 
> developer, but also to the (even more critical) parts of software projects 
> that never receive funding, yet are so important to end-users: documentation, 
> testing, and packaging.
> 
> I know it is 2022, and we have so many corporate influences in FOSS4G that 
> it's hard to see through the activity/smoke, but, we should always try to 
> make sure that the funds are spread around to as many parts of the project as 
> possible.  For example, 50k USD could be shared by the GEOS PSC as:
> 
>  - 25k development
>  - 10k documentation
>  - 10k packaging
>  -  5k testing and releases
> 
> That is a fair plan for actual project "maintenance". QGIS.ORG (the 
> registered entity behind QGIS) & the QGIS PSC does an excellent job at 
> spreading the funding around to all parts of the project, which creates a 
> "product" feeling to QGIS (a well-rounded result).
> 
> My rule of thumb, is that for every 1 hour of development in a software 
> project spent, it should take approximately 8 hours of further testing, 
> documentation, and packaging by others, if done properly. (instead of one 
> funded developer doing an hour of development, and squeezing in a few minutes 
> of docs often by the same developer).
> 
> I hope my feedback can be received well by the GEOS PSC, and they could keep 
> this feedback in mind the next time funding comes along.
> 
> Thanks, sent from the east coast of Canada,
> 
> -jeff
> 
> 
> 
> 
> -- 
> Jeff McKenna
> GatewayGeo: Developers of MS4W, MapServer Consulting and Training
> co-founder of FOSS4G
> http://gatewaygeo.com/
> 
> 
> 
> On 2022-02-15 11:37 a.m., 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 
>> 

Re: [geos-devel] PSC Resignation

[Paul Ramsey]

Thanks Dale, for your time with the PSC over the years and for Safe's early 
support and validation of GEOS as a library that could to "real work for real 
people" back when that was, curiously, an argument that had to be made!
Yours,
Paul

> On Feb 17, 2022, at 5:48 PM, Dale Lutz  wrote:
> 
> Hello GEOS friends,
> 
> It is with a heavy heart that I request to be removed from the GEOS PSC.  The 
> reasons are twofold — I'm at a stage in my career that I'm as good as I once 
> was (though I'm as good once as I've ever was) -- I digress, but seriously, 
> I'm no longer doing active development of any kind so my opinions would be 
> suspect.  And secondly, at Safe we no longer are making use of GEOS directly.
> 
> That said, I'll continue to cheer on from the sidelines and do what I can to 
> support ongoing GEOS efforts (like being happy that some of our GDAL funding 
> may end up helping here), because I believe a solid GEOS is a very good thing 
> for the community at large, and the world quite frankly.
> 
> Thanks all for the amazing progress you've made over these past 15 or 20 
> years(!), and I look forward to seeing  what the future holds.
> 
> Dale
> 
> ___
> 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] Motion: Adopt OSGeo Code of Conduct

[Paul Ramsey]

Thanks all, approved and done.
P

> On Feb 17, 2022, at 7:05 AM, Howard Butler  wrote:
> 
> +1 
> 
> Howard
> 
>> On Feb 16, 2022, at 7:04 PM, Daniel Baston  wrote:
>> 
>> +1
>> 
>> Dan
>> 
>> On Wed, Feb 16, 2022 at 5:46 PM Sandro Santilli  wrote:
>> On Wed, Feb 16, 2022 at 12:31:06PM -0800, Paul Ramsey wrote:
>>> I noticed that the GDAL CoC is in fact just the OSGeo CoC, which is 
>>> convenient, as we are an OSGeo project.
>>> 
>>> The code change is here.
>>> 
>>> https://github.com/libgeos/geos/pull/568
>>> 
>>> We already have a
>>> +1 Paul
>>> +1 Regina
>> 
>> +1
>> 
>> --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

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

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

[Paul Ramsey]

I noticed that the GDAL CoC is in fact just the OSGeo CoC, which is convenient, 
as we are an OSGeo project.

The code change is here.

https://github.com/libgeos/geos/pull/568

We already have a
+1 Paul
+1 Regina
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Paul Ramsey]

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

Re: [geos-devel] GEOS Maintenance Grant

[Paul Ramsey]

+1, sounds wonderful. I'm willing to be the liason to the GDAL / NumFocus 
administrators for this work.

P

> On Feb 15, 2022, at 10:11 AM, Regina Obe  wrote:
> 
> GEOS PSC +1
> 
>> -Original Message-
>> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
>> Howard 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

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

[geos-devel] GEOS 3.10.2 Released

[Paul Ramsey]

The latest patch release of GEOS is now available!

http://libgeos.org/usage/download/

Changes in 3.10.2
2022-01-15

- Fixes/Improvements:
  - Fix crash in MonotoneChain with empty CoordinateSequence (GH-539, Sandro 
Santilli)
  - Fix crash in GeoJSONWriter in case of empty points (TRAC-1139, Paul Ramsey)
  - Improve BuildArea performance (TRAC-1122, Sandro Santilli)
  - Fix unaryUnion to avoid segfault with empty polygon (GH-501, Mike Taves)
  - Fix memory leak on exception in prepared geometry (GH-506, Dan Baston)
  - Iterator invalidation in rare cases (GH-508, Momtchil Momtchev)
  - Infinite loop on collapsed input to MaximumInscribedCircle (Paul Ramsey)
  - Write LinearRing to GeoJSON as LineString (TRAC-1140, Paul Ramsey)
  - Fix PolygonEarClipper to handle collapsed corners (GH-526, Martin Davis)
  - Fix GEOSSTRtree_remove for empty tree (GH-544, Dan Baston)
  - Fix crash on query of STRtree with removed items (GH-545, Dan Baston)

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