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

[Sunburned Surveyor]

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 <jgarnett at refractions.net> 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
>
>