[postgis-devel] Re-organising the PostGIS codebase - to liblwgeom or not liblwgeom?

[Paul Ramsey]

My take:

1- PGXS, good, follow the big fish...

2- liblwgeom, unsure, leaning negative

Some of the questions I have seen on the list about the wrappering of
types, and my own reading of functions has made me less than enamoured
of the abstraction layer.  The trouble is that is violates YAGNI (my
new personal religion). No one has asked us for this, no one is using
it *currently*, so why should we add complexity to our own code to
support it?

If we want do so any separation of concerns, I would lean towards a
very very simple geometry algorithm library in pure C, statically
linked, for things like our length/distance/pip/area and other
routines. Otherwise I would be on the side of doing away with the
liblwpostgis separation.

3- branch trunk or branch development

I think we can branch trunk to 1.3.x and let development march on
trunk. That means we're committing to get a bunch of big changes
through and stabilized before we get to 1.4... hope we're OK with
that.

I lean towards the above because that way we can all watch/help as you
start moving things around.

Paul

On Thu, Apr 24, 2008 at 4:18 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Hi folks,
>
>  Just an update: after some initial hacking, I have managed to get knock
> together some test Makefiles that will build PostGIS using PGXS. The good
> news is that the build system is considerably simpler, and means we don't
> have to worry about keeping sync with the PostgreSQL build files.
>
>  The next question I have come across is related to liblwgeom: for those
> people who don't know, when PostGIS was re-written to use LWGEOMs, there was
> a concept that the basic geometry library would be separate from PostGIS and
> that majority of PostGIS was a set of PostgreSQL wrappers for this library.
>
>  The advantage of this approach would be that if people wanted to use
> LWGEOMs and/or PostGIS functions within their own programs from C, then they
> could do so. I know that there has been mention of people wanting to use
> PostGIS functionality within SQL-Lite on the mailing lists; if they could
> link to liblwgeom separately then it would considerably reduce the amount of
> work needed.
>
>  Having played with this idea in my testbed, we need to decide on a few
> issues:
>
>
>  1) Are people happy that this should be the way forward?
>
>  I haven't heard much in the way of comment, positive or negative, about the
> plan to re-organise the codebase. Should I take that has implicit agreement?
>
>  2) Do we wish to maintain the liblwgeom abstraction?
>
>  I'm leaning towards thinking that this is a good idea in terms of code
> re-use and unit testing. If so, should we link statically or dynamically
> with PostGIS? With dynamic linking, we would need to supply 2 library files
> rather than the 1 file with a standard PostGIS installation, but it would
> potentially be easier for other people to use.
>
>  3) Merging of code into SVN
>
>  I've done some experiments with regard to the abstraction, and there are
> two main work tasks: the first is to create the initial abstraction in the
> build system of which I have a very basic version here (statically linking
> into liblwgeom), and the second is to then re-arrange both liblwgeom and
> PostGIS by moving functionality into liblwgeom.
>
>  From a development point of view, it would be best to branch 1.3.x and get
> this into SVN HEAD as soon as possible - however I appreciate that this
> round of changes will be quite invasive. I'm happy to work in a separate
> branch to begin with and then switch over to HEAD when the majority of
> things are working. Does that sound reasonable?
>
>
>  Comments, questions etc.?
>
>
>  ATB,
>
>  Mark.
>
>  --
>  Mark Cave-Ayland
>  Sirius Corporation - The Open Source Experts
>  http://www.siriusit.co.uk
>  T: +44 870 608 0063
>  _______________________________________________
>  postgis-devel mailing list
>  postgis-devel at postgis.refractions.net
>  http://postgis.refractions.net/mailman/listinfo/postgis-devel
>