Between the discussion on this thread and the one on envelopes I think I am suffering from information overload. :]
I need time to digest all you have written. I understand some of what you are saying, but other things are clear to me yet. Give me a few days, and I will likely have more questions. :] Thank you for your patience. Landon P.S. - "What do you have? I can try and help you find a home for it..." Most of my utility stuff for JTS is here: http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/jts_warped/branches/unstable/src/net/surveyos/sourceforge/jtswarped/utilities/ There isn't a lot there, but the contents will likely grow as I do more work with JTS Warped. I don't know that the code "needs a home" necessarily. It has a home already, but if I participate in GeoTools for the long term it may make sense to move it over. I guess I was more worried about the JTS utilities in the org.geotools.geometry.jts package being abandoned or "unsupported". As a big fan of JTS I don't want to see that happen. :] On Mon, May 19, 2008 at 6:11 PM, Jody Garnett <[EMAIL PROTECTED]> wrote: > 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
