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

[Rueben Schulz]

Comments Below.

On Sat, 2002-10-19 at 10:06, Paul Ramsey wrote:

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

After spending some time with the pgsql jdbc sources I have tracked the
problem down. The sql asText() function returns text, so the
resultSet.getObject() method determines that the resultSet field is text
and kindly returns a String object. If the full geometry is selected in
the sql instead, the PGgeometry.setValue() fails as it cannot parse the
SRID. 

There appears to be two solutions to this. 1) remove the SRID from the
geometry before parsing in the setValue() (easy and works). 2) define a
new postgres type WKT and have the asText() function return this instead
of text.
>  
> > 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.

Should be easy enough. By the way, are you using the sdk 1.3 or 1.4?

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

I will start to look into how this can be done next weekend. Should not
be too hard as the wkb parser and JTS objects are already done. Would be
a good, small project to learn from (my primary reason for working with
postGIS). 

Rueben 

>  
> P.
> 


> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users