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

Paragon Corporation lr at pcorp.us
Mon Aug 3 10:30:10 PDT 2015


Mark and Sandro,

Thanks for your input.  I had forgotten why Mark worked so much on breaking
liblwgeom into a separate module.

Rather than focus on the flock of programmers that will be knocking on our
doorstep to help us, I am most concerned about not complicating maintenance
of PostGIS and not inheriting pissed of users.  I think Paul shares my
concerns.  
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.

Now addressing  Sandro's (SpatiaLite Sandro) comment

> AFAIK spatialite is not the unique GFOSS project using liblwgeom; exactly
the same is for QGIS.
Didn't know this, but doesn't help alleviate my concerns, just adds to them,
cause it just means more users to care about that I'd rather not be bothered
with.


> this is not at all surprising, because liblwgeom is an highly valuable
piece of code; it extends and complements in many potentially attracting
ways the basic core implemented by GEOS.

> ST_MakeValid() surely is the most outstanding example of a very
interesting function for any GFOSS package, but also ST_Segmentize(),
ST_Split(), ST_Azimuth(), ST_Project(), ST_3DDistance(), ST_Node() and many
others are surely very attractive, not to mention the brand new ISO Topology
implementation currently under active development.

Isn't ST_MakeValid, ST_Segmentize, and ST_Node inherited from GEOS?  So I
fail to see the usefulness of having to go thru liblwgeom instead of using
these directly via GEOS unless GEOS becomes liblwgeom (and then we are back
to where we were)


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


Thanks,
Regina





More information about the postgis-devel mailing list