[postgis-devel] A letter to the Postgis Developers and Packagers

[Mark Johnson]

During this extensive discussion, the different needs of the different
participates have, I believe been crystallized.

At this point it might be wise to to create a summery of these, that can
then be a base for a constructive suggestion on how to deal with this
matter.

My impression is, that Andrea Peri of Tuscany Region, is waiting for an
agreement of all participants.

Also, so my impression, Tuscany Region may also be a public service, which
means that they must justify the expenditure of public funding. So the
possible third funding must achieve the final goal that the first 2 funding
were indented for.

---
Main Participants (hopefully complete and correct):
- Sandro Santilli: as a major maintainer of the GEOS project, but also of
PostGIS
- Regina Obe and Paul Ramsey as major maintainers of PostGIS
- Sandro Furieri the major maintainer of Spatialite
- myself (Mark Johnson) as maintainer of the Android Spatialite/RasterLite2
Database Driver

For the Android side (and based on messages sent to the Spatialite User
list, possibly for others such as Cordova and iOS) the main problem is that
applications must be self contained (no Dynamic Library support).
So that all dependencies must be included in the project
- in the case of liblwgeom: PostGIS with PostgreSQL plus any dependencies
they may have

This is why, when building the Spatialite portion, liblwgeom was not
included.

In September I was asked to check if liblwgeom, in its present form,
compiled and ran as indented without these dependencies (with minor
corrections), which it did.

So it seems to me that
- Regina Obe and Paul Ramsey
- Sandro Furieri
and the Android project have a common problem:
- that with certain dependencies, versions conflicts occur.

So this common problem needs, for all participants, a reliable, permanent
solution.

Another common problem, is the necessity of not
- 'Reinventing the wheel'

---
As Sandro Furieri mentioned in his note from 24 Oct 2015 (yesterday)
- what is needed is 'just a handful of highly valuable sophisticated spatial
functions that have no equivalent implementation and that
aren't so easy and simple to be independently rewritten.'

These portions are not from GEOS, but from the PostGIS project.

So if a split is made, as Sandro Furieri has suggested:

What the new separated library should possibly be
--------------------------------------------------
a) a simple, streamlined and light-weighted library just
    depending on GEOS alone.
b) robust thread-safe implementation.
c) canonic configure scripts fully supporting versioning,
    SONAMEs and alike so to make maintainers and packagers
    activities as easy as possible.
d) long term API/ABI rock-solid stability (with possible
    exceptions only during initial alpha/beta testing steps).
e) full support for ISO Topology, and consequently directly
    supporting all the "super-GEOS" API strictly required by
    the Topology code itself, as e.g. MakeValid, Snap etc.
no less than this, no more than this.

it would mean original PostGIS code portions would need to be included.

I believe that such a library, with the above mentioned functionality
- should become a sub-project of GEOS
-- possibly called 'geos_extended'

Assuming the these portions (of the 'handful of highly valuable
sophisticated spatial functions') are self contained
- i.e. not being used elsewhere inside PostGIS as extra functions
-- that need to be maintained due to internal changes inside PostGIS itself

These are decisions that only the PostGIS project can decide
- including any possible licence differences between GEOS and PostGIS
-- which the transfer of the portions from one project to the other would
entail

---
Assuming that all of this is answered with 'yes'
- after extraction, liblwgeom could then be integrated back into PostGIS
-- solely as an internal portion

---
Such a 2 part solution would:
- make a common code usable for all
-- without the present conflicts
- without repetition of common functions, implemented differently
-- such as ST_ConcaveHull
- no 'Reinventing the wheel'

In this sense, I suggest that, based on the above suggestion, a consensus
be made among the participants on how to deal with this problem.

With that, Andrea Peri of Tuscany Region (who started this thread) would
receive the answer he, I assume, is waiting for.

Regina Obe stated in point 4 of her note from 22 Oct 2015
- 'Though with PostgreSQL 9.6 coming soon and the whole parallel query
thing coming in, I'm not sure if that may change our need for threading.'

Insofar as this has not already been dealt with the present version of
liblwgeom
- this could also be dealt with in Andrea Peri offer to help in 'the
recovery in PostGIS of the previous plpgsql implementation of the Topology
module.'

Final decisions could then be made
- and thus end this thread

Mark Johnson, Berlin Germany
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20151025/8048154d/attachment.html>