[postgis-devel] For PostGIS 2.2 moving forward make liblwgeom compatible between micro releases

[Sandro Santilli]

On Mon, Aug 03, 2015 at 01:30:10PM -0400, Paragon Corporation wrote:

> So I think breaking out liblwgeom is a no-go at least for now unless if we
> have a postgis-core thing as Paul described.
> However I think we can make the following compromises
> 
> 1) Have a stable API that doesn't change with each micro version of PostGIS.
> This was my main issue (now that I have this dangling liblwgeom*.dll no
> longer statically linked to my shp2pgsql, pgsql2shp, raster2pgsql
> Strk I think addressed most of this here:
> https://trac.osgeo.org/postgis/ticket/2278
> 
> 2) Revise our configure scripts so it is possible to build liblwgeom without
> the PostgreSQL and other dependencies.  This I think we should table until
> PostGIS 2.3 since our plate is full with PostGIS 2.2 loose ends.

+1 to both.
I agree on not rushing too much on the spin-off path.

For sure I would still want all current PostGIS developers take care
of liblwgeom when it goes out, loosing them would be a really bad
thing.

> Speaking of which -- other Sandro (strk) -- when are you going to release
> GEOS 3.5.0, so I have one less thing to be mad at you for :)

Hey, GEOS is provided "as is" so please don't be mad.
Rather, didn't we say you were going to do the release this time ?

According to trac, the only thing left is a blocker build error
on MinGW: https://trac.osgeo.org/geos/ticket/736

Me I'd also like to see the PHP exposure of ClipByRect:
https://trac.osgeo.org/geos/ticket/734
but if you handle to cut the release out before I handle to do that,
it'll have to wait...

Did anyone respond to the call-for-testing on geos lists ?

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html