[postgis-devel] liblwgeom versioning

[a.furieri at lqt.it]

On Fri, 9 Oct 2015 19:34:16 +0200, Sebastiaan Couwenberg wrote:
> On 09-10-15 18:59, Sandro Santilli wrote:
>> On Fri, Oct 09, 2015 at 10:36:24AM -0400, Greg Troxel wrote:
>>> Sounds good; then I could make a liblwgeom package easily.  But 
>>> until
>>> some other package needs it, I probably won't.
>>
>> I believe next spatialite release will be using it.
>
> Building SpatiaLite with liblwgeom support is the recommended
> configuration since 4.3.0 as mentioned on the spatialite-users list:
>
> ------------------------ <snip> -------------------
>
> 4.3.0: note for builders and packages:
> 
> https://groups.google.com/d/msg/spatialite-users/uawzaLjzbo4/_0JqJ8a6HmAJ
>

Yes, I substantially confirm what already stated by Bas.

SpatiaLite started supporting lwgeom since November 2012 (v.4.0.0),
and the initial support was initially limited to ST_MakeValid() alone.

Subsequent versions significantly extended the number of SQL
functions depending on lwgeom; this is the full list available
on the very recent 4.3.0 (July 2015):
ST_MakeValid() ST_Split(), ST_Segmentize(), ST_Azimuth,
ST_Project(), ST_SnapToGrip(), ST_GeoHash(), ST_AsX3D(),
ST_MaxDistance(), ST_3dDistance(), ST_3dMaxDistance(),
ST_Node() and ST_SelfIntersections()

This surely represent an interesting and useful collection of
advanced Spatial SQL functions, but it's still reasonable
assuming that many users could happily survive even after
disabling the whole lwgeom-depending module.

The scenario will radically change with the next 4.4.0
still under very active development; a first preliminary
ALPHA-testing version is expected to be released in the
next weeks, and the stable version should be probably
released on November or December.

SpatiaLite 4.4.0 will start supporting a full Topology
implementation conformant to the ISO/IEC 13249-3 standard
specification strictly requiring to be supported by the
very recent low-level C API developed by strk in lwgeom-topo.

In other words: next year we'll finally have _two_ different
GFOSS Spatial DBMSes offering an identical Topology support
based on the same low-level library, i.e. lwgeom-topo.
The one adopting a sophisticate high-end client-server
architecture and the other adopting a simpler light-weight
desktop-standalone architecture (spatialite is so light
that it runs even on Android and mobile devices).
I suppose that all this should be considered a rather
relevant advancement for the whole FLOSS and GFOSS cause.

bye Sandro