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

[Aron Olsen]

Hi Markus,

And thanks again. Very enlightening!

For the time being I'm stuck with my own coding, but of course I want to
become "flying".
 
I really want to have geometries transferred in the most efficient way and
have them instantiated (efficiently) according to my geometry model of
preference. The "real" problem boils down to allocating arrays of
coordinates. We don't want to re-allocate and re-instantiate or even
stringenize/parse. JTS does not have an interface for Coordinate - it's a
class. You can get as close as CoordinateSequence, but that's it.

Furthermore, a specific geometry model may have constraints on its
willingness to construct "invalid" geometries. Thus, you may have no room
for fixing errors in invalid geometries using a specific model.
"We" need a neutral common format (and that is bits and bytes if you ask
me). 

I will have a closer look at what is available in PostGIS-driver-ext when I
can find the time (I'm just too busy with our project right now, and here
everything is posted and retrieved as JTS - good or bad).

Anyway, have you ever considered supporting JDBC-structs ?
 
Regards,
Aron.



-----Original Message-----
From: Markus Schaber [mailto:schabi at logix-tt.com] 
Sent: 18. januar 2006 14:20
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] JDBC: Setting/Getting JTS-geometries using bi
nd-vars

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