Bryce L Nordgren a écrit :
FYI, I'm looking at making a stand-alone "geometry" module (which
implements GeoAPI geometry classes) by adapting _something_. Current
alternatives are:
1] Adapt JTS because it has a well-documented lineage, and is active.
2] Adapt deegree because it says it's a 19107 implementation.
3] Fake something where most of the methods throw UnsupportedOperationException.
I already though about it (and missed time, like usual). I would be very glad if someone else could
begin to create this geometry module!
As Dave point out, the geooxygen project may worth a look. But I don't know
much about them.
My proposal (what I would have liked to do if I had time to start coding this geometry module) is to
adapt JTS. More specifically, create the following package:
org.geotools.geometry.jts
to make it clear that this is one implementation on top of JTS; it may be not the only
implementation. My proposal is to *not* modify directly JTS code, because:
1) it is likely to continue to evolve;
2) JTS is used in many place, and some developpers will want the usual JTS
objects for interoperability with their own code.
So I suggest to write adapters. For example a class implementing the GeoAPI LineString interface,
which contains a JTS LineString as its unique field, and delegates all method call from the GeoAPI
interface to the corresponding JTS method.
An advantage of using such adapter scheme is that developers can play with the original JTS object
if they wish. It may be important given the amount of JTS-dependent code.
Wrapping degree code would not have much interest for Geotools, since we don't use Degree geometry
objects (by the way, I believe that Degree's API on the geometry part come from the early GeoAPI
days, before the packages settle down). Wrapping JTS code (instead of adapting it) would provides a
transition path between JTS-dependent code and GeoAPI-dependent code. This transition path is likely
to be needed.
A limitation of JTS wrappers is that they would work only for geometries in a 2D cartesian space. We
should make that clear in the documentation. However, it would be a valuable start. It would give us
more time for looking alternative implementation in the future (geooxygene?), if we wish.
So my vote would be: Adapters around "official" JTS objects (not a rewrite of
JTS).
Regards,
Martin.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
