[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