> 1. You write that you have been working on topology classes. > Fine. Are there any documentation/drafts out to review?
Nope- this is still under development. I'm not quite ready to release it. > 2. Do you aim the topology functions you mentioned for JTS1.6 > or later? Some release after 1.7, which is coming out soon. > 3. I always wondered why JTS uses classes directly, not > interfaces - (apart from a few interfaces that do exist in > JTS). As you have probably realized, almost anything in > GeoTools is based on interfaces and one or more > implementations, which can be replaced by more suitable > implementations without much change in the client code > working on the interfaces. By using interfaces and abstract > base classes it is even possible to add convenience functions > to the interface at a later point without much hassle. > > Personally I am a bit relucatant to use JTS simple for this > reason of not providing interfaces. I find it a bit hard to > build something interface-based "on top of" JTS classes, if > they do not provide interfaces which I could extend. > > Especially for something so fundamental as Geometries and > Topology I personally believe it important that there is a > well-developed, conceptionally sound API with JTS providing > one - the default - implementation, but with other > implementations being possible (maybe speed-optimized or > memory-optimized, maybe extending the API for additional > functionality). > So my questions are: > - Why was it originally chosen to not use interfaces and > implementations? One of the original motivations was for efficiency and speed of development. JTS does use interfaces in a pragmatic sort of way (e.g. the CoordinateSequence interface, which Allows adapting to other geometry models). The use of interfaces should probably be extended, I agree. I believe there is quite a bit of difference between a real Interface API and a library which is intended to be an implementation of algorithms. Being fully interface-based raises the bar quite a bit, since you need not only interfaces but a decent factory model etc. The interaction between interfaces & implementation can get quite complex. I'm certainly interested in looking at well-thought out, complete suggestions though - feel free to supply one. > - Do you think having interfaces would make sense? Would be > possible with reasonable effort at all? > - Is it planned to change this? I've given this a bit of thought, and as I said above would be interested in suggestions. > 4. There is a JTS1.6 library floating around in Geotools. I > couldn't find the source code of it, the JTS web page only > provides version 1.5 which contains (of course) some > differences. Are the (preliminary) source code - or at least > the JavaDocs - accessable somewhere? http://sourceforge.net/projects/jts-topo-suite > 5. JTS provides theoretically the possibility to store SRS > (spatial reference > system) information. From what I have seen in GeoTools, > GeoTools does not use this function but builds CRS storage on > top of the JTS classes (such as in the > "JTS.ReferencedEnvelope" class). Here my questions: > - Am I correct with my interpretation that the SRS in JTS is > just "dumb" metadata and is not actually "used" internally to > transform coordinates and such? > - What is the future of this SRS funcionality in JTS? > - Is there any notion of supporting the GeoAPI > CoordinateReferenceSystem (CRS) API directly in GeoTools and > maybe this way add coordinate transformation into the JTS > classes. See next point to why I consider this relevant. I don't have any plans to support coordinate systems (CS) directly in JTS. It provides a bit of support for CS metadata as per the SFS spec, as you've noticed. My feeling is that geometric operations (at least 2D planar ones) are orthogonal to CS. Clients of JTS should be able to provide their own CS implementation in a fairly independent way. (This may not be tenable for geodetic CS, but that's a whole nother packet of issues anyway. > 6. Will one "topology layer" assume all points (and therefore > geometries) to be in the same coordinate reference system (or > SRS or <null> if this is a non-geographical topology)? I ask > because I could imagine the scenario that there exists a > topology in CRS A, but a node (or a whole geometry) in CRS B > is to be added to it. In this case I would expect the toplogy > API to transform this point/geometry to CRS A before adding it. Why clutter up the topology API with CS reprojection? Why not simply reproject on the way in and out of the topology API? Those things are complicated enough without adding CS support as well. > 7. You might have read on the GeoTools list that I am > interested in real 3D geometry as well. I've been playing > with some concepts lately, some of which involved using JTS > for the "2D projection" of 3D solids. Is JTS considering > anything towards 3D currently? No, definitely not in the plans. 3D is waaay harder than 2D. I would expect that a 3D API would share little if nothing with a 2D API (witness the Java APIs), so I don't see any need to widen JTS to accommodate 3D. Hope this helps... Martin Davis, Senior Technical Architect Vivid Solutions Inc. www.vividsolutions.com Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5 Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046 > ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
