[postgis-devel] LWgeom and PostGIS Java classes

[strk at refractions.net]

On Fri, Dec 17, 2004 at 10:28:21AM +0100, Markus Schaber wrote:
> Hi, strk,
> 
> On Fri, 17 Dec 2004 08:45:06 +0100
> strk at refractions.net wrote:
> 
> > > The canonical forms should be "lossless", as close to the internal rep
> > > as feasible (for efficiency reasons), provide all PostGIS features and
> > > extensions, and are subject to change between PostGIS releases.
> > 
> > If we don't want to loose "features" we'll have to provide a function
> > returning the "lossless" canonical binary form in a specific byte order.
> 
> I think it is sufficient to include information about the used byte
> order.
> 
> This way, only the reader has to convert if necessary. This avoids
> situations where both ends have to convert the byte order. And most developers will transport data only bet
> 
> > This is for both byte order control and PG<74 support, where there were
> > no _send and _recv functions.
> 
> I thought pg<74 (the V2 query protocol) does not support canonical
> binary forms at all. But I may be wrong. If I'm right, a question is
> whether it is worth to provide a workaround for this, or simply stick to
> the text canonical form on those platforms.
> 
> Thanks,
> Markus

Ok, I've implemented the canonical binary form in terms of bytea<->geometry
casts. As you can see below this allows lossless conversion from one 
to the other representation.

strk=# select summary(addbbox('SRID=4;POINT(0 0 0 4)'::geometry)::bytea::geometry);
    summary
---------------

Point[ZMBS]


This have been set to be _send and _recv funx for PG>73, and are
still available as a fast lossless trasfer mean for PG<74.

The problem is now on GeometryFromWKB(bytea), which should 
be smart enough to distinguish between canonical form bytea and
extended WKB bytea (both are bytea types).

This could be done adding support for SRID and BBOX presence flags
in the uint32 type ...


--strk;