GUI again!

[Roderick A. Anderson]

I've been following the GUI discussion but since I'm not a GISer (only an
open source, linux, GRASS fan) I've stayed out of the fray.  That is until
now and only to point out what can be done pretty-map-wise right now. (And
in fact using GRASS 4).

Take a look at the site

	http://www.dogwander.com

All of the maps and most, if not all, the html is generated using scripts;
GRASS and shell.  I've attached Doug's message about how he generates this 
site and some of his plans for the future for those interested.

This might also be a good example for a link from the GRASS web site.

Enjoy,
Rod
--
Roderick A. Anderson
raanders at altoplanos.net               Altoplanos Information Systems, Inc.
Voice: 208.765.6149                            212 S. 11th Street, Suite 5
FAX: 208.664.5299                                  Coeur d'Alene, ID 83814

-------------- next part --------------
To: Rod Anderson

Subject: Getting from scientific data, to GRASS, to a useful image, to a
Web page, to a human.

Scripts using GRASS to generate maps using vectors, sites, and raster
data are fairly simple, the hard part is just knowing what GRASS tools
do...and there's a bunch of em!.  It's a matter of plugging GRASS
commands into your scripts in the necessary sequence.  I have scripts
that execute ten or fifteen GRASS commands in a row and it all happens
surprisingly fast. Your scripts can then use new vector, sites, and
raster files you generate to eventually set up a file to be read into
ps.map or p.map (the GRASS hardcopy output commands). 

After you generate a map and have it in a viewable format such as a .ps
file you can then convert it to a png, gif, or jpg using a conversion
program. At that stage you then place the image file into your html, or
better yet write another script that builds the html code placing
instructions, the GRASS maps, site descriptions, etc. wherever you need
it within the Web page. 

This is all useful only if you understand the nifty tools
of GRASS.  Just about every command in GRASS can be executed within a
script and output to a file that in turn can be used by another GRASS
command or another script.  In this way you can build a whole process,
automated from start to finish, with variables, that ends up as a
useful, color picture on one page.  It's a
nonprogrammer-technical-communication graduate's fantasies come true!!!

Creating maps in this manner is now practical for fairly specific, daily
routine purposes that don't require a lot of formatting changes from one
map to another.  For example: at www.dogwander.com my visitor
information maps come in only two different output sizes and are placed
with the same set of instructions etc. always formatted identically. 
The variables are: the area mapped, the sites, the html image map
location points, and descriptions of the specific sites. The finished
map placement and text placement is always output in the same format.
But, the information on the map changes, that's the important part.  The
information itself is generated from your own data files and that data
can be updated all the time.  Creating the scripts to handle the
variables and the html codes for the image map(the clickable yellow
dots) is the tricky part. (I am for hire!)  And, of course, you must
output maps and information that somebody values or you're wasting your
time.

Now, if a Web server were to have a special directory running GRASS all
the time, along with a good image conversion program, and CGI scripts
were used to execute the GRASS and image conversion commands on that
server, many wonderful things could be done for local scientists,
realtors, govt agencies, and even us common folk.  Scripts similar to
the ones I use for my site can be edited and fine tuned for the specific
needs of local organizations.  GRASS running on a server wouldn't be to
hard to set up for you Linux experts would it?  I could create some
fairly
simple scripts that would allow a web page visitor (a local scientist,
or wandering dog) to make some basic choices according to his or her
immediate needs, those choices would then be passed on to GRASS scripts
as
the variables, that would in turn generate GRASS vectors, sites, and
rasters and send the results back in a neat, colorful, html file for
viewing and printout by the Web page user (for a fee of course). Typical
scripts that I've created take GRASS just a few seconds to run. If
rasters
are generated, great care must be taken to adjust grid resolutions with
changes in area size so GRASS doesn't churn for long periods of time. 
Simple scripts can handle all of that too.  

I am not a Linux pro, networking pro, or a programming wiz (I approach
expert level only at drinking Microbrews) but I believe I can coax GRASS
into doing just about anything practical. One huge advantage of using
GRASS instead of mapping programs is the ability to overlay the maps
onto water, elevation, land use images, etc.  Another, is GRASS and
Linux are free!  GRASS is like a huge garage full of great tools, fun
gadgets, and nifty toys.  Linux is the high voltage power that runs
them.  The builder simply uses the right tools in the right order to
complete the finished product.  The projects to be created are limited
only by the artists imagination. (...oh yes, making a map that anyone
can read, and wants to, is an art).

Let's start imagining!!!   


Doug Merrick
dmerrick at dogwander.com

PS. ( To any interested party. I'm a rare GRASSer for hire.  Rather than
trying to figure out what the hell I just said above, make me an offer).