[
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
|
Hi Jesse, first we propose to resolve some Operations and Editing tools, then
we found a lot of similar operations in different products (esri, grass,
etc), but there is not a consensus about:
name operation / tool -> semantic
Then, we decide take two requirement (Merge and Buffer) to offer a concrete
discussion subject to attempt to arrive at conclusions that could be taken as
start point to others requirement.
Talking about Merge and Union Paul Said:
"...They really are quite different operations... I think you might
distinguish between "tools" which work on layers in place and
"operations" which process inputs to create outputs? ..."
We have gotten this concept to define tools and operations.
Operation Definition:
Does not modify the source features and produces a new content.
Not undouable.
Does not block the source layer.
Blocks the target layer until it finish.
Tool Definition:
It could modify the source features.
It is undoable.
Blocks editor until it finish.
It can have implications in the future development, so Operations could be run
in background process blocking only the target layer. Maybe the operation
take a lot of time, the user could continue his work editing other layers.
BTW, tools could modify source features, geometries and alfanumerical data,
user decision are required because this transaction could "delete features".
The feature could be presented in many layers and the state is not consistent
until to get the final result of transaction.
Adrian Custer do a lots of interesting considerations (included below) about
usability that we are thinking to include in.
Our strategy is iterative and incremental and we pretend release some features
that could be improved in the future.
We will appreciate your feedback a lot. You can see more on Axios Community
space.
Best regards.
On Thursday 25 January 2007 16:11, jeichar@xxxxxxxxxxxxxxx wrote:
> 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
--
Mauricio Pazos
Director
Axios Engineering
www.axios.es
e-mail: maurcio.pazos@xxxxxxxx
tel-:+34 94 441 63 84
fax: +34-94 441 64 90
