Sunburned Surveyor wrote: > 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.) > In GeoTools we try to isolate ourselves from the clients choice of Geometry implementation; ie it is not our choice to make - that is up to the person using GeoTools. That said you will find a couple guidelines: - Code that does not want to depend on JTS can make use of GeoAPI DirectPosition in order to interact with gt-referencing. - Code that does not want to depend on an ISO Geometry implementation can get away with that; referencing has its own implementation of the DirectPosition and Envelope interfaces in order to do its work. You also missed out on a major one: - Java 2D Shape
And a couple minor ones Oracle SDO Geometry, PostGIS Geometry, some Java 3D stuff etc... You will find we have code to convert between JTS and Java 2D shape for display. The idea is to treat other Geometry implementations the same way ... > 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? > We have not implemented the full ISO Geometry spec yet (ie no curves), we also have not integrated the work we have: - gt-referencing does not make use of "GeometryFactory" yet; when it does you will be able to ask it specifically what you want to do (ie use JTS or an ISO Geometry implementation of your choice). Right now adapting between these two done by the JTS utility class... - gt-renderer needs some code to convert from ISO Geometry interfaces to Java 2D Shape > [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. You have identified the problem: - there is no good alternative to JTS - JTS has a strict mandate (linear geometry) that is holding us back So in order to bust free of the limitations of JTS we have a couple plans: - seperate out the library from the choice of Geometry; see Filter/Expression for how this is done on the "Query" side, and "Converters" for how it is done on the "Data Access" side - an implementation of ISO Geometry does as a JTS wrapper - an implementation of ISO Geometry done as a fork of JTS But until one of these ISO Geometry starts offering additional constructs I have no reason to recommend it over JTS; and you can see my recomendation in the user guide (strictly telling people to use JTS for now). > 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? > Um; we have not added the complexity of a wrapper. We use JTS a lot? > [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 think Adrian has identified a couple problems with the implementation from a maintainability standpoint. Turns out that a decent implementation of Geometry that knows about CRS has an extra layer of complexibility that I had thought of... - I had thought of the "new constrcuts" like Curve and Solid and figured that was where the work is... - Adrian noticed that a Geometry defined on a CRS may actually be a Geometry defined on a surface (ie with great circles edges, rather than linear edges). Basically we need to cough up implementations of the "spatial operations" based on looking at the CRS as well as the Geometry construct involved. > 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. > None; Martin is not interested ... see strict scope of his library. > 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... > What do you have? I can try and help you find a home for it... > 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. > Yep; you are getting a good tour. Basically we have more scope then Martin does; as such we are taking on some hard problems; some of what you see is a work in progress ... the gt-geometry module was started as a research project; cleaned up by Refractions for commercial use, and may go back into research mode now that Adrian has tried to use the result. Jody ------------------------------------------------------------------------- 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
