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

[Aron Olsen]

Hi Markus,

Thank you for those answers. 

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

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

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

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

Aron.

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

Hi, Aron,

Aron Olsen wrote:

> I did try to use the driver-extension / wrapper, but I couldn't get it to
> work with JTS 1.6 (maybe because the extension was written for a JTS 1.6
> beta release, or maybe it was because our current PostGres/PostGis version
> was too old - I can't remember exactly why).

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.

> Anyway, I think its better not to be dependent on a certain driver, and
that
> is what I believe I have achieved. Can I rely on, that if I use the
"plain"
> driver, then I can always get geometries via PGobjects without having to
use
> special SQL-syntax ?

What do you mean with "plain" driver? The plain pgjdbc driver without
PostGIS extensions?

No, I'm not shure you can. You know, as soon as the postgis.jar is in
the classpath, newer pgjdbc drivers autoregister the postgis extension,
and this mechanism may change in the future. So your application may
break unexpectedly in future setups.

Second, it is not guaranteed that PostGIS will keep hexewkb as the
canonical rep, at least with major releases the canonical rep is likely
to change (as just happened between 0.X and 1.X).

That's the reason why we use drivers - they can abstract over this changes.

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.

> The nice thing with PGobject / hex-encoded WKB is that you are completely
> independent of a specific Geometry-model (except that one will need to
> re-write XXXParser and XXXWriter for every Geometry-model you want to
use).

And the PostGIS Driver just implements three of those geometry models
(PostGIS own, JTS and Java2D).

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