Hello, Your question seems totally naive.
JTS is a good library but it should be obvious why it cannot form the basis of a geometric engine for a geographic information system at anything other than local scales. Using JTS has been a great first step for Geotools since we've been able to focus on other things first, i.e. we got a simple features implementation in place and now even have a namespaced feature model. Now we're hoping to move on. Interoperability requires that we speak what others speak. The global GIS community has so far only proposed the use of concrete profiles of the abstract ISO 19107 Spatial Schema specification as a vector description of the spatial occupancy of geographic entities. So if we want to speak with others, that's the way forward. I suspect you are not entirely clear of what's "complex" in ISO geometry. I laid out my preliminary understanding on the Fried Egg modules' page: http://docs.codehaus.org/display/GEOTOOLS/Fried+Egg The core hurdles are * (1) allowing developers using Geotools to configure the library as a restriction of the complete spec such as the new "Simple Features" spec 19125 or the "Core Implementation" spec 19137 * (2) doing calculations on the manifold given by the geometry's CRS * (3) handling curvilinear structures * (4) handling 3D with number two being, I suspect, the most challenging of the four. Just yesterday, I started the unsupported/isogeometry directory aka 'Fried Egg' by a massive copy of the plugin/geometry module. That module itself is a port of JTS. However, none of the code even begins to consider the four issues just listed. Also the code needs a bunch of serious re-work so most may very well be junked. So, it's going to be a while before it's usable even for 'simple' geometries in cartesian spaces. For now, JTS remains the only good game in town. Finally, beware the notion of { Envelope \equiv Bounding Rectangular Parallelepiped } FALSE! which is false. Envelope is very well defined, *always*. That is why it is used pervasively in the ISO specifications. The Bounding Rectanglar Linear Edged Convex Polygon also is, I suspect, although I don't know of a rigourous definition for the idea we all share. Note that Bounding Rectangular Parallelepiped only works on manifolds which allow parallelism and generally implies an Axes parallel structure so it requires considering also the directions of the Axes. These two ideas are *not* equivalent, as can be quickly seen if you consider those concepts for Antarctica and Afric-Euro-Asia in long/lat coordinates. So, the idea that we can have a class that is both an envelope and a bounding rectangle exists in one of the classes you've run across in Geotools but that class is bogus as soon as the geometry becomes geographically interesting. It's bogus because we are not always in a space that allows Rectangular Parallelipipeds and even in those spaces, while the joint class could always be interpreted as a Rectanglar Parallelepiped it might, or might not, cover the spatial occupancy of the object of interest but would certainly not be, in general, a Bounding shape. General geography is hard, don't expect it to be easy and simple. Also, if others have spent a bunch of time thinking about an issue, you should probably think that the issue itself is rich and complex so it's not possible to "just do it" in a simple way. --adrian On Mon, 2008-05-19 at 15:55 -0700, 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.) > > 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 ------------------------------------------------------------------------- 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
