[Qgis-developer] Processing: module duplications

[G. Allegri]

The tagging system would be great, and in the future we can imagine a
system to let a user groups algorithms under its own groups (like favorites
links in the browser).

Vector and raster menus should at least point to the Processing tool
window, in case the algorithm is there too...

I still miss the semantics of the "normal" group. This word doesn't mean
anything to me as a grouping, but I see I'm the only one with this doubt :)

giovanni
Il 24/giu/2014 10:10 "Alex Mandel" <tech_dev at wildintellect.com> ha scritto:

> I disagree, the Vector and Raster menus are the Basic algorithms.
> Opening Processing is the Normal+Experimental as Paolo described.
>
> Moving everything to Processing just makes it harder to find the simple
> stuff. Another major GIS project many of us know took this approach and
> it's extremely annoying to sift through 300 methods when you just want a
> Clip. 1. Finding and remembering where the tool you want becomes harder,
> 2. Searching gets challenging with many similarly named things - wait is
> that the raster clip or the vector clip?
>
> Not saying a level filter in the Processing box won't be good, just
> don't eliminate the simple menus even if it is a duplicate.
>
> Thanks,
> Alex
>
> On 06/23/2014 10:06 AM, G. Allegri wrote:
> > I've given a look to the list of Processing QGIS geoalgorithms and I've
> > seen that all the tools from fTools seem to be there. I remembered that
> > someone was missing, but it seems not to be true anymore. I wonder if it
> > wouldn't be the case to drop fTools algorithms from Vector menu. It would
> > help in avoiding confusion, imho.
> >
> > giovanni
> >
> >
> > 2014-06-23 18:50 GMT+02:00 G. Allegri <giohappy at gmail.com>:
> >
> >> Hi Paolo,
> >> I agree with you, a cleaner organization of Processing tools is
> advisable
> >> to reduce the confusion in users.
> >> It's rather difficult to teach them in a clear way too! :)
> >>
> >> IMHO this reorganization should consider also the integration of other
> >> sparse analysis/processing tools, like the ones under the Vector menu. I
> >> know it depends on their implemention (and its feasibility in the
> present
> >> Processing model), but it's one of the major sources of confusions or
> >> users. A typical question: why we have the Processing toolbox and a
> Vector
> >> menu, where some tools overlap, while other are only available under
> Vector
> >> menu, and so not usable inside a Processing model/workflow?
> >>
> >> I hope we will find time (=money) to close this gap and, hopefully, have
> >> most of the analysis tools under the same structure. Well... all but the
> >> C++ ones :(
> >>
> >> giovanni
> >>
> >>
> >> 2014-06-23 18:42 GMT+02:00 Paolo Cavallini <cavallini at faunalia.it>:
> >>
> >> Hi all.
> >>> We are thinking about the future of Processing framework. The
> duplication
> >>> shown among
> >>> modules is certainly a good thing, as it allows richer analyses and
> more
> >>> control and
> >>> verification, but can be intimidating even for skilled GIS users.
> >>> We have been discussed this before, but I came up with the conclusion
> >>> that a
> >>> reasonable approach would be to have three levels:
> >>> * basic - only one choice, no overly complex modules
> >>> * normal - all well tested modules, minimizing duplication
> >>> * experimental - out in the wild, all modules.
> >>> This would improve the user experience, and would require less
> >>> maintenance by core devs.
> >>> Of course the selection of the modules for the second category is
> rather
> >>> complex, and
> >>> would require much thinking.
> >>> Opinions?
> >>> All the best.
> >>> --
> >>> Paolo Cavallini - www.faunalia.eu
> >>> Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
> >>> _______________________________________________
> >>> Qgis-developer mailing list
> >>> Qgis-developer at lists.osgeo.org
> >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140624/9e668099/attachment-0001.html>