[postgis-devel] LWgeom and PostGIS Java classes

[strk at refractions.net]

On Thu, Dec 16, 2004 at 12:58:52PM +0100, Markus Schaber wrote:
> Hi, strk,
> 
> On Thu, 16 Dec 2004 12:38:54 +0100
> strk at refractions.net wrote:
> 
> > We do *not* have a canonical binary rep yet. That's what I'm working now ;)
> 
> Oh, and I thought the "WKB + ZM bits" was intended to be the canonical
> binary rep :-)

That's the "extended" WKB.
Actually since we "extend" we might as well add the SRID there...
If you want a 'pure' WKB you currently have to
	SELECT asbinary(force_2d(geom))
to avoid ZM ...
Embedding a SRID would mean requiring to run
	SELECT asbinary(dropBBOX(setSRID(force_2d(geom), -1)));

.. of course we might as well have asBinary(geom) *always* return
'pure' WKB and rely on canonical (text or binary) forms for
postgis extensions .. (should keep discussing this on postgis-devel).


> > Maybe just adding byte order (of the server host) to the internal
> > representaion would make the smartest "canonical binary" form for
> > sending and receiving. What do you think ?
> 
> I think that would be a good solution. As all bits of the first byte are
> already defined, simply precede another byte that has two bits defining
> the byte order for integers and doubles. (Those may differ on some weird
> hosts.) Then we still have 6 bits left for defining a version or further
> extensions, should this ever get needed. 
> 
> This way, geometry_send() is basically to write a compile-time constant
> and memcopy() the internal rep thereafter.
> 
> Receiving will, of course, have to do some byte reordering if necessary.

This is already the case for any "canonical form".
If you want to control ordering you have to use OGC
	asBinary(geometry, 'XDR'|'NDR')

.. see above for extended WKB ...

> 
> > > BTW, has anyone ever used two different PostGIS versions in the same
> > > Postmaster? Of course, they have to be in different databases, but
> > > as all datatypes and functions are defined per database, and the
> > > .so-names differ, it should be possible.
> > 
> > Sure. I do. It is possible. You'll only have trouble with the loader
> > as it is not compatible with both versions.
> > (you can use the LWGEOM dumper for both HWGEOM and LWGEOM)
> 
> I only hope that I don't get conflicts for the GEOS and ProJ versions (I
> would try to run current 1.0beta CVS branch additionally to 0.8.1
> currently running).

postgis 1.0beta should run with any GEOS version.
If you upgrade GEOS 0.8.1 will fail to work, but 0.9.1 should.

> Thanks a lot. Should we ever meet in real life, remember me to invite
> you for a beer and pizza or whatever you prefer.

pushed on the stack, thanks.
--strk;

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