[postgis-devel] Canonical binary form AND WKB

[Mark Cave-Ayland]

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: 21 December 2004 15:23
> To: Markus Schaber
> Cc: PostGIS Development Discussion
> Subject: Re: [postgis-devel] Canonical binary form AND WKB

(cut)

> Ok. I've reverted canonical binary form (and bytea casts) 
> back to EWKB input/output and extended EWKB with a SRID 
> presence flag and int4 storage (if present) right after wkbtype.

So basically EKWB is our "on the wire" version of LWGEOM, but abstracted so
that if we change LWGEOM internally, it won't have a knock-on effect on
EWKB.

> HEXEWKB does not need SRID=#; anymore, but still accepts it 
> for old dumps.

Great. If we can't read the geometry, there seems little point in having the
SRID in readable format ;)

> What is left now is *strict* OGC WKB I/O.
> For output we can just *downgrade* geometries to be OGC 
> compliant (strip Z,M and SRID) very easily. For input I'm 
> afraid we'll need a separate parser, to allow for EWKB 
> <future>WKB clashes. I guess this can be done when WKB-ng is 
> out (why run?).

Great, so at least we are now import/export compliant. Perhaps Extended
WKB/WKT are slightly misleading names.... Other than that, I think we need
to document why we made all the decisions leading up to this, and give clear
definitions of LWGEOM, EWKB/T etc. and confirm the strict OGC-compliancy of
the existing functions.

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