There are two implementations available on trunk:
This is the approach used by the unsupported/geometry module.
There is a lot to be said for an easy to understand implementation - it is simple sweet and direct. No duplication, no JTS at all. There are ways not to throw away the years of work placed into JTS (The team appears to have ported some of the JTS code over to the new geometry abstraction, although the the testing framework would be a bigger win in terms of trust).
This is a lot of work but represents a nice long term solution if a committed team is around for years to come, we can cheat time by stealing the JTS test cases (ie high value), but this approach has the great risk but will be done eventually.
This design is used in the implementation donated by SYS Technologies.
This design is a direct wrapper around JTS but JTS is not the final authority on topological information. Instead a JTS object is produced as needed from the information held in the wrapper object - this may result in greater performance (but does have the danger of getting out of sync).
This approach is good and is also used by the gvSig team (where they put off creation of the JTS object until (and only if) a complex topological function needs to be called. This is fast when done right.
This is only presented as a reference point, no implementation exists.
A simple and quick way to get an implementation out the door quickly would be to wrap JTS and delegate all the topological data (ie the coordiantes) to the JTS classes for safe keeping and stability. Additional metadata required by ISO Geometry (for example CoordianteReferenceSystem) can be held by the wrapper class.
The based location for this code would be as part of the JTS codebase, the downside is that this model goes beyond the "pure topo" mandate of JTS and it does not have a path forward for curve and surface support.
This is safe when done right, and is an option for the jts wrapper module if synchornization issues become a problem.
As part of preparing for the roll out of ISO Feature interfaces we will need to set up GeoTools with an implementation of ISO Geometry (the subject of this page).
Criteria for evaluation:
There are two implementations:
There are two aspects of Geometry that must be accounted for when integrating into the GeoTools codebase:
GeoTools 2.4 has paved the way here with the design used here for seperating out property access from the implementation used. In short an extension point is provided which integrators can use to teach GeoTools about additional geometry formats.
This task is tracked as part of Expression Improvements.
In order to have the renderer function the existing ExpressionValue construct (and Converter extension point) can be used to morph data between formats according to context. A straight forward application of this idea would be to evaluate the ISO Geometry into a Java 2D Shape construct; we may need to make a special effort to provide the required decimation level to control the process.
We also have the need for speed, especially in the reading to renderer department. In an ideal world we would make several 'GeometryFactory' interfaces which the DataStores could make use of as needed.
It should be noted that this GeometryFactory API will need to:
We may need to produce our own flavour of CoordianteSequence to act as a bridge between what DataStore "Reader" can provide and what GeometryFactory can produce.