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

Benjamin Ducke benjamin.ducke at ufg.uni-kiel.de
Sat Jul 28 04:58:25 EDT 2007 


Thomas Adams wrote:
> 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…

Well, if you do C coding for GRASS, you will probably find GEM pretty
handy because it allows you to keep your code in a source directory
separated from the main GRASS CVS tree (and neatly packaged along with
your documentation, ASCII readmes etc.). This makes your code easier to
maintain and update if you prefer to keep development in your own
organization or are the only one working on it, anyhow.
Also, deploying your own extensions on Unix machines is very easy with
GEM. On the other hand, if you want your GRASS developments to become
part of the mainstream CVS code, there is no reason for using GEM.
Also, GEM is really meant for packaging whole extension, i.e. groups
of functionally related GRASS modules and/or libs. Not really single
modules. Finally, experience has shown that inexperienced users struggle
with the usage of GEM and the need to have a full set of development
tools (C compiler, make tools etc.) installed on their machines to
install GEM extensions.

That said, I'd love to see someone help improve GEM especially in the
following areas:

- get it running on native Win32 (MSYS)
- support for wxGRASS menu entries
- installation of extension modules using binaries instead of source code
- fine-tuning of the configure and Make systems packaged with each GEM
extension ("skeleton" files).
- a GUI for GEM with interactive admin password entry if needed

I think it is a really useful tool for developing and deploying complex
sets of GRASS add-on modules that are not meant to be hosted in the main
CVS repository. It has done a good job for me for many years now.

Benjamin

> 
> 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
>>
>>
>>   
> 
>

More information about the grass-dev mailing list