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

[Mark Cave-Ayland]

On 30/07/15 16:49, Sandro Santilli wrote:

> On Thu, Jul 30, 2015 at 05:44:21PM +0200, Sebastiaan Couwenberg wrote:
>> On 30-07-15 17:21, Sandro Santilli wrote:
> 
>>>> I sugges to start with -version-info 2:0:0 in PostGIS 2.2.0, and keep
>>>> the libtool versioning of liblwgeom separate from the PostGIS version.
>>>
>>> It might be better to postpone this to when liblwgeom gets
>>> its own release cicle.
>>
>> I tend to aggree. It currently hard to version liblwgeom indepent from
>> PostGIS.
>>
>> What will the postgis and liblwgeom interaction be like after the split?
> 
> In my vision PostGIS will link to liblwgeom as it currently links
> to geos and proj and gdal. New features might originate in either
> sides (as it happens currently between liblwgeom/ and postgis/
> subdirs) but ideally they'll be put in liblwgeom when possible.
> 
>> I'm a bit afraid liblwgeom may quickly become an stale project because
>> all development moves to postgiscore.
> 
> I don't think the focus of current developers would be affected
> by the split. Not sure what Paul envisions as ending up in
> "postgiscore".

As someone who originally worked with Sandro on splitting out liblwgeom,
the concept I had in mind was that liblwgeom was a dynamic library
internal to PostGIS with consideration that some power users might want
to use directly. The aim was to give us the following:

- Sharing of code between all parts of PostGIS

A good example of this was unifying the geometry parsers between the
PostGIS core and utilities such as shp2pgsql. And moving further along
this line, functionality could be added to detect invalid geometries on
load with shp2pgsql for example.

- Regression testing and code simplicity

The idea was that liblwgeom would contain all of the PostGIS algorithms
allowing them to be regression tested outside of the database, and so
the PostGIS part becomes just a thin wrapper (marshalling/cache layer)
around the liblwgeom functions. Heck we could probably come up with a
script to generate these wrappers directly from the liblwgeom headers or
similar which means more time working on functionality and less on
boiler-plate.

- Experiment with different algorithmic implementations

There has been some work on using other libraries such as Boost which
can outperform GEOS for certain algorithms. At one time I had a vision
of having a Boost liblwgeom alongside a GEOS liblwgeom where users can
switch between the two just by swapping out the library.

I must say I'm amazed that spatialite were able to use the library in
this way, but then it does show there is some appetite for this
functionality.

For the PostGIS developers on their own, maintaining a stable liblwgeom
API takes extra time and effort, and I can see why Paul and Regina are
expressing frustration with having to manage this extra work. However if
officially opening up liblwgeom to 3rd parties brought in fresh
developers who can work on bug fixing, optimisation and algorithm
development and further reduces the workload on the PostGIS development
team then for me the idea becomes a much more interesting proposition.


ATB,

Mark.