[postgis-devel] Canonical binary form AND WKB

strk at refractions.net strk at refractions.net
Mon Dec 20 03:34:50 PST 2004


On Mon, Dec 20, 2004 at 11:11:05AM -0000, Mark Cave-Ayland wrote:
> 
> > -----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: 20 December 2004 10:39
> > To: 'PostGIS Development Discussion'
> > Subject: Re: [postgis-devel] Canonical binary form AND WKB
> > 
> > 
> > I don't really feel comportable with all these formats.
> > Having added a 'canonical binary' represent yet another 
> > format which will need to be parsed in both XDR and NDR forms...
> > 
> > The cleanest thing to do would probably be supporting 
> > something like the following:
> > 
> > 		-- OGC interfaces --
> > 	    ascii WKT - GeomFromText / asText 
> > 	   binary WKB - GeomFromWKB / asBinary
> > 
> > 		-- POSTGIS interfaces --
> > 	   ascii EWKT - asEWKT / fromEWKT / geometry_in
> > 	  binary EWKB - asEWKB / fromEWKB / geometry_send / 
> > geometry_recv
> > 	ascii HEXEWKB - geometry_out / geometry_in
> > 
> > Where EWKT and (HEX)EWKB should have a SRID added (currently 
> > only ZM flags "extend" the OGC spec).
> > 
> > Does it sound cleaner ?
> > 
> > --strk;
> 
> 
> Hi strk,
> 
> I was thinking about this over the weekend and came to a similar conclusion,
> although I was considering using the native LWGEOM structure for speed when
> dumping/reloading. However I don't believe the LWGEOM structure has a byte
> that indicates the endian-ness of the data, where as EWK* forms do. Your
> idea will allow dumps to be restored across different architectures, which
> is obviously a "must have" feature, while helping simplify the code -
> however, I think we will need to include code for byte-flipping in the EWK*
> functions....

An option would be making the native LWGEOM *be* (HEX)EWKB (just adding
byte order - as current canonical binary do).
Pros: faster input/output, already structured SRID inclusion.
Cons: needs implementation of byte-flipping, 'constraints' internal
      representation for future releases.

--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



More information about the postgis-devel mailing list