[GRASS-dev] GRASS "custom" applications

[Thomas_Adams2]

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

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

EMAIL: thomas.adams@noaa.gov

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

[cmbarton]

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

[cmbarton]

After answering, I looked at your applications. These are web applications.
They can be created with Mapserver, another OSGEO project.

Michael

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

Please take a look at this: http://www.erh.noaa.gov/er/ohrfc/fop.html

__________________________________________
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

[Thomas_Adams2]

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

Regards,
Tom

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

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

EMAIL: thomas.adams@noaa.gov

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

[cmbarton]

Hi Tom,

See below

On 7/27/07 5:01 AM, "Thomas Adams" <Thomas.Adams@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@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_Adams2]

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@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@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@noaa.gov

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

[Thomas_Adams2]

Timmie,

Thank you for the suggestion; it's certainly something to explore.

Regards,
Tom

Tim Michelsen wrote:

Hi!

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:

What about using Qgis python bindings together with the Grass plug-in:
http://blog.qgis.org/?q=node/29
http://blog.qgis.org/?q=taxonomy/term/2
example:

http://blog.qgis.org/?q=node/73

Regards,
Timmie

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

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

EMAIL: thomas.adams@noaa.gov

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

[Paul_Kelly]

On Fri, 27 Jul 2007, Thomas Adams wrote:

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 think you should be able to use *any* GUI toolkit that includes the concept of a "canvas" - you can use GRASS d.* commands to create maps and write the output to a PNG or PostScript file, then load this into the canvas widget in the GUI you have created. This is how the GRASS GUIs work and it's very fast (the time taken to load the image is tiny compared to the time taken for GRASS to generate it). Whichever GUI toolkit you're using should have facilities to collect user-clicked points from the canvas - e.g. a user could draw a shape on the screen and you could collect these co-ordinates and pass them to v.in.ascii (run in the background) to generate a vector map, then overlay the vector on the original image (running d.rast and d.vect in the background, outputting the image to a file) and load the resulting image back into the canvas widget. All this would be totally seamless to the user and take only a second or two. The same for text labels collected from the user through the GUI and then overlaid on the map using the d.text command and that kind of thing.

I have close to zero GUI-programming experience, but I hope I haven't got the basic concepts wrong here - what I'm trying to say is you're not limited to adapting any of the current GRASS GUIs - all they basically are is a canvas widget with a few menus passing pass data in and out of GRASS commands running "behind the scenes". None of the current GUIs interface directly to GRASS in C - it is a much simpler interface than that, but in general this is a strong point: you can use any scripting language and any GUI toolkit.

I think this is the point Michael was making about how the GUI is a really simple layer on top of the GRASS commands, and if your GUI needs are pretty simple - drawing shapes on a map and adding text annotations, for example - it may be much less work implementing it from scratch in your favourite scripting language/GUI toolkit rather than trying to familiarise and adapt one of the existing GRASS GUIs (e.g. d.m, gis.m or wxGRASS) - I hope I haven't made it more confusing!

Paul

[Glynn_Clements1]

Thomas Adams wrote:

Thanks for taking the time for the thoughtful responses. I very much
want to contribute e$(G!7e(B and I think I can e$(G!7e(B 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 & Motife$B!De(B

For GUI code, we normally use interpreted languages. Previous GUIs
(tcltkgrass, d.m, gis.m) used Tcl/Tk, the next one will use wxPython.

Mostly, we try to avoid doing "real work" in the GUI. Instead, GUI
actions invoke external commands which generate images which are then
displayed by the GUI.

This has the advantage of limiting the amount of code which is "tied"
to the GUI. E.g. if you wanted a web-based interface, all of the
external commands which the GUI uses can be called just as easily from
a CGI script.

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

In some respects, this might be a bad time for that. The existing GUI
is planned to be replaced, but its replacement is really still at an
"alpha" stage.

Conversely, if you want to help out, generic GUI programming
experience is probably more useful than specific knowledge of the
code. Development of the new GUI is still at a early enough stage that
nothing is set in stone yet.

--
Glynn Clements <glynn@gclements.plus.com>

[Benjamin_Ducke3]

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