[postgis-devel] LWgeom and PostGIS Java classes

[strk at refractions.net]

On Wed, Dec 15, 2004 at 02:08:11PM +0100, Markus Schaber wrote:
> 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.

Both use canonical text representation.

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

It does (for LWGEOM). WKB type has been dropped.

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

You'd get SRID+HEXWKB, WKT, WKB.

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

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

You have to test this, I dunno how would the server tag that.
Note that geometry_send() does not include the SRID though.

> 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().

> 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

Thank you for look aheads.
--strk;

> 
> -- 
> 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
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel