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

[Jesse Eichar]

On 25-Jan-07, at 1:47 PM, Adrian Custer wrote:
Hey all,

Congratulations to the Axios team for keeping at this! You've got some
really useful functionality coming along. It's good to see you  
thinking
globally about the design and I'm glad things are coming along so  
well.

My comments below are meant to encourage you to take a usable  
design and
make it fantastic. They come out of ideas I struggled with last year
when I tried to do a buffer operation---they are meant to get a
world-class design in place so we then can readily code up all the
different kind of operations we will want.

Do you have an update site so we could try out your work? If not I can
only comment on what I see in the images you put on the wiki.


Overall comments:

Based on the experience of the Gnome project, we came to think in  
terms
of workflow and speed. For example in buffering, we can expect a  
bulk of
users to want to make a simple buffer at a fixed distance to see it on
the map, another bunch will want to try several distances and  
eventually
settle on one, another bunch will want to tweak the process in  
infinite
detail. The best free software makes it easy to be fast by hiding the
details from most operations; because we can't make decisions for  
users,
we also need to provide a way to slow down and tweak all the detail. I
would encourage you to think in those terms: fast for most users  
with a
way to tweak the details if the fast is not right. So a user wanting a
new layer with a 100 meter buffer should be able to generate this in
five clicks max. For users trying different distances, you might want
feedback on the map showing a preview of the buffer of at least  
some of
the selected features. For users with complex needs, we can give  
them a
button to access that.

I'm still not sure about the trim/operation split. There is an elegant
split for in place vs into new layer so if that's the split, I can be
happy with the distinction. Tools essentially become operations with
known destinations. However, I don't see that split as necessitating a
view / dialog split. The trim tool, for example, might be better as a
view so that the user can first select the layer to trim (say a  
property
boundary polygon layer) but then later select from another layer the
river feature to trim the polygon layer (say everything on the left  
bank
of the river).


OPERATIONS

The buffer operation:

1) uDig has a serious design constraint due to the RCP design in  
having
the visual map extent dependent on the outer shape of the user window
and on the particular shuffle of the views on display in the GUI. What
happens when a user first opens the buffer view? Does the map  
resize to
show all the previously visible extent in the now smaller window?

        JESSE, can this become a uDig wide behaviour 'Adding a view  
will
        rescale the map so that the entire extent previously  
visible is
        still visible'?

I'd rather not as I want to remove this restriction.  I was a  
mistake.  If we have 2 views of the map they can't each change the  
map.  I will try to address this soon.


2) The UI in the view should be more strongly grouped. Could you  
put in
a border around 'Source' and 'Target' (perhaps call the latter  
'result')
so a user would see a clean split of Source/Result/Options and the
overall 'Accept' button. (BTW, there is no need for the close button
since there's one on the tab and until the user has done something,
nothing has happened.)

3) The 'source' layer should be a list of layers and features. Somehow
we need to suggest to users that they can simply do those selections
with the mouse---That is, we need to show that the Source is 'active'
and will change if the selection changes. (Thinking in more general
terms, where operations require two selections, we need to show  
when one
area of the Operation view is receiving input as against another.  
Think
of a 'clip' operation where a user needs to select the clipped  
features
and then select the clipping features.) Perhaps there is a way to  
put an
alpha mask on all the non-selected groups and have the currently
selected input group visible without a mask.

4) We might want to generalize the approach to operations by  
considering
the common elements involved. For example, all operations will require
several GUI element groups:

        Title
        Demonstration visual (e.g. Unbuffered pts -> Buffered pts)
        Options
        PerformButton

ideally, the 'Options' provide a limited set by default and an
'advanced' button to expand the options to more details. For  
buffer, the
simple options are 'output layer' and 'distance'. The advanced options
include:

        which unit - 'distance in layer unit rather than renderer
        units', (note that CRS is not enough since your two axes could
        be in different units)

        what result - if the 'buffer' is one merged multi-polygon or a
        polygon for each input feature,

        ...

5) We might consider a generic "Operation" view instead of a view for
each operation. I imagine the tab would read "Operations" and the top
would be a drop down list of Operations. Then below that we would have
the standard
        'visual/options | PerformButton'
combination which would change according to the selected  
operations. The
Options would have a standard
        Input / Output / Settings | Advanced Settings
split.

        See the attached image for a mock-up (a quick and dirty
        example).

6) The Operation views have to function in either the column or
landscape view. That is, if possible, a user should be able to  
choose if
they have it next to or above/below the map.


TOOLS:

* On the toolbar, maybe the spatial tools should have their own group
and perhaps a different shading (e.g. the green tools are spatial
tools).


Merge Tool

1) Where do the new1 and new2 come from in the dialog? As I understand
it, we will only have a single new layer at the end of the tool
operation. It sounds like you duplicated the source features to start
with. If so, the user should *never* know that you are doing this.
That's an internal decision you made about the implementation. From a
user standpoint, I'm merging the two original layers into a new layer.

2) The Feature merge dialog will need work. uDig needs a standardized
approach for putting attributes from existing layers into a new layer.
This is actually a very hard problem. Things like densities will  
have to
be re-calculated. Some attributes will only apply to part of the  
merged
results. Some will probably have to be hand edited as a late step  
in the
merge process (obviously we can't do this until we have table editing
capabilities but you should consider that as a step to be added
eventually into the workflow).

3) Note that the generic result of merging several layers of polygons
will be a multi-polygon. It will be fairly rare to have a single  
polygon
as a result. So I'm not sure if we want to standardize all outputs  
from
the merge operation on the most general result for consistency.

Trim tool:

1) The arrow doesn't work visually for me. It seems like you should
indicate what will be trimmed with both the arrow and the polygon  
to its
right. I imagine a red arrow and a grey alpha mask polygon extending
infinitely to the right---not sure how this would work on a 3D  
globe...

Trim/Split tools:

1) you might consider allowing the user to draw a line (continuous set
of line segements) and trim or split based on that rather than on a
simple line.

2) Similarly, you might allow trim/split based on a feature in a
different layer.


Hope these ideas help you. Sorry that doing this well takes so  
long. We
all know that creating a simple buffer process is simple. However,
making the tools fantastic will have a huge impact on user experience
and on the eventual adoption of uDig so I think it's worth the extra
work.

all the best,
adrian



On Thu, 2007-01-25 at 12:33 +0100, Victor Mauricio Pazos wrote:
Hi Adrian, we are planning Spatial Operation and Editing Tools  
project and we
have taken into consideration your suggestion.

We have planned to refactor buffer UI in 0.1.0-rc1 Iteration.
http://udig.refractions.net/confluence/pages/viewpage.action? 
pageId=9643
Is it more adjusted to your idea? Do you want suggest anymore?

Additionally, we agree about the tools and operation definition  
problems, I
can not find definitions but I think, the distinction between  
tools and
operations could be important to take some implementation  
decisions and to
establish a user language in uDig. Then, we propose initial  
definitions and
classify the project requirements taking into account  some Paul e- 
mails
(union merge sujects).

http://udig.refractions.net/confluence/display/COM/Spatial 
+Operations+and+Editing+Tools

Nowadays, we are working in 0.1.0-m3 - Intersect, Clip, Trim, Split.
http://udig.refractions.net/confluence/pages/viewpage.action? 
pageId=9560
Comments?

Thanks a lots

Best regards

--
Mauricio Pazos
www.axios.es

On Wednesday 06 December 2006 11:19, Adrian Custer wrote:
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
<OperationView-buffer.png>
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel