[postgis-devel] liblwgeom.so

[Paul Ramsey]

On Mon, Sep 12, 2011 at 3:30 PM, Bryce L Nordgren <bnordgren at gmail.com> wrote:
> On Mon, Sep 12, 2011 at 8:52 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>>> 2) Ability to offer some aspects of PostGIS API externally for people
>>> writing their own custom converters/importers
>>
>> I feel like a better approach for the overall foss4g ecosystem, and
>> for our own internal work would be to have those aspects of the API in
>> OGR, which is already a system level utility library.
>
> My original thought with #2 was not limited to custom
> converters/importers: It is my impression that if anyone, anywhere is
> to have even the option of writing a postgresql module which interacts
> with geometry, raster, or topology data types, they have to have
> access to your serialization/deserialization routines (and probably
> your accessors and/or methods). Adding this to OGR doesn't seem to be
> aligned with OGR's mission.

No, postgis serializations aren't anyone's mission but our own.
However, OGR's mission could certainly encompass geometry cleaning
algorithms of the sort strk wants to share with spatialite and qgis.

> Failing to provide this is like postgresql failing to provide a way to
> detoast an int. :) Or keeping the plus operator "server-private".
>
> So: Is there a non-system-liblwgeom way to detoast a geometry from a
> non-postgis module? If so, I'm a happy camper.

mynewtype::bytea:;geometry

Passing through the canonical form is far less likely to get broken
over time than trying to guess what we're doing with our form,
particularly now that we have access to a whole new pile of flags to
layer conditional behaviour into our form without causing a backwards
breaking change.

P.