Bryce L Nordgren wrote: > [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. > Given that we use Batik (ie we write to a Graphic2D a Java Shape .... ) in order to generate SVG working with a Shape should be good for now. Now if those crazy uDig cats talking JOGL require more we can talk again. > Within five years, we may want to "render" to an OpenDocument Drawing file, > in which case we make *.odg<->Geometry adapters. > The Filter/Expression definition on GeoTools 2.4 have the idea of "pulling" a value into the format requested; so we have the open ended mechanism their already .... pulling into the shape of a DOM Element could very well produce SVG (although look at the parser bindings idea for a better idea). > 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. :) > See we like you - you are crazy. And we are crazy - check out trunk and see if it will do what you describe. >> 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? > > Was not aware of the data only conformance level; throwing a unoperation operation exception is the traditional java notification technique :-)
Cheers, Jody ------------------------------------------------------------------------- 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
