[postgis-devel] PostGIS-JDBC

Markus Schaber schabi at logix-tt.com
Thu Nov 2 01:15:49 PST 2006


Hi, Thomas,

Thomas Marti (HSR) wrote:

> 1) The Javadoc of Geometry.setSrid() defines, that the SRID will be set
> recursively, but that's not reflected in the implementation. I have
> attached a patch that fixes this.

Applied, thanks.

> 2) At the moment the only way to get the JDBC driver, is to either
> download the sources and build it yourself or to install PostGIS and
> then go dig for the JAR-file. In our opinion it would be much better to
> have a separate download for that, as for example the PostgreSQL project
> has (http://jdbc.postgresql.org/).

I've proposed this myself, but it was not accepted yet.

> Even better would be to put the JARs
> in a public Maven repository, so Java developers would only have to put
> the dependency in their POM files and the rest is then taken care of by
> Maven.

I don't have any idea how Maven works, and I think Paul is the one who
has to decide about that, because he's the "master of infrastructure".

However, some distributions like Debian distribute the java parts in
their own packages. And as PostGIS is free software, nobody prevents you
(or anyone else) to set up and maintain a Maven repository for PostGIS. :-)

> 3) There's a fair bit of duplication in BinaryWriter/JtsBinaryWriter and
> BinaryParser/JtsBinaryParser. Wouldn't it make sense to refactor out a
> super class? We'd be willing to volunteer for the job, because we want
> to write a separate Writer/Parser combo for Oracle's JGeometry anyway.

It will definitely make sense, as long as you figure out a common
abstraction between org.postgis.Geometry, JTS and Oracle's JGeometry.

However, I also want to reduce code duplication between the JDBC and the
new PLJava code that's just waiting for some pljava issues to be fixed.

In PLJava, we don't have to parse EWKB, but the slightly different
internal lwgeom representation that's used by the C code.

And I'd like to replace the [Byte|Value][Getter/Setter] interfaces with
SQLData implementations, as they are the "native" interface for that case.

The only thing that's preventing me from doing that just now is time
constraints, as usual. :-)

HTH,
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



More information about the postgis-devel mailing list