[postgis-devel] JDBC: Setting/Getting JTS-geometries using bi nd-vars

[Markus Schaber]

Hi, Aron,

Aron Olsen wrote:

>>It would be good to send us the exact problem description if you can
>>affort to re-try, so I can try to fix it.
> 
> When I get the opportunity I will try it again, and let you know how it
> goes.

Thanks.

>>What do you mean with "plain" driver? The plain pgjdbc driver without
>>PostGIS extensions?
> 
> Sorry. Of course I'm using the PostGIS extension. I that moment, when I was
> testing, I wasn't realizing that the PGgeometry was so tightly bound to the
> PostGIS extension.

Yes, PGgeometry is part of the PostGIS extension, and subclassing the
PGobject class from pgjdbc.

>>The only reliable way to get a specific geometry representation are the
>>OpenGIS compliant asText() and asBinary() as well as the PostGIS
>>specific asEWKT() and asEWKB() functions.
> 
> Ok. As I understand it "asText()" and "asBinary()" affects the way the
> server will deliver geometry-objects to a client...

Yes. asText() and asEWKT() convert the geometry to a text (String)
containing the text representation, asBinary() and asEWKB() convert the
geometry to a bytearray containing the binary representation.

So when issuing a statement like

  SELECT geom, asText(geom), asBinary(geom) FROM table;

the server tells the client that the first column of the resultset is of
type geometry, the second column is of type text, and the third column
is of type bytearray.

The PostGIS/PGobject mechanism kicks in whenever the type "geometry" is
sent to the client, this is why asText() returns a String in
ResultSet.getObject().

>>And the PostGIS Driver just implements three of those geometry models
>>(PostGIS own, JTS and Java2D).
>  
> ..and with PostGIS there is no "default"/"common" representation of a
> geometry-object, when you are dealing with a JDBC-resultset (?).

No, there isn't, but this is not JDBC specific. The so-called "canonical
representation" of type "geometry" is implementation specific and has
changed from WKT-like in PostGIS 0.X to a hex-encoded extended WKB
variant with PostGIS 1.X.

So applications basically have three possibilities:

- use the accessor functions like asText() and get the data as text /
  bytarrays (which is the OpenGIS compliant way)

- use geometry directly and have driver extensions like postgis.jar
  handle the different server representations more-or-less transparently

- use geometry directly without any driver extension and handle the
  different server representations yourself

Maybe we could add a postgreslq session config variable that allows the
user to change the behaviour of the canonical rep, but AFAIR no work has
been done in this direction.

HTH,
Markus
-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org