[postgis-users] Questons about current starte of java geometry objects

[Paul Ramsey]

Rueben Schulz wrote:
> 
> 
> 1) What is the current status for these objects? I see from posts to
> this list that David Garnier was working on a wkb reader for the
> geometry objects.

  From the developers side, fairly untouched. I have not verified that
they work and are useful for about 6-12 months. On the other hand, there
have not been a slew of messages to the list saying 'they are broken!'
either.

Mssr. Garnier completed a WKB reader a few months ago. Do a search on
google for 'wkb4j' to find his project page. Using WKB4J will definately
enhance the speed at which you can extract geometries from the server.
It uses binary cursors in order to pull the data as pure byte data.
Unfortunately, the same gag is hard to do for the attribute side of
things, so queries often end up broken into two runs, one for geometries
and one for attributes...

> 2) I also see that other people have had the same problem that I have
> returning the wkt as objects (they are being returned as strings because
> the jdbc driver thinks they are char/varchars; I have not had time to
> figure out why). Has someone figured out a fix for this?

As it turns out, this is Just How It Is. Using normal JDBC, data is sent
back from the server to the client as text. This is true for all types,
not just our custom types. To verify this, peruse the pgsql JDBC
sources. 

The JDBC API and the PostgreSQL extensions to them can be used to hide
this fact, and that is what the postgis java objects do. They silently
parse the text for you, so that you can have direct object-level access
to the geometries without building your own parser. Is this efficient?
Hell no, parsing WKT takes a fair amount of time. Is this convenient?
Probably, since there is no reason for everyone to build their own WKT
parser.
 
> 3) Is there a good way to access the llb and urt Point objects of a
> PGbox3d or should these data members be made public?

I do not think I have accessors on the box3d object. I would be happy to
take any patches you would like to offer to the JDBC objects. I would
prefer to add accessors rather than just making the members public
though.

I have been thinking about deep-sixing most of the postgis objects in
favour of a structure which builds JTS objects instead. JTS objects are
way more useful than postgis ones, since they have the whole OGC
predicate and operator infrastructure built into them. Also, geotools
already uses the JTS objects as a core. What do people think?
 
P.