[postgis-devel] PSC vote Request: Make Geos 3.5 the default in PostGIS 2.2

Paragon Corporation lr at pcorp.us
Sun May 24 07:24:11 PDT 2015

No, not without a ton of effort and why bother?  I think in these cases we
just throw a not implemented.

We still have to put a bogus function there to make the extension consistent
across all installs.

Come to think of it we kinda have the same issue with the KNN geography
operators. But that one isn't quite as much of an issue as the GEOS one
since at least within the same PostgreSQL version install the extension
files will be the same.
That one would be an issue if people installed 2.2 on 9.4 and then
pg_upgraded to 9.5.   Might have to throw a warning in the notes somewhere.

 strk, Paul - any thoughts on how to deal with that one?  When you run
pg_upgrade, since it's doing a binary upgrade, I don't think CREATE
EXTENSION is run so the functions just get pulled over.


-----Original Message-----
From: postgis-devel-bounces at lists.osgeo.org
[mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Mark Cave-Ayland
Sent: Sunday, May 24, 2015 5:54 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] PSC vote Request: Make Geos 3.5 the default in
PostGIS 2.2

On 20/05/15 09:09, Paragon Corporation wrote:

> I suppose it would be mean to completely block compiling PostGIS 2.2 
> against a geos lower than 3.5, however, how about a compromise:
> We make GEOS 3.5 the default and if someone wants to compile with a 
> lower GEOS, then they need to pass in an extra parameter to do this.
> Why do I want to make GEOS 3.5 the default and make it a deliberate 
> decision to compile with lower GEOS
> We have 2  great functions coming in PostGIS 2.2 that rely on GEOS 3.5 
> and they've been things people have been asking for as far back as I 
> can remember in PostGIS history.
> 1) ST_ClipByBox -  which does fast clipping by boxes
> 2) it's sibling ST_SubDivide -- which does fast clipping optimizing 
> for number of vertices per clip.
> Strk -- I wanted to add Voronoi here, but guess we aren't going to 
> have that for 2.2.
> -- Anyway speaking as a package maintainer, and knowing how I think 
> which I think is how a lot of package maintainer's think, if I don't 
> know a project, I often build against the previous stable minor 
> version (Not most recent
> stable)
> And I don't have the patience to read little friendly developer 
> fineprints ("Hey you know you get more with 3.5?") unless it halts my
> That said -- if all package maintainers think like me, which I think 
> many do, we'll have a lot of users stuck with GEOS 3.4 in PostGIS 2.2 
> if there isn't a non-ignorable warning that strongly urges them to 
> build with something higher.

I think historically we've just provided older methods that work the same
way but in a less effective manner. So then if people complain these methods
are slow, they can be pointed towards a newer version of GEOS in order to
get the extra performance. Is that something that could work here?



postgis-devel mailing list
postgis-devel at lists.osgeo.org

More information about the postgis-devel mailing list