[udig-devel] Re: questions about UDig from the OpenJUMP, answers from Go-1

[Jody Garnett]

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