[postgis-devel] PSC vote Request: Make Geos 3.5 the default in PostGIS 2.2
Mark Cave-Ayland
mark.cave-ayland at ilande.co.uk
Sun May 24 02:53:39 PDT 2015
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 compilation.
>
> 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?
ATB,
Mark.
More information about the postgis-devel
mailing list