[GRASS-user] GRASS "custom" applications

Fri Jul 27 12:12:29 EDT 2007

Michael,

Thanks for taking the time for the thoughtful responses. I very much 
want to contribute — and I think I can — it's more a matter of finding 
the time (as I'm sure it's true for you and others). I don't know 
Tcl/Tk, but I'm sure I could mess around and do OK (I do my programming 
in Perl & C mostly, but also *some* simple shell scripting). My 
programming background includes X Window System & Motif…

I have seen on the developers' mailing list that Benjamin Ducke's GEM 
(GRASS Extension Manager) and William Kyngesbury have been doing the 
work you mentioned, but I have not paid *that* close of attention to it. 
I guess I have been waiting for these efforts to reach fruition to get 
serious about following their developments.

However, I have been involved with the U.S. National Weather Services' 
effort to develop some policy about GIS use in our operational systems. 
ArcGIS, for example, does not fit very well for a couple of reasons: (1) 
cost and (2) we use Linux and want to stay open source. So, it *looks* 
like the recommendation to baseline GRASS (and other open source GIS & 
related tools - GMT, R, Mapserver, PostGIS, etc.) into our systems may 
actually occur. I have been pretty instrumental in carrying the banner 
for GRASS in this. What this means, is that now I have to answer some 
questions that relate to the questions I have been asking. There are a 
lot of very competent programmers in the NWS who could help tremendously 
(there are also a lot of novice computer users as well); but, it's 
falling on my shoulders to demonstrate a couple 'custom applications' 
that duplicate what is already being done in ArcGIS 9.x and ArcView.

I have no doubts that the customizations can be done; I just want to do 
it the most sensible way, that minimizes how much work I have to do and 
that I can show to others in the NWS how easy it is to customize GRASS. 
I really like the GRASS extension manager approach by Benjamin Ducke. I 
would guess that's the way to go…

Thanks again,
Tom

Michael Barton wrote:
> Hi Tom,
>
> See below
>
> On 7/27/07 5:01 AM, "Thomas Adams" <Thomas.Adams at noaa.gov> wrote:
>
>   
>> Michael,
>>
>> Thanks for your feedback. I understand how the GRASS GUI is set-up — as
>> you explain it. I suppose my problem is one of not wanting to break the
>> current GUI, to avoid problems when new upgrades are released, yet
>> simplify the user's interaction with the GRASS GUI for the purpose of
>> using the tools I have in mind. Some of this, I understand, comes down
>> to a design decision on my part.
>>     
>
> Yes. What we have now is a general GUI that attempts to make all GRASS
> functions available to the user. However, it is simpler than most people
> imagine to craft a custom one for a specific target audience.
>
>   
>> I do have a broader question at fits in
>> with what I am asking about, but also affects others who may have
>> similar needs, namely:
>>
>> Should there be some facility within the GRASS GUI that allows people
>> such as myself to generate some GUI tool that can simply be "dropped"
>> into GRASS and appear in some consistent way in the main GRASS GUI? The
>> main GRASS menu bar *may*, for instance, have a new 'Other' or 'Add-on'
>> or 'Custom' or 'Tools' or whatever menu item to go with the existing
>> ones ('Raster', 'Vector', 'Imagery', 'Volumes', etc.). Or rather than a
>> main menu bar item, there could be an icon selection button, for
>> instance. So that, if someone like myself were to add some new GUI
>> component in the way I previously describe, then the item would appear
>> under the new menu item. The 'dropping' into GRASS may consist of some
>> standard subdirectory in the GRASS build where a subdirectory would be
>> created by me or others (for each of their 'projects'), where the coding
>> and some naming convention, etc. would be expected to meet certain
>> guidelines in order for it to appear in the GRASS GUI.
>>
>> In this way, there would be both straight-forward programming standards
>> and easy user access to the new tool without breaking the interface when
>> new GRASS GUI builds came along. Just a thought…
>>     
>
> This is actually 2 questions. For the main one, there are a couple attempts
> in progress to do exactly what you describe. These are Benjamin Ducke's GEM
> (GRASS Extension Manager) and William Kyngesbury's GRASS modbuild. There
> have been some discussions about merging these 2 efforts. From an observer's
> perspective watching discussions on the dev list, there seem to be 2 issues
> that need to be resolved: 1) where to put any custom modules given that the
> 'best' place varies by OS; and 2) how to automatically embed custom module
> commands into the GUI menu. There is progress being made on both fronts. If
> you have interest in this, help is needed to move this forward.
>
> The second, implied question, may be more helpful to your immediate needs.
> Both for TclTk and wxPython, the actual interface files are simply ASCII
> text scripts. So you can modify them to your heart's content without
> compiling. This means that you can (as I've done) engage in a lot of trial
> and error experimentation quickly: change a script, quit and restart the
> interface (i.e., with gis.m for TclTk or wxgrass for wxPython), watch it
> crash, do it again. ;-)
>
> If you have a custom interface for GRASS, you can simply drop it into the
> current GUI folder, make a new folder and change the target of the calling
> script (gis.m or wxgrass), or make a new calling script (e.g., mygui) that
> starts your custom app.
>
> I hope this encourages you to try out some of these suggestions.
>
> Michael
>
>   
>> Michael Barton wrote:
>>     
>>> 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
>>>
>>>   
>>>       
>
> __________________________________________
> Michael Barton, Professor of Anthropology
> Director of Graduate Studies
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
>
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
>
>
>   

-- 
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL:	thomas.adams at noaa.gov

VOICE:	937-383-0528
FAX:	937-383-0033