[postgis-devel] liblwgeom.so

Bryce L Nordgren bnordgren at gmail.com
Fri Sep 9 12:22:50 PDT 2011


On Fri, Sep 9, 2011 at 5:33 PM, Paul Ramsey <pramsey at cleverelephant.ca>wrote:

* We are a PgSQL extension, not a third-party library. If this
> actually "succeeds" in getting people using liblwgeom, it also "fails"
> in that now we have to, in addition to doing our own work as PostGIS
> developers, ensure we don't break other people's work. If we do change
> things all the time and people don't use us, then we don't "succeed",
> so the "let other people use liblwgeom" argument fails.
>
>
You already have to ensure you don't break other people's work: you must
keep the faith with the interface contracts of your SQL functions. :) The
difference between liblwgeom (private) and liblwgeom (public) is the size of
your public API, not "no API vs API". Whether internal-only or shared,
you're going to want to strive for a *stable *liblwgeom API.

Now I think the real question is "is it worth sharing"? To be honest, I
don't know what features are offered by the various libraries out there. It
sounds like there is some postgis-unique enhanced validity checking in
liblwgeom not present in other libraries, and not easily integrated into
GEOS/OGR/etc. If it was a rational thing to do, I'd argue for offloading the
geometry burden altogether: to GEOS or OGR; writing the extra postgis
functionality on top of one of these foundations. This would mean that
postgis doesn't need to maintain its own wkt/wkb parser, its own internal
geometry format, its own roundtrip translations to an external geometry type
where the heavy lifting is done... I don't know whether the functional
requirements would make this a rational long term goal or not. But in my
opinion, if liblwgeom adds no unique capabilities, it should disappear over
time; if it has something that others do not, it should be shared. The
mechanism of sharing may be: 1] installed as a shared library systemwide; 2]
forked as a separate project; or 3] assimilated into an existing separate
project. ..and if you start with #1, declaring your intentions to migrate to
#3, well, your users have been warned.

One thing that occurs to me is that with a separate liblwgeom (complete with
serialization functions), it becomes possible to write "compatible"
postgresql extensions. For instance, if no one here wants my raster iterator
engine, I can write a completely separate postgresql extension which can
read and write postgis-compatible geometries to the database. It would be
awful nice if the raster serialization stuff was in there too: in fact, I'd
want everything required to interact with database objects supported by
PostGIS. If you don't do that, then everyone wanting to extend functionality
or datatypes must plan on modifying the postgis code base itself. Not so
modular. Icky. So I guess the thing liblwgeom has which no other libraries
have is the ability to support postgis-compatible postgresql modules.


W.r.t. rearranging (dustymugs): I see the contents of liblwgeom as a
separate issue from whether or not liblwgeom is shared separately from
PostGIS. But I think that voting on whether liblwgeom should have
accumulated the functions it did (which is what it looked like you were
objecting to) is kind of moot at this point. The evil deed is done. We
(y'all) can take away some lessons learned about how to better approach
similar changes in the future. But with the rearranging, your potential
contributors have the option of hearing something other than:

1] "No, it duplicates code"; or
2] "No, we don't want to rearrange"

..that is, if they make it past the stage of being so totally aggravated
that they have to reinvent supporting code which is already in the codebase,
but which is unusable... :)

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20110909/f8f94f95/attachment.html>


More information about the postgis-devel mailing list