THinking about this watching the rain fall, it occurred to me my
answer should have been more complete. I ran into a *lot* of design
issues thinking about setting up a simple interpolate algorithm, the
kind of thing the Potatoe Center has been doing.
The design issues are around the workflow. Ideally this would happen
in a perspective (more on that to follow). Regardless, the work flow
is something like´:
Selection of input layer(s)
---> User input (operation; parameters)
--> Output layer
For something as simple as ¨buffer¨ you also have issues of whether
you do the buffer per feature (ie each river gets its own buffer zone)
or per layer (the river network gets a buffer zone) and so on. The
upshot is that you need to *design* a workflow before you get to worry
about coding the actual operation. So while coding the operation may
be relatively easy given that the computational geometry has been done
by the fantastic folk who created JTS, there is some hard work and
some decisions that need to be made at the uDig level.
User input could obviously be done through dialogs, but if you start
designing a series of geospatial ops, you see that (1) it will require
lots of dialogs and (2) there is some serious commonality betwen the
different ops which begs for reuse.
The long term goal will obviousl be to have a graphical editor of
geospatial ops where users can create operation chains graphically by
adding arrows between data sets, operators and output layers. It´s not
for tomorrow but probably will be required down the line so it would
benefit thinking about how todays quick and dirty can eventually be
integrated into such a framework.
The net of thinking about the design of geospatial ops in uDig is that
we probably want a perspective for this so users can work between
input layers (selection in the catalog + selection on the map);
operations and their parameters; results (both graphical and
analytic).
So this is something about what I meant that there´s a *lot* of work
that needs to happen setting up the direction of implementation before
users can build (1) single layer analyses (buffer, interpoloate) (2)
multi layer analytics (clip, overlay,...). That work has nothing to do
with whether an implementer uses existing methods in JTS, codes their
own methods, or calls out to a third party library like R to do the
computational work.
Hope that helps you think more generally so we can implement all the
needed functionality piecewise but coherently,
--adrian
On 10/13/06, Cory Horner <[EMAIL PROTECTED]> wrote:
Adrian Custer wrote:
> This is not entirely true; setting up the first example of these will
> actually be non-trivial. Once there is a path, ie. an example, then it
> will be easy to add the others. If one of you decides to implement one
> of these, it becomes *much* easier for the community to implement the
> rest,
>
> --adrian
Fair enough... we will kick out the first example :)
Cheers,
Cory.
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
