Future direction

[Bernhard Reiter]

On Tue, Jan 11, 2000 at 09:30:01AM -0800, Rich Shepard wrote:
> On Tue, 11 Jan 2000, Bernhard Reiter wrote:
> 
> > > Angus Carr wrote:
> > > > Based on one day's return comments, people on this list see the
> > > > "arcviewization" of GRASS as a good possible thing.
> 
> > The tale is that a good programmer knows, when to start over again and
> > put code aside. GRASS is a very useful and rich GIS tool, but I cannot
> > see how it will ever be a simple mapping and visualisation tool.
> 
>   I read a bit of confusion here. 

Well at least about the different spatial data processing software
tasks. I did not take the time to explain them all in my last post.

> The Microsoft-centric world started with
> what we would consider GRASS to be: a GIS-engine used to enter, store,
> manipulate, analyze and report on spatial data. 

> "Desktop mapping" was/is aimed at the business market and the
> focus was on pretty displays (on screen or paper) with comparatively simple
> and limited analyses. 

> ESRI saw the potential of this market (i.e., end-user
> oriented rather than guru-user oriented) and entered with ARCview.


> I suggest that there is great value in taking GRASS in both directions. 

I tend to differ.
From the software engineering point of view the core and frontend idea
is not the problem here. From my personal impression of the GRASS source
code I think it will be a major undertaking. It might be easier to start
from scratch (of course taking the source code and knowledge from GRASS
not tabular rasa.). 
The main reason for this is the integration of exploration functions and
the GUI. The data structure and program logic behind something like
ArcView has to be completly different to enable the program to be
interactive and nice to create maps.

>   A MapInfo/ARCview type end-user UI would be the perfect front end to GRASS
> in business applications. The command line and GUI interfaces can be
> developed in parallel for those who need (or prefer) the increased power and
> accessibility to functions.

Again, as someone, who as worked with advanced User Interfaces I believe
that the ArcView Interface is significantly sub-optimal.

The next step will be task orientated components and 
the integration of them. ArcView always had the bloat-ware concept build
in. (Though they talk about components, but they mean internal
components.)

>   As for languages, I prefer C and gtk+ for the UI. I recognize that we need
> something to make GRASS accepted by the Windows user, and I defer to those
> of you with more expertise in this area. The UI for linux, solaris or
> win9x/Nx/2x should be interchangable modules.

wxPython runs on Gtk+ on Unix. :)

Just my 0.03 Euro,
	Bernhard
-- 
Free Software Projects and Consulting 		         (intevation.net)  
Association for a Free Informational Infrastructure            (ffii.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 236 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-user/attachments/20000113/a00ccacf/attachment.bin