[postgis-devel] LWgeom and PostGIS Java classes

[Markus Schaber]

Hi, Strk,

On Wed, 15 Dec 2004 14:29:31 +0100
strk at refractions.net wrote:

> > Imagine a query like "select geom, asText(geom), asBinary(geom) from
> > table". This should return the clients preferred object representation,
> > a String containing WKT and a byte array containing the WKB rep.
> 
> You'd get SRID+HEXWKB, WKT, WKB.

Which the jdbc driver with the appropriate extension would transform
into an instance of appropriate org.postgis.Geometry subclass, a String,
and a byte[].

> > Also imagine that an user gets this representation, and uses it while
> > inserting into another table. So this representation should not lose
> > information like the SRID. It seems weird that you read an object, and
> > re-insertion of exactly the same object fails because of a SRID
> > constraint violation.
> 
> This would only happen for binary transfers, as canonical text
> transfer would include SRID.

So this tells me that driver extension writers cannot use binary
transfer for lossless postgres-data to object mapping.

> Note that geometry_send() does not include the SRID though.

Would it be possible to add the SRID to geometry_send? How much third
party applications are there that already depend on the internal
representation? (I guess none.)

A way I could imagine would be to add the 4 byte ASCII text "SRID" plus
4 bytes int containing the actual SRID after the WKB. As the WKB
contains counters for all arrays in it, a non-srid aware parser will
simply ignore those extra bytes.

> > For write support, the situation is a little more difficult. Currently,
> > the just-to-be serialized geometry object does not know which PostGIS
> > version works on the server side. As, AFAIK, the current parser can read
> > both text rep versions, we can simply use the old (SRID;WKT) format by
> > default, and provide a switch for the user to trigger the new, more
> > efficient format. For binary canonical rep, I have not thought so far.
> 
> You can query postgis_version().

During being serialized, a PG_Object subclass does not have access to
the connection the serialized data will be sent over. Additionally,
wildly sending queries from inside a driver extension may give
additional problems. For example, it may be impossible to send a query
at that specific moment (e. g. because the current transaction is in an
invalid state after an error) but will be rollback()ed before my own
statement is sent.

However, the client software itself can query postgis_version, and then
set a switch which binary format is used (should there ever be more than
the current).

It seems that I need to think some more about it, but my ideas are
maturing, and your comments are very helpful.

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