[postgis-devel] A letter to the Postgis Developers and Packagers
strk at keybit.net
Mon Oct 19 08:23:28 PDT 2015
On Sun, Oct 18, 2015 at 08:52:14PM +0200, Andrea Peri wrote:
> We thought that the substitution of the PostGIS Topology functions from
> plpgsql in C would not cause any problems to users, offering
> instead performance improvements. But during its testing in Spatialite,
> we realized that the library required several further refirements in its API.
> This has created a situation of embarrassment that caused the break
> of the new liblwgeom API just in the same day it was released along
> with the new 2.2.0 version of PostGIS.
For the record, I think the liblwgeom API breakage was really not
a big deal, especially as what broke was the new topological API,
which is really only used by PostGIS itself (beside the ongoing
> We apologize for causing, with our interventions in liblwgeom, the
> release within PostGIS of a topological library that is not yet complete
> and which definitely needs several revisions and other changes to the API.
I don't think you can be blamed, the modifications entered the PostGIS
code base under my own responsibility so if someone feels it was an
error to introduce such change, the fault is all on myself.
Personally, I don't see any damage introduced with those changes.
Yes, there's been a performance regression, but those kind of things
tend to happen, and we've a fix for it already committed.
> Beeing in need of a more rapid test and release cycle for the topology
> library, and with the aim to create a library which is compatible with
> both PostGIS and Spatialite, we have identified as the best solution
> to carry out the development, test and release activities in a separate
> project. This choice also allows us to write the library with a thread-safe
> model, which is not needed by PostGIS.
Both adding thread-safety to the library and having a faster release
cycle are surely good reasons to have a separate package for the new
I've been hoping we could directly work at making liblwgeom itself turn
into such an external library, but I understand the evaluated risk for
increased cost of such a move makes other PSC members prefer not to
Note I do not think the fundings spent on liblwgeom integration were
wasted, as that allowed us to immediately prove the appropriateness
of the library API and its correctness against the existing PostGIS
Topology testsuite, which was also improved in the past thanks to
Tuscany Region funding. And moving the code elsewhere would now mostly
be a matter of renaming the symbols.
> As we fear the liblwgeom-topo code might be too immature and prone
> to API breakage, we offer to finance the recovery in PostGIS of the
> previous plpgsql implementation of the Topology module.
I think the API breakage issue could be as well fixed by excluding
the topological support from the published liblwgeom headers.
Having topology function implemented in C opens the door to further
improvements that aren't easy with the plpgsql.
Not knowing in advance when the external library will be ready,
I'd rather keep using the internal version until an alternative
There's a fair amount of code in the C topology module that doesn't
belong to the C topology library API (implementation of the callbacks
required by the library). That code will still be useful for using
the external library, shall it have a similar interface to the current
one (as I belive is the case).
If anyone else from the PSC prefers a revert, please speak up.
> The new topological library of Tuscany Region will be deposited on a
> distinct GIT repository, with an open license similar to that of
> liblwgeom and of course we will be pleased and honored if in the future,
> when it will be more robust and reliable, the Community of PostGIS
> Developers and Packagers will decide to link it as a shared library for the
> topological component functions.
I hope that'll be soon possible.
Thanks for your continued support to free software development!
More information about the postgis-devel