Adrian, Thank you for the detailed response, it seems that you, like other GeoTools programmers, are willing to patiently answer my questions. This is appreciated. I have some interleaved responses to your e-mail below.
You wrote: "Your question seems totally naive." I am a lot of things, but I hope naive isn't one of them. I'm still trying to get a handle on the goals of GeoTools as a library, and on the logic that goes into its design choices. This isn't an easy task for me, as GeoTools is a many tentacled thing. You wrote: "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." On the contrary, a 2D geometry space can be used for much larger areas, even for the whole earth, with the correct map projections. You just have to understand the distortions that you are dealing with. The idea of global or geographic coordinate systems is interesting, and for some applications (like geodesy) it is even critical. However, I'd bet 98% of today's GIS users are working with a typical 2D or 2.5D cartesian coordinate system. You wrote: "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." Understood. You wrote: "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." O.K. - But I wonder how much we really need to worry about the "global GIS community". What really matters is being able to move the state of geometries from one software package to another. The internal representation used in a spatial application written in Java is another matter entirely. It my own limited experience the file format used for storage of data is the real key. I'd argue that we deal with ISO19107 in that respect, and work with an internal representation that plays best with Java and existing code. Unless of course you are speaking about sharing Java objects between Java libraries, or the "Java GIS community" and then something based on ISO 19107 might make sense. You wrote: "I suspect you are not entirely clear of what's "complex" in ISO geometry." I do understand. I just wonder how important it is to support these for the majority of GIS applications. To me, it is almost a specialized field. You wrote: "General geography is hard, don't expect it to be easy and simple." My job as a programmer is to make complex things simple. :] I am very cautious in this regard because I know that complexity can be the kiss of death. This may not always be true for proprietary applications, but it is certainly true for open source applications. You have to write code that can be understood by others, and those "others" may not always be expert programmers. I believe it is very important that an open source project keep the road from "user" to "programmer" as wide and smooth as possible. GeoTools should be vigilant about fighting complexity. I know this is a challenge with such a broad library, but from an outsider's perspective I think it is the number one challenge for GeoTools programmers. I would argue that the ability to work with complex curved geometries, 3D geometries, or even geometries modeled on the curved surface of the Earth are still not needed by the majority of GIS applications. We should recognize that this stuff is cutting edge, and treat it accordingly. That doesn't mean that it shouldn't be developed and used, but that it's applicability at this point in time be treated realisticly. We shouldn't add complexity to 95% of a code base for %5 percent of the applications. You wrote: "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." It seems (on occassion) that people view my questions as a challenge to (or harsh criticism of) their work. Or worse, as my doubting their own expertise and intellectual ability. This is not at all the case. I learn by asking questions, and I accept very little established wisdom. This can be a difficult way to approach the world, but I find it very rewarding. I don't doubt your expertise, or Matin's, or Jody's, or the wisdom of any other GeoTools programmer. I ask that you give me the same respect. I am not an expert programmer, but I do know a thing or two about creating a 2D or 3D model of the very complex world around us. That's something I do for a living, and I'm not half bad at it. My work as a surveyor brings me into contact with many different spheres of the geospatial sciences, include geometry, geodesy, cartography, measurement error, measurement instruments, and more. I'd like to think I'm a little more advanced than your average ESRI user, and I probably know just enough to be dangerous. At the same time, I try to humbly admit my limitations. In summary, I mean no respect when I ask questions about the work others have done, but I do humbly propose that my background as a surveyor may allow me to add something useful to the conversation. Landon On Tue, May 20, 2008 at 12:31 AM, Adrian Custer <[EMAIL PROTECTED]> wrote: > 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
