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

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Sun Oct 25 03:55:23 PDT 2015


On 24/10/15 14:04, a.furieri at lqt.it wrote:

> 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

Well if you're thinking of starting again from the ground up, it may be
worth considering using Boost Geometry instead of GEOS for your
liblwgeom implementation. Firstly it has a more liberal license,
secondly it has the potential to support multiple precision models and
thirdly being written native for C++ (i.e. its APIs aren't based on
Java's memory model) then it's likely to be much performant than GEOS -
I seem to remember strk doing some tests with a basic Boost Geometry
wrapper that showed a 100% speedup in some cases.


ATB,

Mark.




More information about the postgis-devel mailing list