[GRASS5] Proposal for GRASS UI roadmap

[Michael Barton]

Glynn,

Thanks for the input.


> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Mon, 07 Nov 2005 21:21:24 +0000
> To: Michael Barton <michael.barton at asu.edu>
> Cc: GRASS Developer's List <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Proposal for GRASS UI roadmap
> 
> 
> Michael Barton wrote:
> 
>> ***2D and 3D visualization:
>> 2D and nD visualization should be seamlessly integrated. The "normal" view
>> would be 2D like current x displays and standard GIS. Clicking a 3D (nviz)
>> button would open a floating window with 3D controls (like in nviz now) but
>> not a new display window. This would allow user to tilt, rotate, change z,
>> visually separate layers, etc. It would work with the same layers shown in
>> 2D mode, but would simply display them in 2.5D or 3D. Nviz would not be a
>> separate module, opening a separate display window and separate layer
>> control panel; it would simply display any active layers in 3D "mode".
> 
> Making OpenGL a mandatory requirement could be problematic, i.e. it
> could result in a significant proportion of potential users being
> unable to use GRASS.

OpenGL seems to be becoming increasingly crucial for complex
visualization--including 3D--and such visualization is becoming increasingly
important for GIS and related spatial technologies. It also seems to be
better supported both in hardware and software.

Nevertheless, it is a good idea to keep GRASS as useable as possible for the
broadest possible user base--especially given its popularity
internationally. 

This raises 2 questions to me:

1. Could a display window function without OpenGL in 2D mode, then call
OpenGL IF the 3D mode was invoked? That way, people without OpenGL could use
all the display functions except the 3D mode (much like now when running
NVIZ is not required for standard display).

2. Is there an alternative to OpenGL for rendering 2.5D and 3D imagery that
would work as well but be useable for a wider group of users?

> 
>> DISPLAY CONTROL GUI AKA GIS MANAGER
>> 
>> We should keep single display control (like current GIS Manager). distinct
>> from the  display window(s). This allows for multiple display windows to be
>> controlled from single interface. Display "commands" should be integrated
>> into display control interface; there would be no separate d.* command
>> modules. That is, the display control system should be able to directly draw
>> graphics to a display window, without going through intermediate, stand
>> alone programs. We need to rethink how these would best be implemented
>> (e.g., should we combine thematic vector and chart display functions?)
>> Display functions should still be scriptable as in nviz and d.m, just not
>> independent "commands". It should be possible to run a display script from
>> the command line to automate mapping.
> 
> The main problems with monolithic applications are reliability and
> memory leaks. Having d.rast crash is less serious than having your
> monolithic application crash.

It also depends on how 'monolithic' the application is. I think most people
want most of GRASS to stay modular. However, there seem to be important
advantages to building display functions into the UI. As you pointed out
this past summer, there are equally problems in making the UI simply call a
series of independent display modules for all functions.

The big question is where is the best balance between building better
functionality into the UI and keeping GRASS modular? From my probably biased
perspective, I'd suggest...

Definitely fold into UI: d.mon, d.zoom (including pan), d.erase (separate
background color from erase)

Probably fold into UI: d.measure, d.where, d.what.vect, d.what.rast,
equivalent functions for volumes and 3D vectors, nviz (I think this would be
a great feature if we can do it), xganim.

Maybe fold into the UI: any of the commands that currently create layers in
the GIS Manager (i.e, d.rast, d.vect, d.text [merge with d.text.freetype and
make placement better], etc.), d.frame, and v.digit. Some of these might
better as independent modules while others might function better as part of
an integrated UI/display control. For example, if d.frame were incorporated
into the UI, it might become a much nicer layout manager.

Do not fold into UI: all analysis and file management commands.

As a programmer, which functions do you think work best integrated in the UI
and which are better off kept separate and simply called as commands by the
UI?

> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>


__________________________________________
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