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

[Thomas Marti (HSR)]

Hello PostGIS-Developers

We're two students at University of Applied Sciences, Rapperswil 
(www.hsr.ch) in Switzerland and we are currenty working on implementing 
support for PostGIS spatial types in JPOX (www.jpox.org). The term 
project will be finished by July 7th, when we will publish it under a 
suitable open source license. The JPOX devs have already offered to put 
it on their CVS, so the code will be publicly available in one form or 
another.

After a first analysis, we've decided that we start by implementing 
JPOX-Mappings for Geometry (and its subclasses) from the PostGIS-JDBC 
package.

That said, we've found a number of things that are unclear to us and we 
hope that someone here can help us out...

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? Is 
there any way to make them private in future releases? Unfortunately, 
it's not possible to write an SCO-Wrapper in JPOX (that means a wrapper 
that automagically detects changes in a persisted Object and saves to 
them to the database) for Classes with public fields. The problem is, 
that we can't intercept a direct write access to a public field, whereas 
we can overwrite the set-methods() and mark the object as 'dirty' (which 
means that the changes need to be written to the database).

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

org.postgis.Geometry implements the following:
===========================================================
     public void outerWKT(StringBuffer sb, boolean putM) {
         sb.append(getTypeString());
         if (putM && haveMeasure && dimension == 2) {
             sb.append('M');
         }
         mediumWKT(sb);
     }
===========================================================

So, 'M' is only appended if dimension equals 2....but if I try the 
following directly on the database:

===========================================================
SELECT AddGeometryColumn( 'points', 'punktm', -1, 'POINTM', 2  );
===========================================================

This error is thrown:
-----------------------------------------------------------
ERROR:  TypeM needs 3 dimensions
KONTEXT:  SQL statement "SELECT  AddGeometryColumn('','', $1 , $2 , $3 , 
$4 , $5 )"
PL/pgSQL function "addgeometrycolumn" line 4 at select into variables
-----------------------------------------------------------



We're contemplating writing mappings and wrappers for the JTS classes as 
well. The question here are:

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


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?

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

-----------------------------------------------------------
     public boolean equals(Object obj) {
         if (obj instanceof JtsGeometry)
             return ((JtsGeometry) obj).getValue().equals(geom);
         return false;
     }
-----------------------------------------------------------

What this method does is comparing the 'value' (String) of the other 
object with the 'geom' (Geometry) of this object. This doesn't work and 
the method will always return false!

Simple test case for this:
===========================================================
JtsGeometry geom = null;		
try {
	geom = new JtsGeometry( "POINT(11 21)" );
} catch ( SQLException e ) {
	assert false:e;
}
System.out.println( "geom.equals( geom ): " + geom.equals( geom ) );
===========================================================

P.S.: Haven't checked cvs, so maybe this bug is already fixed. Sorry 
then... ;)



Well, that's it for now...



So long,
  Thomas & Stefan