[postgis-devel] Canonical binary form AND WKB

[Markus Schaber]

Hi, Strk,

On Fri, 17 Dec 2004 12:19:40 +0100
strk at refractions.net wrote:

> One question is wheter make output of asBinary() *always* OGC
> compliant.

I vote pro this, because we do not get any problems whenever the OGC
WKB spec extends.

We still provide access to the full geometry information via our
canonical representations.

Did anybody have a look on how other DBs do? When there's a common
interpretation of 2.5D geometries (possibly like the preliminary spec
floating around on the net), this interpretation is likely to get
standardized soon or later, and we could have the heart to use this
extensions.

> This can be done internally forcing the geometries to 2d form.

Another alternative is to throw an error when the geometry is not OGC
compliant, and the user must explicitly apply force_2d() to the
geometry. This avoids silent loss of data. As, currently, 2.5D
geometries are a postgres extension, we can make the users call postgres
specific force_2d function to output standard conform WKB format.

The disadvantage is inefficiency, as the geometry is converted twice.

> Another question is how to distinguish between an OGC WKB
> (extended or not) and a canonical form, which are currently
> both of type bytea. 

IMHO, the user has to know what he does, to feed the right function.
OpenGIS standard mandates use of GeometryFromWKB(bytea) for feeding
standard compilant WKB, and the postgres canonical binary form can be
converted by other PostgreSQL/PostGIS specific ways to geometry.
(Autocast, feeding via V3 protocol as canonical binary rep, _recv()
function, ...).

All kind of magic that tries to distinguish the two binary formats by
some bit tests, sanity checks or alike is in the danger of failing as
soon as the OGC WKB format gets extended.

The most dangerous thing wr/t extending WKB acceptance is that once we
get such a collision and thus change the interpretation of
GeometryFromWKB(bytea) to use the new OGC WKB spec, old clients that
rely on the magic will fail. And if we have to tell the Programmers that
they should not rely on this behaviour, it is better to not accept it in
the first place.

But that's just my opinion.

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