Jody, Thanks for taking the time to look into this.
I want to get back to you with some comments, but I'd like to have a little more time to read over what you and Adrian posted. I'll try and respond by the end of the week. The Sunburned Surveyor On 10/2/06, Jody Garnett <[EMAIL PROTECTED]> wrote:
Good Morning again, I managed to talk to Jesse last week about the various "levels" at which edit tool interaction occur in uDig. I have the language all wrong but the rough idea is as follows... 1) Selection Iis modeled at several levels: - FILTER associated with each layer - Features dragged into memory for abuse by editing tools - XXXSelection (ie open ended) placed on the layer or map blackboard for use by any tools 2) Feature - The edit tools make use of a edit feature (this should be on a layer or map blackboard?) as their object for editing. 3) Geometry - From one of these Features they currently grab just the default geometry (something that will need revision), they depend on a feature setAttribute to pass this geometry back to the feature when modified). 4) Visual / Interactive - similar to Go-1 Graphic (basically Shape + Style) and in the Go-1 case interaction - think this is represented as a draw command right now? 4a) Shape - From a Geometry they produce a decimated Java2D shape (basically they simplify into control handles for the current screen) - The relationship is recursive (so multi geometry ends up being several of these shape adapters) 4b) Control Handle - a single control handle may represent many coordinates that have be drawn onto the same pixel. If these layers were *really well* defined you would be able to make use of the same "stack" with OpenJUMP, and we could both work on the problem of adapting first curve and then ISO Geometry for editing. So the questions should be: Q: How much would it take to hook up "curve" (ie the only non JTS geometry that matters). A: Need to write a new adapter from shape to geometry handle Q: Effort needed to hook up "GeoAPI Geometry", ie ISO rather then JTS A: Would need to once again produce these geometry to shape adapters Q: Effort needed to hook up POJOs (ie reuse tools against objects rather then features) A: depends if geometry change is captured as a command (if so isolate a new command factory for working with the pojo), conversly write a Feature interface that adapts the Pojo (even just making visible the single geometry attribute being modified. Q: Effort needed to work with multiple geometries A: Unsure, imagine it just involves checking which geometry was being modified (could be similar to the multiple geometry) Comments: - It would be nice to see the shape adapter captured as a first class concern (a similar idea is defined as part of GO-1 for exactly this purpose) - It would be nice to see "control points" captured as a first class concern so other tools can share look and feel with the edit tools Hope these comments/thinking help, Jody > Let me know what you guys think. If I can design these new tools for > OpenJUMP in a way that plays nice with UDig, I'd like to do that. > > The Sunburned Surveyor
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
