[postgis-devel] geos in liblwgeom

[Mark Cave-Ayland]

On 22/06/11 18:52, Paul Ramsey wrote:

> Mark,
> What do you think?
> http://trac.osgeo.org/postgis/ticket/1050
> P.

+100 (am I allowed to vote multiple times?) for both this and ticket #1053.

My long term aim for PostGIS with the liblwgeom abstraction was to be 
able to separate the database code from the PostGIS functions.

This gives us the following advantages:

- We can unit test (and debug) algorithms outside of the database, 
making finding memory leaks considerably easier

- We can potentially switch PostGIS to another database in a very short 
space of time

- Switching the underlying algorithm library (e.g. from GEOS to Boost) 
becomes easier

- We can also do cool stuff such as run GEOS tidy-up functions on 
invalid geometries within shp2pgsql (e.g. if an incoming geometry fails 
on parse, we can retry with looser parser flags, run a tidy function, 
emit a warning and verify the new geometry is then valid before 
outputting and continuing).

My long term plan is for the PostGIS functions to be simple wrappers 
that convert the serialized geometries into one of 
LWGEOM/GGEOMETRY/GEOGRAPHY, jump into liblwgeom to do the work, and then 
serialise the results back to the database. I don't think that all this 
will necessarily get done for 2.0, but I would definitely accept (and 
help review) patches that move in this direction.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs