[GRASS-dev] Re: [GRASS-user] GRASS "custom" applications

[Michael Barton]

It is relatively straightforward to create a custom application with GRASS
because all (or very nearly all) GRASS functions can be run as a series of
ASCII commands with arguments and switches.

In essence, this is what the current TclTk GUI and development wxPython GUI
do--execute a series of GRASS commands.

One easy thing that you could do to start is simply begin with the current
TclTk scripts and get rid of anything you don't want to show from the menus
(gmmenu.tcl) or toolbars (gism.tcl and mapdisp.tcl).

Michael


On 7/25/07 3:48 PM, "Thomas Adams" <Thomas.Adams at noaa.gov> wrote:

> Folks:
> 
> Please take a look at this: http://www.erh.noaa.gov/er/ohrfc/fop.html
> 
> which was created using ArcGIS 9.x through some customization of the GUI
> to make the creation of the graphic a one-step process. Now, this
> graphic could easily be created using a script in GRASS (or, presumably,
> in ArcGIS), so it's an uninteresting example. But we use the graphic to
> depict areas of potential flooding (as indicated by the legend) by
> drawing color-filled polygons with text annotations to indicate the
> period over which the flooding is likely, as shown here:
> 
> http://www.srh.noaa.gov/wgrfc/fop/wgrfcfop.html
> 
> for a different region of the U.S. My question is this: how should I
> proceed to do this through some customization of the GRASS interface to
> "hide" GRASS details using a somewhat simplified GUI tool. I should add,
> that the flood risk polygons are exported to a text format file, which
> is then transmitted to a national center to generate a National product
> like this:
> 
> http://www.srh.noaa.gov/wgrfc/fop/wgrfcfop.html
> 
> I am also interested in an unrelated 'custom applcation' that would
> essentially combine a series of GRASS analyses into single step
> processes utilizing the GRASS GUI to initiate the analyses and set some
> parameters ‹ for various hydrologic analyses, including:
> 
> (1) identification of snow elevation zones (disconnected regions within
> a watershed, above a certain elevation)
> (2) basin boundary delineation for a set of watershed outlets (utilizing
> r.water.outlet, etc.)
> (3) model parameter estimation
> 
> I think most of this could be done as GRASS add-ons; would this be the
> way to go, or would embellishing the GRASS Tcl/Tk interface be necessary
> (something I would rather NOT do for several reasons).
> 
> Thanks for any and all feedback!
> 
> Tom

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

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