different results from PGobject.getValue()

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

different results from PGobject.getValue()

Claude Eisenhut
Is it expected behaviour that PGobject.getValue() returns different results,
depending if postgis.jar is on the classpath?

without postgis.jar PGobject.getValue() returns

01010000201555000052B81E85A50E2341B81E85EB3B330F41

with postgis.jar PGobject.getValue() returns

SRID=21781;POINT(624466.76 255591.49)

client
postgresql-8.2-504.jdbc3.jar
postgis.jar (snapshot 2007-01-29)

server
postgis_lib_version() 1.0.4

Claude Eisenhut


Reply | Threaded
Open this post in threaded view
|

Re: different results from PGobject.getValue()

Markus Schaber
Hi, Claude,

"Claude Eisenhut" <[hidden email]> wrote:

> Is it expected behaviour that PGobject.getValue() returns different results,
> depending if postgis.jar is on the classpath?
>
> without postgis.jar PGobject.getValue() returns
> 01010000201555000052B81E85A50E2341B81E85EB3B330F41
>
> with postgis.jar PGobject.getValue() returns
> SRID=21781;POINT(624466.76 255591.49)

Yes, it is expected.

If you don't have PostGIS installed, then PGObject just memorizes the
data String sent by the server.

When you have PostGIS in your classpath, org.postgis.PGgeometry is
automagically registered, and used for Geometry objects. By default,
getValue() returns the EWKT format which is compatible with PostGIS 0.8
and up. You can manually register org.postgis.PGgeometryLW as handler
class, which returns the hex-Binary form you see above, but only works
with PostGIS 1.X and above.


Regards,
Markus

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

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

Reply | Threaded
Open this post in threaded view
|

Re: different results from PGobject.getValue()

Claude Eisenhut

> > Is it expected behaviour that PGobject.getValue() returns different
results,
> > depending if postgis.jar is on the classpath?
>
> Yes, it is expected.
>

I would prefer, if the semantic of the base is not changed.
Why not a different function in PGgeometry?

Claude



Reply | Threaded
Open this post in threaded view
|

Re: different results from PGobject.getValue()

Markus Schaber
Hi, Claude,

"Claude Eisenhut" <[hidden email]> wrote:

> > > Is it expected behaviour that PGobject.getValue() returns different
> results,
> > > depending if postgis.jar is on the classpath?
> >
> > Yes, it is expected.
>
> I would prefer, if the semantic of the base is not changed.
> Why not a different function in PGgeometry?

Because the semantic for "getValue()" is "give me the string
representation of whatever the server can parse". So, using a different
function defeats the porpose of PGObject, and always returning the hex
value breaks compatibility with old PostGIS releases (as the PGgeometry
object has no idea for which server it's called).

You can, however, turn of the automagic registration (or redirect it to
PGgeometrylw) by editing the org/postgresql/driverconfig.properties
file in the postgis.jar

Btw, we might drop PostGIS 0.X support eventually, or change the
autoregistration to use the PGgeometrylw class, what do you think about
that?

Regards,
Markus

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

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

Reply | Threaded
Open this post in threaded view
|

Re: different results from PGobject.getValue()

Claude Eisenhut
> the semantic for "getValue()" is "give me the string
> representation of whatever the server can parse".

ok.

> Btw, we might drop PostGIS 0.X support eventually, or change the
> autoregistration to use the PGgeometrylw class, what do you think about
> that?

I would prefer if different libraries could work with the same connection
without interference.
And I would prefer if the JDBC driver offers a stable (hiding server
versions), but as fast as possible (raw/low level) interface.
I guess that means no autoregistration and an unmodified getValue().
Unmodified of what the JDBC driver offers without any addons.

It seems that the server can handle binary mode (LWGEOM_recv() and
LWGEOM_send()), but I didn't find code in the JDBC driver that makes use of
this. ?

Claude


Reply | Threaded
Open this post in threaded view
|

Re: different results from PGobject.getValue()

Markus Schaber
Hi, Claude,

"Claude Eisenhut" <[hidden email]> wrote:

> > Btw, we might drop PostGIS 0.X support eventually, or change the
> > autoregistration to use the PGgeometrylw class, what do you think about
> > that?
>
> I would prefer if different libraries could work with the same connection
> without interference.

They can, as PGgeometry only registers for the PostGIS geometry
datatypes, other datatypes are not affected, and explicit registration
of datatype handlers via Connection.addDataType() always overrides
autoregistration.

Btw, did you notice that some builtin datatypes like PGbytea, PGmoney
and PGInterval use the same mechanism, subclassing the PGgeometry
class? That's what PGobject is meant for, being subclassed by driver
extensions. It's only a "soft fallback solution" that a plain PGobject
is returned instead of failing with an unknown datatype exception when
a datatype extension is missing.

> And I would prefer if the JDBC driver offers a stable (hiding server
> versions), but as fast as possible (raw/low level) interface.

The problem is that the server sends and receives different
representations, depending on which PostGIS version is installed.

The PGgeometry class is exactly that part of the driver that is meant
to hide server (PostgreSQL and PostGIS) versions, and as PostGIS is a
plugin to the backend, it's a plugin to the driver. It's not an
"ordinary Library", that's what JTS & co are, it's part of the driver.

> I guess that means no autoregistration and an unmodified getValue().
> Unmodified of what the JDBC driver offers without any addons.

We can discuss whether the autoregistration is sensible. It was meant
to make life easier for the users (simply dump the postgis.jar near the
pgjdbc.jar, and it works). But it seems to cause problems for others.

But if you want to get the data without any modification, you should
use the accessor functions, asHexEWKB() or asEWKB() in your case,
depending on whether you want text or binary representation. When using
those functions, you're independent of driver and backend versions, and
when using asWKT(), asWKB() and getSrid(), you're even portable across
OpenGIS compliant databases (although you lose some PostGIS extensions).

> It seems that the server can handle binary mode (LWGEOM_recv() and
> LWGEOM_send()), but I didn't find code in the JDBC driver that makes use of
> this. ?

Currently, the JDBC driver only supports text encoding, binary encoding
is in the works. The list [hidden email] is the right place
to discuss that specific issue (it was already discussed sometimes,
please scan the archives.)


Regards,
Markus

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

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