[GRASS5] Proposal for GRASS UI roadmap

Mon Nov 7 23:49:02 EST 2005

I tend to agree with Martin on this. If QGIS were to embed all the
functionality and flexibility as GRASS, it would no longer be the fairly
slick, quick program it is now. The button bar is already getting pretty
busy (40 buttons with GRASS plugin installed, including 3 pull-downs, vs.
GRASS's 34). 

I actually like the GRASS interface in many respects (but of course I would
wouldn't I?), and am most annoyed by the need to call programs like d.mon
and d.zoom for manipulating the display. Like Martin, I also like having
multiple windows to work with.

There need to be programs like QGIS that are efficient viewers coupled with
basic GIS capabilities. I like QGIS a lot and I hope QGIS can come to view
GRASS files on a Windows platform and without having to open it from within
GRASS. This would make it excellent for classroom use as well as for a broad
spectrum of users. 

However, QGIS and other similar programs like JumpGIS and Thuban differ from
programs like GRASS (and ArcInfo or Idrisi) that are focused more on
research and analysis. I asked about the possibility of merging QGIS and
GRASS projects some time back. It sounds like that is not in the cards for
the near future at least, as QGIS has a somewhat different, but equally
important, set of goals from GRASS.

It would be nice if we could have one program that could meet all these
needs, but I'm not optimistic about whether we can (or even should) do that
at present. Nevertheless, I think it IS important to try to make even
complex programs like GRASS more accessible to a wider audience. This is an
important reason that we need to start planning the GRASS UI and not just
let it happen. QGIS has many nice features and great functionality for some
things. When improving the GRASS UI, we should look at QGIS closely--and at
other GIS projects. QT may be a great platform for the future GRASS UI. Or
it may be GTK, or even a beefed up TclTk. We may even decide on UI that
looks so much like QGIS that we want to build directly from that platform.

But before we make these decisions, I think we need to think about what a
21st century GIS package ought to look like and do. This will help us plan
how to carry this out better.

Cheers
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

> From: Martin Wegmann <wegmann at biozentrum.uni-wuerzburg.de>
> Reply-To: <wegmann at biozentrum.uni-wuerzburg.de>
> Date: Mon, 07 Nov 2005 15:17:41 +0100
> To: <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Proposal for GRASS UI roadmap
> 
> On Monday 07 November 2005 10:23, Paolo Cavallini wrote:
>> Just a short note (hope nobody will get offended by it):
> 
> I hope so as well ,-)
> 
>> I think Michael 
>> and others have done a great job improving the tctk interface (every time I
>> compile grass, I have pleasant surprises!), but it is a reality that
>> "normal" people sees its look&feel as rather primitive. What we (grass and
>> freeGIS users and developers) need is enlarging our user base, far too
>> small compared to grass potential.
>> Our experience teaching FreeGIS is that integrating grass with qgis gives
>> an easy way of approaching gis problems, without a steep learning curve.  Of
>> course issues remain; in my view:
>> - integrating NVIZ (the work from ACS is a good first step in this
>> direction) - putting most/all grass modules in the qgis-grass dialog (not
>> difficult, but may be boring)
>> - multiple monitors: I got used to them, and I agree they are very useful,
>> but most people stopped using in most applications anyway
> 
> very important point. All raster manipulation programs (from GIMP to
> ERDAS/ENVI) work with multi-monitor setups and I got used to them very much.
> Perhaps the user should be able to decide if he/she wants a multi- or
> single-window workspace.
> 
>> Moreover, we have the advantage of working with the live and thriving qgis
>> community, which is an extremely positive factor.
>> I am worried about the duplication of efforts I have seen recently; we have
>> limited forces, and we would better concentrate on a common line; for
>> instance, I do not think a printing interface can be much better than the
>> one currently available in qgis.
>> In short my suggestion is: let's concentrate on qgis as a frontend, and
>> strengthening grass as backend (eg fixing functionality bugs, making new
>> modules, releasing new versions more often).
> 
> well, as I agree with you that "usual" users think that the tcltk UI is
> primitive however I doubt  that GRASS-d.m shall/can fully merge with QGIS and
> fullfill all user interests which Michael is currently inquiring.
> 
> I use QGIS frequently to view raster data/vector data (and hopefully soon)
> modify vector data -- in general: doing "low-level" GIS work which can be
> achieved using QGIS very easily.
> For this kind of work I don't need a fully-blown GIS/Raster manipulation
> software like GRASS. I want QGIS to start quickly, do my work and exit again
> unlike GRASS which is running nearly permanently and which I favour because
> of the enormous amount of  functionalities.
> Perhaps the comparison between ArcView and ArcInfo is best. The first one is
> for low-level GIS work, the second is for all the other work. I don't want to
> start ArcInfo functionality when I just want to do some quick modification.
> 
> With GRASS and QGIS we have the same problem (in my opinion) plus the problem
> that GRASS is not only a GIS but a raster manipulation program as well which
> needs a CLI too. 
> 
> This does not contradict your idea of using GRASS commands inside QGIS but
> using GRASS solely via QGIS.
> 
> Concerning the man-power for GRASS C coding; I am not sure about it but I
> think that C programmers and QT/GTK programmer are different kind of persons
> or at least their interests are different. At QT/GTK programmer is keen to
> develop a UI but not to code C, therefore I think the amount of
> C-programmer-man-power would not be diminished.
> 
> regards, Martin
> 
>> pc
>> 
>> At 05:59, domenica 06 novembre 2005, Michael Barton has probably written:
>>> Colleagues
>>> 
>>> A couple months back I suggested a discussion on the specifications for
>>> the next generation user interface for GRASS. Perhaps because it was
>>> summer--or perhaps because everyone is just so happy with what I¹ve done
>>> so far ;-)--there were few takers. However the comments were useful. I¹ve
>>> included all of them in the attached text file as I promised to do.
>> 
>> ...
> 
> -- 
> Martin Wegmann
> 
> DLR - German Aerospace Center
> German Remote Sensing Data Center
> @
> Dept.of Geography
> Remote Sensing and Biodiversity Unit
> &&
> Dept. of Animal Ecology and Tropical Biology
> University of Wuerzburg
> Am Hubland
> 97074 Würzburg
> 
> phone: +49-(0)931 - 888 4797
> mobile: +49-(0)175 2091725
> fax:   +49-(0)931 - 888 4961
> http://www.biota-africa.org
> http://www.biogis.de
> 