New GRASSLinks site now running

[Tom Moore]

In mailgate.grass.user you write:

>Simon Cox writes:
>> 
>> While working on this (and earlier) it occurred to me that this kind of
>> point-and-click interface is what has been lacking and criticised
>> in GRASS all these years, for the casual user.  There have been a
>> couple of attempts to develop GUI's - viz. XGrass and LAS's
>> still-to-be-released tcl/tk interface.  I wonder how much of the
>> functionality could actually be provided through html & "forms",
>> so making XGrass and tcl/tkGrass potentially obselete?
>> 
 
>Just a quick comment.  In one word - Java.  

I have thought about how Java might be used in a distributed GIS environment
and I don't think that there is substantial improvement over existing
internet/WWW technology, at least in the near future.

Java provides a platfrom independent application language that can
run on a large variety of platforms.  Programs written in the Java
language can be compiled into byte-codes that can be uploaded via
WWW (or similar transport) and then executed by a Java run-time 
interpreter.  Java has some nice design features:  it has a good
OO model, it was designed from scratch to be secure, and the
implementation supposedly provides very good performance, getting
close to native compiled code speeds.  These are all factors on the
'plus' side.

But the main premise of Java is uploading the application to run
on the client...   allowing better local interaction by avoiding
network latencies.  The network connection latency is the hurdle 
that is being overcome by Java,  and the method is by uploading 
a small, efficient applet that can be executed to do most of the
work.

GIS applications typically operate on big datasets, and that
is why they are usually slow or require fast workstations.
(If there wasn't a performance problem this discussion would
probably be a non-issue).  How can Java help out in this area?
If the big GIS dataset is on the server, then uploading a
client applet probably wont help much, because the data will
still have to be transmitted to the application, and that
is where the bottleneck will occur.   If the GIS data are
located on the client machine, I am not sure what benefit would
derive from uploading network applets.  Wouldn't it be better
to have local software?

I suppose that a hybrid solution would involve truly distributing
the workload by having a smart server compressing information and
delivering it to a smart client.  The client could have a great GUI
to form the request for geograhpic data, and the server could do
a lot of processing to send back just what was needed.  On the
client end, there would be some limited ability to manipulate
the geographic data.  Now I haven't looked into the Java Class library, 
but I doubt that this would be easy.  Part of the speed of Java
derives from primitive operators written in native code.  It is
unlikely that Java would have built in GIS viewport operators.
So these would have to be written in Java using other primitives
(maybe pixel operators) and would probably be extremely
ineffeicient.

My opinion is that the current technique (having a server
accept parameters then generate and upload image) is probably
the best that can be done given *GENERIC* tools such as Java
and HTML.  I think that the interface can be made better,
but it is doubtful that processing will be moved off of the
server.

I do think that there is tremendous potential for *CUSTOM*
distributed geoprocessing tools.  OGIS is an important building
block, but there are many other pieces needed.  Java may or
may not be one of them, but certainly not in its current state.

Of course, this is all IMHO.

Tom




>Mike Bender
>University of Manitoba

--
Tom Moore R.P.F.                                tmoore at pnfi.forestry.ca
Petawawa National Forestry Institute            
Canadian Forest Service, Box 2000, Chalk River  +1 (613) 589-3048
ONT K0J 1J0  CANADA                             +1 (613) 589-2275 telefax