[postgis-devel] LWgeom and PostGIS Java classes

[Markus Schaber]

Hi, Strk,

This mail is a rather wild bunch of thoughts. I think I have to breed
them some more time, but I also do want to share them with the list. So
please take it all with some grain of salt, and feel free to comment or
flame.

On Mon, 13 Dec 2004 18:27:53 +0100
strk at refractions.net wrote:

> 	- Text form is hexized extended WKB + SRID
> 	- Binary form is bytea extended WKB

This means that the binary form always drops the SRID. Do pg_dump -Ft
and pg_dump -Fc use the text from? If not, dumping and reloading a
database could silently lose the SRID information, or fail because of a
constraint violation.

> You should always use asBinary,asText to ensure compatibility
> with future releases. In this specific release (1.0) using
> a BINARY cursor on a plain geometry field will give you bytea
> extended WKB (as for 'send' specification of geometry type).


I think this is valid for OpenGIS compatible applications. Those
explicitly fetch their preferred representation and the SRID, and so are
completely independent from the DB vendor. This is supposed to even work
through JDBC, ODBC or other layers that are not aware of GIS data types.
So, IMHO, asBinary should return bytea as generic data type instead of
wkb, because the application does want it that way, and intermediate
layers don't know anything about a wkb type.

However, the PostGIS jdbc classes are a different case. They are generic
driver extensions that are supposed to read and write an object
representation of GIS objects. They don't know in advance which of the
text columns contains a WKT Geometry, and so they have to rely on the
server providing the column data type. 

The user of this extension can simply call ResultSet.getObject(col) and
get a directly usable object representation of the geometry, and does
not have to fiddle with WKT/WKB parsing etc. That's the whole point of
those classes, as far as I understood them.

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.

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.

Thus, this driver extension has to rely on the server-provided column
data type, and thus automatically gets in contact with the canonical
representation. I do not see a big problem on depending on this
quasi-internal representation as the driver extension is part of the
postgis distribution. 

Compatibility for clients should be first priority (so they can simply
upgrade to a new PostGIS version by using a new PostGIS.jar).
Compatibility to older server-side PostGIS versions is good (especially
for clients working with different servers at the same time), but can be
abandoned if not feasible. 

Currently, read support for both text representations is no problem (as
they are easily distinguishable by looking at the text). If the server
puts "geometry" as datatype for the bytea delivered by geometry_send()
on V3 connections, supporting a representation should be possible, too.

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.

Note that, because of some drawbacks in the pgjdbc extension system, the
current support is suboptimal in two points: It needs a wrapper class
for read access, and it only works with text representations of the
canonical form. I'm trying to work and advocate to remove those limits,
as the pgjdbc driver currently grows into full V3 protocol support. See
the appropriate threads on <pgsql-jdbc at postgresql.org>. Also, SRID
support in the current java code is not fully implemented, but that
seems a simple matter of adding some lines of java code. 

My thoughts are (at least intended to be) a bit more into the future,
and also for other driver writers (python, C++) that want to provide a
transparent wrapping for GIS types.



Thanks for your patience,
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