[udig-devel] Work required for (was:) Spatial Operation and Editing Tool

[Adrian Custer <acuster@xxxxxxxxx>]

Hey all,

These are my responses to the Axios team, and the the work I imagine
will be required to have uDig support geospatial operations.

My ultimate suggestion is: let's implement a really good buffering
operation, solving all the issues related to workflow, user interface,
and file creation with just that operation. Adding more operations
afterwards will be fast and easy.

--adrian



On Tue, 2006-12-05 at 20:00 +0100, Victor Mauricio Pazos wrote:
> Hi list!, we have begun a project to develop Spatial Operations and Editing 
> Tools features. This new features will be LGPL products.
> 
> Our first goal are Spatial Operation (buffer and merge). The following link 
> has the project details.
> 
>  http://udig.refractions.net/confluence/display/COM/Axios
> 
> We expect yours comments.
> 
> Thanks in advance


Great to hear you are getting into this issue.

First, this is hard in many ways most especially the user interface.
There are many solutions and we may have to poke around a little.

Second, because this is the first attempt at an operation interface,
difficult workflow and GUI issues have to be resolved. 





On workflow:
-----------
In [[http://www.axios.es/projects/udig/html/]] you show a particular
workflow for buffering operations

  Select  ->  Invoke Buffer  -> Configure Output -> Configure parameters

Two issues arise with this. First, new users don't know this is the
workflow before starting their operation so they don't know they have to
start by selecting. Your strategy provides no way to recover from 

  Invoke Buffering

When developing the Gnumeric spreadsheet's graphing interface, we faced
a similar problem, having to develop a way for users to select after
calling the graphing wizard. For Gnumeric, this involves entering a
weird state where you can select and do nothing else. This workflow is

  Invoke Buffering -> Select 

uDig must support this strategy. 


The rest of the workflow should also be consistent; I believe it should
be organized as:

  Inputs  -> Operation parameters -> Outputs

which would reverse the order of your wizard. 


So ideally, we have a workflow that goes

  |Invoke Buffer|
  |-------------| -> Configure parameters -> Configure Output -> run
  |  Selection  |

in which, when the user invokes the buffering operation, uDig opens a UI
to the 'Inputs' page which shows the user the features/layers/attributes
on which the operation will proceed. If a user (for example an advanced
user) has pre-selected data, then the various inputs fields are filled
out with that information. If they are empty or if the user wants to
change the inputs, that is possible.

        IMPLICATION: uDig needs a standard set of GUI elements which
        together show the current selection.
        
        IMPLICATION: uDig a way to go from that GUI element set back
        into some sort of 'selection mode'.

During parameter configuration, a user may also want to go back into
screen mode. For example, a user may want to buffer by a distance that
they know as a visual separation on screen but not as a metric. We may
want to support a way for users to go back to the screen to click on a
start and end point to get their buffer distance. So now we have


  |Invoke Buffer|    |Configure parameters|
  |-------------| -> |--------------------| -> Configure Output -> run
  |  Selection  |    | Select Distance    |

which is getting more complex, showing that the user may need to go back
and forth to the map.

        IMPLICATION: uDig needs a way to go from the Operation GUI back
        into a 'input via map mode'.

During output, we need to distinguish the processes that create new
layers from those that modify existing layers even if the rest of the
process is identical. Someone brought this up on the mailing list as
'operations' versus 'tools'. They have a good point but it may not be
that we want to make an initial terminological distinction as much as
let users pick which way they want to go: into same layer, into a
temporary layer or into new, saved layer? With initial data or without?
With initial attributes or without? Note, that for now, if we go into a
new layer, uDig will ask the users on exit if they want to save the
layer to a file.



On GUI:
--------

The GUI needs to be (1) efficient (2) easy to figure out (3) consistent
across operations. As I have just shown above, the GUI also needs to
allow users to go back and forth between the map and the inputs. 

You've chosen the 'druid' or 'wizard' multi dialog approach. This is an
easy choice when there is only one operation but one which may make less
sense when a user wants to do repeated analysis. For example, if a user
is trying to find by trial and error a buffer distance that works,
having a druid is painfully slow. 

In eclipse it would be possible to have a 'view' for all the user input.
This might be divided into three areas or three tabs depending on the
complexity of the input. That view could even have a standard location,
say across the bottom, in an analytics perspective. I suspect that this
will lead to much faster workflow for anyone doing serious analysis. 

Ideally, I'd like us to think about these two approaches, and think
about them in the eventual state where uDig will have twenty to thirty
core operations and a massive number of user created operations.


On a different tack, the GUI should provide users with some graphical
examples of each action, so, for example, users can see the semantics of
'merge' without having to figure out exactly whose terminology is being
used. These are all set theoretic operations which have been talked
about with lots of different vocabulary in different domains. For each
operation, I can guess what it might do without being sure of the
semantics (eg do I get 1 feature or many at the end? Do I modify the
layer or am I going to get a new one? Are new nodes being crated?). A
diagram, carefully and correctly constructed, could save users having to
read the text and interpret it really carefully.





On the Buffering Operation:
--------------------------

You have set things up so your 'buffer' layer has as many features as
the original. In common situations, this will *not* be what is wanted.
The general use of buffer is to end up with a single geometry, the
'merge' of what you currently create. So we need to let users pick
between the two results.

Consider also buffering a stream network, which is made up of a series
of interconnected stream segment features. Buffering the whole thing
into one final geometry is straight forward. Buffering each feature is
also straightforward but gives a result that is not really what will be
desired. If we want to create 'areas of responsibility' we need to
buffer each feature and then divide overlaps by nearest neighbourhood.
That means, on an intermediate segment of the network, a stream feature
buffered as a separate feature will have the two terminal semi-circles;
those will have to be cut off by the vornoi.



Conclusion:
-----------
As you see, even this simplest spatial operation, for which all the
computational infrastructure is in place in JTS, still leaves a lot of
work to be done. I suggest we focus on this 'Buffer' as an example of
all spatial operations and get it working. We will need to keep in mind
how the operations which need several input layers, e.g. clip and merge,
or result in several output layers, e.g. divide, alter the workflow and
UI requirements.

hope that's enough to ratchet up your thinking a notch,
--adrian