We should uses GepAPI interfaces (derived from ISO 19107) as our basis for geometries in Geotools. Since JTS still a useful implementation, we need to wrap JTS geometries into GeoAPI interfaces.
Note that JTS cover a subset of ISO capability. An ISO geometry can have arc as well as straight line, be 2D or 3D, and use an arbitrary coordinate reference system (CRS). JTS geometries applies only to the following:
Straight lines only
* 2D (or 2.5D, but not 3D)
* CRS using a cartesien coordinate system only, i.e.
crs.getCoordinateSystem() instanceof CartesianCS
Our wrapper must verify that those conditions are meet before to allows the use of JTS implementation. However, even if JTS cover only a subset of ISO capability, I believe that this subset already cover a wide range of cases.
Actually, we may not need to enforce too much the CartesianCS constraint. Maybe we can allow JTS object creation with a non-CartesianCS, but disallow only topologic operations on it. In any case, this issue must be explored. But we must make sure that all operations that requires a CartesianCS check this condition first. We can live with UnsupportedOperationException, but we can't let a method produces erroneous results without warning (from the code, not from the documentation) that it was not designed for a work in non-cartesian CS.
CodeHaus Comment From: bnordgren - Time: Fri, 14 Apr 2006 16:50:13 -0500
I am most of the way through a review of the code. I had a database set up in Openoffice where I could mark each method as stubbed out or not (and also associate comments with methods). I was most of the way thru, but it crashed and dumped all my data. I'll redo (should only take half a day or so) and post here, having learned that the embedded database is a volatile monkey.
In general, it looks really good and far more complete than I was expecting. I have some issues with returning the actual Set or List which backs an object (instead of a copy), and these are peppered throughout the code. I would also suggest some changes of return types in GeoAPI from arrays to Collections, to sync up with other usage in GeoAPI, but that is beyond the scope of this jira task. Specific comments will follow when I get my database back.
CodeHaus Comment From: coconut - Time: Tue, 18 Apr 2006 08:48:38 -0500
new zipped up src folder attached
- changed to use org.geotools.factory.BasicFactories.getDefault()
still uses org.geotools.referencing.CRS.decode()
removed the methods that had been added to end of org.geotools.referencing.CRS and added them to end of the GeometryUtils class
So little changed that i don't know if it was worth posting new version - was intending to sort out headers, formatting and comments with jalopy but all i get is grief about invalid javadoc tags...
CodeHaus Comment From: bnordgren - Time: Fri, 2 Jun 2006 14:37:02 -0500
Ok, it's time to consider something that's mentioned in the main issue text:
Should we generate errors rather than perform a JTS spatial operation on a noncompliant coordinate system? What if the user wants "approximate" results? What if the user knows (for instance) that operations on EllipsoidalCS are technically not legal, but wants to see what the result is? Worse, which projections produce length-conserving CartesianCSes and which do not? Which produce area-conserving CartesianCSes? Are the JTS operations legal with any projected coordinate system or do they apply only to strictly planar orthonormal spatial coordinates?
In terms of how to handle issuing a warning, how about this: perform the spatial operation regardless of coordinate system. If the coordinate system is not CartesianCS, we throw an InvalidCoordinateSystemWarning exception, which could be a subclass of UnsupportedOperationException. If the user wants the results regardless of CS, then they know what exception to catch, and if they're just blindly stumbling along they get an exception.
CodeHaus Comment From: desruisseaux - Time: Tue, 6 Jun 2006 00:29:35 -0500
An InvalidCoordinateSystemWarning sound like a good approach, even if unusal (but still used in java.sql with SQLWarning).
CodeHaus Comment From: jgarnett - Time: Sun, 14 Mar 2010 04:41:44 -0500
This approach was followed by the donated jts-wrapper plugin; which is available as an unsupported module.