[postgis-devel] Common Code

Paul Ramsey pramsey at cleverelephant.ca
Tue Aug 9 07:40:34 PDT 2011


You think the proj caching is useful outside the pgsql context? 
Me == surprised

P.

On 2011-08-09, at 2:42 AM, Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk> wrote:

> On 08/08/11 17:55, Paul Ramsey wrote:
> 
>> We actually need two pieces of common code now.
>> 
>> - liblwgeom, which is already there, and Sandro is cleansing, is
>> common to geometry, raster, loader dumper, even the documentation
>> builder!
>> - postgis, which is what we currently call geometry/geography should
>> be an agnostic place were we have some utilities for caching call
>> information between calls (used by projection, prepared geometries,
>> etc) and other code that is common to all types, but has a dependency
>> on pgsql. In an "ideal" world, we would have: ?
>> 
>> ./liblwgeom
>> ./postgis/common
>> ./postgis/geometry
>> ./postgis/geography
>> ./postgis/raster
>> ./postgis/topology
>> ./postgis/geocoder
>> ./docs
>> 
>> Or something like that. In any event with raster in the pool the need
>> for a separated out utility library of pgsql-dependent things goes up.
>> 
>> P.
> 
> +0.5 which is nearly a +1 with some caveats ;)
> 
> I think the above directory structure is good, but there are a couple of extra things I'd like to push into liblwgeom: the projection cache and also the geometry 1D R-Tree code.
> 
> The reason for doing this is that it makes things much easier to test and benchmark outside of PostgreSQL and will also be a bit of value-add for people using liblwgeom outside of PostGIS.
> 
> Apologies that I haven't had much in the way of time to look at Bryce's patches, but I would envisage the liblwgeom projection API to look similar to this:
> 
> PROJ4Context = lwgeom_proj_context(char *fromproj4text, char *toproj4text);
> lwgeom_project(PROJ4Context *ctx,  G_GEOMETRY g);
> lwgeom_proj_context_destroy(PROJ4Context *ctx);
> 
> We can then handle the caching internally to liblwgeom and then simply store the context pointer within the fcinfo->flinfo->fn_extra to keep things really simple.
> 
> 
> 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
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list