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
