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

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]

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]

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