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

[a.furieri at lqt.it]

On 02/08/15 06:39, Mark Cave-Ayland wrote:
> 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.
>

Hi Mark,

AFAIK spatialite is not the unique GFOSS project using liblwgeom;
exactly the same is for QGIS.

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.

under the current implementation using liblwgeom as a self-standing
library outside the PostGIS own context isn't at all difficult, at
least on Linux platforms.
just to say, both Debian and Ubuntu currently deliver "liblwgeom"
and "liblwgeom-dev" as self-standing packages not depending on
PostGIS; I'm not really sure if this marks a well established
future trend for all Linux distros, but it's surely worth to
be noticed.

on the other hand building lwgeom on Windows and Android is an
unnecessarily complex task, mainly because it currently requires
building PostGIS as a whole; this in turn requires building
PostgreSQL and any related dependency.
it's surely an overwhelming task if you are just interested
into lwgeom alone (please note: PostGIS isn't currently
supported by OSGeo4W).

a second limiting factor making more difficult than expected
integrating lwgeom and some other GFOSS project is caused by
a certain API instability: since now every new version of
lwgeom always imposed several major changes to spatialite
and made developing build scripts adequately supporting more
than a single lwgeom version a rather puzzling task.


> 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.
>

This is surely true: I personally think that Mark here has
correctly focused the point.
Repackaging liblwgeom as a separate component will surely add some
further complexity, most notably during the very first steps.
Anyway a self-standing library will certainly open the doors to
many future benefits:
- will potentially attract the interest of more GFOSS projects
   (the most obvious candidate being GDAL).
- will surely facilitate direct code contributions from more
   developers
- will significantly increase the number of users/testers and
   will noticeably extend testing on more platforms and on
   substantially different operational conditions (e.g. Android
   and lightweight embedded devices).
- will strongly promote bug fixing, code portability and code
   optimization in many ways.
- will naturally facilitate long term API stability.

In a single statement; it will give birth to a robust, well stable,
thouroughly tested, highly affordable and easily portable library
nicely complementing GEOS so to get altogether a standard and powerful
Geometry engine.
And the whole FLOSS/GFOSS community will obviously benefit from this.

Last but not least: it will definitely prevent any hill minded
temptation to create some crazy kind of wild fork.
AFAIK when OSGeo4W started distributing lwgeom.dll (mainly to
the benefit of QGIS) a very rough approach was adopted by badly
slaughtering sources and headers-files so to insulate ST_MakeValid
(and few others) outside PostGIS.
more or less the same happened for some Android porting;
surely it's not enough to claim for a real fork since now:
anyway if this forecasts some future trend it's a rather
alarimng symptom.

bye Sandro