The recent threads on the different Envelope classes got me to thinking about the policy for Geometry representation in GeoTools, if there is one. In OpenJUMP land representation of feature geometries is pretty simple. You just use JTS. :] If something more is needed you cook it up. (I don't think this happens very often.)
So here are some of my questions about the policy for Geometry representation in GeoTools: [1] Is there a need to support complex geometries not currently supported in GeoTools? If so, is there a clear demarcation between these packages and the packages that can only need simple geometries and can use JTS? [2] Why wrap simple geometries in an ISO or OGC specification? Is there a FOSS Java library for representing simple geometries that offers serious competition for JTS? Are there any plans for such a library in the future? I wonder if it is worth the additional complexity of such wrapper interfaces if there currently isn't, and won't be such an alternative in the foreseeable future. The more I work with JTS the more I appreciate all the effort Martin Davis has put into making it an excellent library. It seems the logical choice for representing simple gometries in GeoTools. If there is no pressing need to integrate an alternative to JTS, why add the complexity of a wrapper? [3] Adrian wrote: "Stay away from org.geotools.geometry.iso and org.geotools.jts unless you really need to use those packages. The former is, I suspect, moving full speed back to unsupported land." Is there a reason for this? I would think that JTS will be around for a long time. Is it because there isn't currently a maintainer for this package? Is it because there is an effort to move these classes and interfaces into JTS itself? I've got some JTS utility code of my own. Maybe I should consider moving it to the org.geotools.geometry.jts package and taking care of some clean-up and maintenance of the package... I don't mean to be difficult by asking these questions. I'm just trying to understand the logic that goes into the decisions governing the design of individual GeoTools module, and of the library as a whole. Landon ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
