[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Re: Work required for (was:) Spatial Operation andEditing Tools
|
I think I missed the first part of this conversation. Could I get some
background on the problems you are having?
Jesse
Quoting Victor Mauricio Pazos <mauricio.pazos@xxxxxxxx>:
> 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
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
