[postgis-devel] Re: Implementing support for PostGIS spatial types in JPOX

[Markus Schaber]

(It seems that the original message of Thomas and Stefan did not arrive
at my inbox, despite the fact that it appears in postgis-devel list
archives, so they mailed me personally...)


Hi, Thomas and Stefan,

I'll try to keep the discussion on the list.

Thomas Marti (HSR) wrote:

> Weiter haben wir beim Durchschauen des JDBC-Codes festgestellt, dass
> gewisse Sachen nicht optimal gelöst sind. Vor allem die Implementation
> der equals()-Methode ist einerseits nicht konform gemäss dem "Vertrag"
> wie er in java.lang.Object verlangt wird (die Methode wirft eine
> Exception, wenn man null übergibt),

This is a bug, I'll look into fixing it.

> andererseits ist sie für unsere
> Zwecke nicht ganz geeignet, weil die Typengleichheit mit getClass()
> geprüft wird und nicht mit instanceof. 

The reason for this is that I intentionally wanted to avoid having the
problem of comparing different subclasses.

Say we have an Object a of MyPoint, and an Object b of YourPoint, both
extending Point.

Now the code has to see that both of them are a subclass of point, and
then compare them, having no knowledge about the exact semantics of
MyPoint and YourPoint.

For your case, you should override the equals method in your subclass
with appropriate semantics, and then possibly the equalsIntern method.

> Da wir aber von Point, etc
> ableiten, funktioniert dann die Gleichheitsprüfung nicht mehr wie
> gewünscht. Jedenfalls haben wir uns erlaubt, die entsprechenden
> Änderungen vorzunehmen. Nach unserem Dafürhalten sollten diese die
> Kompatibilität mit bestehenden Code nicht brechen. Die geänderten Files
> findest du attached, es wäre super, wenn du die Änderungen reviewen und
> dann in den CVS committen könntest.

It seems that you had attached the original, unmodified versions of the
classes.

Btw, I prefer a "diff -u" attached as text/plain instead of .zip, as it
clearly shows the differences and can be looked at directly from the MUA.

> 1.) org.postgis.Point (and other classes) use public fields to store all
> their data! What's the reason for this rather odd design decision?

It is some of the things I inherited from Pauls original code, and I
think it was no deliberate decision, but simply implemented this way.

> Is there any way to make them private in future releases?

I had thought about doing this, but it will possibly break compatibility
with existing software.

We should take two steps for this:

- enshure that all attributes have proper accessor methods, could be in
a minor release

- change all non-final member variables to private (or at least
protected), this should be a 2.x or at least 1.x release, not in 1.1.x IMHO.

> 2.) There seems to be some confusion about the possible combinations of
> haveMeasure (XXXM-Types) and dimension.

The backend and the PostGIS classes have slightly different semantics in
this way, which is not ideal.

For the PostGIS classes, dimension is either 2 or 3, depending on the
existance of Z ordinates. The haveMeasure flag indicates the existance
of a measure. This allows e. G. for adding a 4th dimension (time) later.

In the backend code, the dimensionality includes the measure, and the
"M" in type and function names is used to distinguish between 3D and
2D+M geometries. There's no easy way to extend it to 4D geometries, as 4
dimensions currently signals 3D+M.

> 3.) How far developed is JTS-Support in the PostGIS-JDBC-Driver? The
> todo-file is rather sparse and says only 'Finish JTS support'. Can
> anyone state how complete the implementation approximately is? 20% or 80%?

It is fully working, and in productional use at our site.

However, the regression tests are not extensive enough, the build
process is suboptimal, and I still have to rework the whole
GeometryFactory / SRID thing to avoid the strange geometry factory
cache, now as JTS does not deprecate the SRID fields any more.

And there are bugs in code pathes I did not use in my own projects (as
the one you found below), due to the lack of user feedback and
regression tests.

> 4.) What is the difference between JtsWrapper and JtsGisWrapper? The
> only things we found, when comparing the source code was:
>     * the POSTGIS_PROTOCOL differs: "jdbc:postgresql_JTS:" vs.
> "jdbc:postgres_jts:"
>     * JtsGisWrapper adds 'geometry', 'box2d' and 'box3d' as datatypes.
> JtsWrapper adds only 'geometry'. But where is the difference in the
> implementation?

There is no other difference, the JtsWrapper only registers a handler to
map the JTS classes on the PostGIS geometry PostgreSQL datatype, whereas
the JtsGisWrapper additionally uses the plain PostGIS box2d/box3d
classes to handle bounding boxes.

> 5.) We also think that we've found a bug in
> org.postgis.jts.JtsGeometry#equals():

>             return ((JtsGeometry) obj).getValue().equals(geom);

Yes, that's a bug, AFAICS it should have read

              return ((JtsGeometry) obj).getGeometry().equals(geom);

But that still does not fix the "null" issue, I'll overhaul it and
commit the fix as soon as CVS access works again.

Thanks a lot,
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