[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] Re: Work required for (was:) Spatial Operation and Editing Tools
|
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
