[postgis-devel] Moving some algorithms into liblwgeom

[Mark Cave-Ayland]

On 13/11/12 20:18, J Smith wrote:

> G'day list.
>
> The recent talk about python and ctypes[1] has got me to thinking it
> would be pretty slick to be able to wrap python (or in my case, ruby)
> around liblwgeom and have access to the various algorithms available
> in liblwgeom. I have already written a ruby gem that wraps the
> functionality of GEOS in an FFI interface called ffi-geos[2] and I
> think it would be pretty sweet to also wrap liblwgeom in a similar
> manner. I had already begun the process of implementing some of the
> algorithms available in PostGIS such as ST_SnapToGrid in native ruby
> code using PostGIS as a guide, but it would be even nicer I think to
> wrap the actual PostGIS implementations themselves.
>
> I took a look at the source for ST_SnapToGrid as an example and notice
> that the implementation of the various grid snapping functions are
> currently in the postgis directory and not actually a part of
> liblwgeom. I extracted the relevant functions from the postgis
> directory and put them into liblwgeom, replaced the calls to palloc,
> pfree, etc., elog, POSTGIS_DEBUG and so forth with their equivalent
> calls such as lwalloc, lwerror, LWDEBUG and the like and got the grid
> functions working in liblwgeom on their own. The PostGIS functions
> themselves reference them accordingly and everything seems to work
> fine (no regressions after a "make check" at least, and I notice that
> ST_SnapToGrid is used all over the place in the regression tests, so
> that's a good sign.)
>
> I then wrote the necessary wrapper code in ruby for the gridspec
> struct and the calls to the lwgeom_grid and things look good -- I'm
> now able to call something like the following in ruby:
>
> LWGeom::Geometry.new('POINT (10.10 20.20)').snap_to_grid(1)
>
> And that's pretty cool.
>
> The question is, would there be any interest in moving some these
> sorts of algorithms out of the postgis directory and into liblwgeom so
> they can be called directly from code linked to liblwgeom? I've only
> taken a look at the snap to grid code because it seemed to be a good
> starting point given how often it gets used in the regression tests,
> but I'd be interested in moving similar code into liblwgeom.
>
> Thoughts or suggestions? Seems like it would be a cool project, and I
> like the idea of having access to PostGIS' spatial functions and
> algorithms in C from my ruby code. (And perhaps python and whatever
> else.)

This is actually something that I've had in the back of my mind for a 
while, but haven't had much of a chance to work on unfortunately. The 
idea was that we could put most of the functionality into liblwgeom, and 
then PostGIS becomes a thin wrapper onto the library. In particular, 
regression testing and memory leaks are a lot easier to locate/debug 
this way.

One thing that has been discussed is the stability of the liblwgeom API 
- at the moment, we don't need to worry about this as it is still 
considered an internal interface. But my original concept was that 
people could wrap parts of liblwgeom to help write processing/conversion 
scripts, e.g. detecting geometry validity without having to use the 
database.

I think if you focus on making the underlying liblwgeom wrappable, 
rather than a fixed API, then I personally wouldn't object to patches 
moving in this direction.


ATB,

Mark.