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

[a.furieri at lqt.it]

Hi PostGIS developers,

just few considerations attempting to explain how the lwgeom
problem appears as seen from outside, more precisely from the
SpatiaLite's own side; I imagine that the same considerations
will probably apply for any other FLOSS/GFOSS project excluding
PostGIS itself.

Linking lwgeom as a whole never was an exciting target,
mainly for the following reasons:
1. about 90% of lwgeom simply is an unneeded duplication of
    already existing code.
    Just consider all the wrappers built on the top of both
    GEOS and PROJ.4: SpatiaLite (exactly as QGIS, GRASS, GDAL
    and alike) already has its own, they exist since a very long
    time, they are robustly tested, and they interact very
    strictly with our main core. The same obviously is for any
    other OGC-defined SQL function and for WKT/WKB/GML/KML/etc
    parsers and writers; we already have our own since long
    time and we are not really interested in the same functions
    supported by lwgeom in an slightly different and not
    compatible form.
2. the lwgeom code is not thread-safe; this is a real PITA
    because calling any single lwgeom API always implies defining
    a critical section protected by a mutex so to properly shield
    against any risk caused by unsafe parallel processing; it's a
    really unpleasant complication strongly limiting the real
    usability of lwgeom.
3. building lwgeom as a self-standing static/dynamic library
    was a cumbersome process until recent times; happily enough
    (mainly thanks to the nice efforts of strk) now it's a
    decently plain task and this surely marked a noticeable
    usability improvement.
4. lwgeom has a very poor API/ABI long tern stability: supporting
    a new lwgeom version always implies applying many relevant
    changes and patches, both in the C wrapping code and in the
    configure scripts; and being able to correctly support several
    different versions of lwgeom at the same time can quickly
    become a real nightmare.

What is strongly attracting in lwgeom for other GFOSS projects
are 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.
Just to mention the most relevant, they are MakeValid(), Split(),
Snap(), Node(), SelfIntersection() and few others.
Please note: all these functions directly wrap some GEOS call
but all them internally perform some kind of further complex
geometry manipulation thus introducing a relevant added value.
 From an external project naive perspective they basically are
just "super muscular GEOS"; unhappily if you wish to use such
"superGEOS" functions in any other project except PostGIS you
have to necessarily face two equally unpleasant alternatives:
A) forking specific portions of the lwgeom code (IMHO an
    option to be avoided as long as possible).
B) unenthusiastically resign to link lwgeom as the lesser
    evil, then patiently suffering from the many inconvenients
    reported before.


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.

IMHO considering this new library as an lwgeom replacement
is someway misleading; it's a different thing, it's just
a brand new topology C engine including a handful of
"superGEOS" API currently buried within the lwgeom codebase
and not really easy to be reused in a different context.
I easily guess that a new library modelled this way should
probably attract the interest of several other GFOSS projects,
and I sincerely hope that PostGIS developers too will find
useful linking the new library once it will be robustly
tested and finally stable, mainly because this will simplify
their own development and maintenance tasks.

SpatiaLite will be obviously happy to be the first "experimental"
user of this new library: and will immediately contribute to
the new library it's own C code implementing Topology-Network
(currently unsupported by PostGIS/lwgeom).

Refactoring the whole lwgeom as a fully independent library
is a completely different task, and should never be confused
with the other approach advocated by the initial post from
Tuscany (A.Peri); future evolutions of lwgeom mainly are a
PostGIS own internal affair, and have a very limited interest
(if any) for any other GFOSS project.
What really matters is a very limited and well defined
subset: "superGEOS" and Topology.

bye Sandro