Thanks a lot, Martin! This makes several things much clearer for me. I've attached additional comments below.
> 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, Definitely, it might involve a different way of looking at existing classes and how operations are done. Maybe I can investigate this 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. When it comes to factories, I like what I've seen in GeoTools: 1. A "FactoryFinder" as the central place to register factories and to get factories from. If I had an alternative implementation of, lets say, the geometric primitives I would register the appropriate factory there. 2. Several factories, each one with a well defined scope (i.e. one for the CoordinateSequence, one for geometric primitives, one for creation of ... You get the picture. There's not much point for me playing around with JTS1.5 source code if 1.7 is about to come. But once it is released, I could have a look at it and see what is possible. One issue I see is that operations would (maybe) have to work on interfaces of the geometric primitives as well. They would not have access to any functions not in the interfaces. It will be one design task to ensure that this does not lead to reduced performance. But I belive it's possible. > > 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. OK. I understand you point of view. No problem. We can (and do) care about this on our side. > Hope this helps... It did indeed. 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
