Hi Martin, I am as well interested in a good and intuituve topology API. In this context there arose some questions concerning JTS that I'd like answered by someone from the JTS team directly.
1. You write that you have been working on topology classes. Fine. Are there any documentation/drafts out to review? 2. Do you aim the topology functions you mentioned for JTS1.6 or later? 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? - Do you think having interfaces would make sense? Would be possible with reasonable effort at all? - Is it planned to change this? 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? 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. 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. 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? I do not read the JTS dev list (would be too much traffic since I already read three lists), so please excuse if some of these questions have been discussed there already. Matthias Basler [EMAIL PROTECTED] ---------------------------------------------------------------- This mail was sent through http://webmail.uni-jena.de ------------------------------------------------------- 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
