[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [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 13:32, Victor Mauricio Pazos wrote:
> Thanks for your suggestion Adrian.
>
> Regards
>
> 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