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 -- Mauricio Pazos Director Axios Engineering www.axios.es e-mail: [EMAIL PROTECTED] tel-:+34 94 441 63 84 fax: +34-94 441 64 90 _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
