[postgis-devel] Canonical binary form AND WKB

[strk at refractions.net]

On Fri, Dec 17, 2004 at 04:55:26PM -0000, Mark Cave-Ayland wrote:
> Hi strk, 
> 
> > -----Original Message-----
> > From: postgis-devel-bounces at postgis.refractions.net 
> > [mailto:postgis-devel-bounces at postgis.refractions.net] On 
> > Behalf Of strk at refractions.net
> > Sent: 17 December 2004 11:20
> > To: postgis-devel at postgis.refractions.net
> > Subject: [postgis-devel] Canonical binary form AND WKB
> > 
> > 
> > Changed subject and started new thread to reflect discussion.
> > 
> > A 'canonical binary' representation has been defined for 
> > LWGEOM, being the exact internal representation with an 
> > additional inizial byte specifying byte order:
> > 
> > 	0 : XDR : big endian
> > 	1 : NDR : little endian
> > 
> > These are available with a cast to/from bytea, and are fast
> > and lossless conversions.
> > Bytes flipping is unsupported in both forward and backward 
> > conversions.
> > 
> > WKB is another binary representation, again encoded as a 
> > bytea but different from the canonical binary representation 
> > in that it does not contain a SRID. WKB can be produced and 
> > accepted in both XDR and NDR form. It's implementation is 
> > currently slow. It understands an 'extended' OGC WKB 
> > including 3dz, 3dm and 4d geometries.
> > 
> > One question is wheter make output of asBinary() *always* OGC 
> > compliant. This can be done internally forcing the geometries 
> > to 2d form.
> 
> I think we should stick to the OGC standard, no matter how bad it is, purely
> so we know that anything we export can be imported into another OGC
> compliant application. One thing we could consider is to overload the
> asBinary() function such as asBinary(geometry, 'EWKB') which would output
> the extended WKB format for applications that need it, containing all the
> extended attributes needed for 3dz, 3dm and 4d geometries.
>
> I guess we should make this extended type the default for the LWGEOM_in/out
> functions (if this isn't already the case) so that geometries can be
> correctly dumped/restored to/from a database across endian architectures.

LWGEOM_in/_out are meant for ascii transfers.
LWGEOM_send/_receive are meant for binary tranfers.

LWGEOM_out gives canonical ascii (Z,M,SRID)
LWGEOM_int accepts canonical ascii and EWKT (ie: 'SRID=2;POINTM(0 0 0)')

> > Another question is how to distinguish between an OGC WKB 
> > (extended or not) and a canonical form, which are currently 
> > both of type bytea. 
> 
> The only option I can think of would be to change the canonical form endian
> identifiers from 0x00/0x01 to something like 0x80/0x81; then if the first
> byte > 0x80 then we know we are dealing with canonical form, otherwise we
> assume it is (E)WKB. Having said that, is it possible to tell the difference
> between EWKB and WKB?

I agree with Markus actually... if OGC will extend WKB we'll end up
with bad conflicts between our extension and their extension.
We'd better leave WKB forms driven by OGC and just use byte casts
and _recv/_send for out own extensions.

This would mean *dropping* EWKB support as a whole and document
canonical binary form for clients willing to support that.
Also the same thing should be done with EWKT in GeometryFromWKT().

geomFromWKB(asBinary(geom)): would then make the geometry OGC-compliant
			     dropping Z,M and SRID

geometry(bytea(geom)): would keep all extensions

... providing strict WKB will be easy, but suppressing acceptance 
of EWKB and EWKT will be problematic ...

--strk;

> 
> 
> Kind regards,
> 
> Mark.
> 
> ------------------------
> WebBased Ltd
> South West Technology Centre
> Tamar Science Park
> Plymouth
> PL6 8BT 
> 
> T: +44 (0)1752 791021
> F: +44 (0)1752 791023
> W: http://www.webbased.co.uk
> 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel