[postgis-devel] Canonical binary form AND WKB

Markus Schaber schabios at logi-track.com
Mon Dec 20 06:35:05 PST 2004


Hi, strk,

On Sat, 18 Dec 2004 10:41:41 +0100
strk at refractions.net wrote:

> That would be the best solution, as it seems to be getting a mess
> with all these representation:
> WKB, EWKB, HEXEWKB, internal, canonical binary, WKT, EWKT

Then lets try to get rid of some of them, and simplify the others.

Add the endian bit to internal representation, so internal and canonical
binary get the same. (Always convert to machine byte order on geometry
input so we do not have any speed issues, and do no conversion on
output. Maybe we should make sure that we have space reserved for some
additional bits for future extensions).

Make canonical text a straight hex(canonical binary), instead of
adding the SRID with a ';'.

So I see four "real" representations left:

- internal == canonical binary == unhex(canonical text).

- OGC WKB 

- OGC WKT

- Old SRID=42;EWKT format, for canonical text input only

Canonical binary should be as efficient as possible. We cannot abandon
the OGC formats, obviously, and the old format has to be maintained for
restoring old dumps.

Old format can use the same parser as WKT after splitting the SRID part.

Maybe the canonical binary and WKB parsers can share some code,
especially endianness conversion.

This approach should be the leanest.

But I'm pretty shure I forgot some important use case :-)

HTH,
Markus

-- 
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios at logi-track.com | www.logi-track.com



More information about the postgis-devel mailing list