[EMAIL PROTECTED] wrote on 01/25/2007 12:29:13 PM:
> Bryce L Nordgren wrote: > > Yes, this is the JTS wrapper approach (code from SYS Technologies). > Cool - has Sanjay looked at this code? Can we grab it into > unsupported/geometry module (and get finished faster?) I think Sanjay examined this code at the outset. His code is optimized differently than the JTS wrappers. I think the two implementations should be complementary when they are done. Users should be able to use whichever implementation fits their problem better. For the life of me, I can't remember the exact difference, as these conversations took place back in March (earlier?) > > No, I haven't been committing recently. I was in a truck bound for a > > government surplus warehouse. > > > ? do not understand ? If there was activity in the jts-wrapper branch recently, it wasn't me. I was in a truck fetching a 1200 pound satellite tracking system. :) > Not to worry Bryce we have the Filter side isolated out on GeoTools > 2.4, we will need to look at Geometry to Shape however. Hopefully we should be able to make some Shape adapters for the Geometry GeoAPI interfaces. This should serve to help adapt Geometry into Java2D graphics. But we might also want to "render" to an SVG file. In which case, we make SVG<->Geometry adapters. Within five years, we may want to "render" to an OpenDocument Drawing file, in which case we make *.odg<->Geometry adapters. Heck, if we get into 3D (terrain rendering from a particular vantage point), we may need to "render" to a Java3D scene graph, or a POVRay script, or an X3D file. Any of these would require the appropriate geometry adapters. With the broadest brush, it seems like each system has its own means of representing geometric objects and each has roughly the same set of objects. It may be best to consider these "adapters" to be data-only geometry implementations; including the geometry factories. We may be able to write large portions of the renderer (layer management, data handling) once in an AbstractRenderer and produce any of the above renderers via extensions which know which geometry factory to use. :) > The Filter would turn around and call the Geometry method(s) - may be an > interesting exercise in interoptability and the strength of the GeoAPI > interfaces. If we provide a "Shape" backed implementation of Geometry, Filter probably should not assume that any of the operations work (e.g. intersects(), contains(), etc.) 19107 does specify a series of "data-only" conformance levels for an implementation. Perhaps the geometry implementations should be provided some mechanism by which they could report their conformance level? Filter would only work against those implementations which supply the computational geometry implementation? Bryce ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
