[GRASS5] Re: Complete module list for GRASS-5?

GRASS GRASS developer
1

On Fri, 15 Jun 2001, Markus Neteler wrote:

recently you (Eric) posted a list of descriptions generated from XML.
Do you mind to send the script to me (I don't want to re-invent the wheel)
or add it to CVS?

  Eric did indeed generate such a list and sent it to me. As I reorganized
it yesterday I noticed that it was not complete. For example, as I compiled
the section on remotely sensed data, there was nothing appropriate for
aerial photographs. I added i.ortho.photo but not the internally-called
modules.

  If the same script can be run on the complete source tree it would save me
(and others, of course!) a lot of time flipping through the man pages one by
one to make sure that they're all in th list.

  BTW, the list is in beta review now (only a couple of people looking at
the first draft), but I'll put it up on both the grasslist and grass5 lists
when it is complete (includes all modules) and the placement of modules
within categories has been reviewed.

  My reason for doing this is to design a menu system that will make
learning and using GRASS easier for my clients. The people using the systems
I'm developing are geologists and engineers and totally unfamiliar with GIS.
I need to give them both a turn-key system and one that they can use from
scratch with minimal training as they add new data and discover new analyses
they need/want.

  The new interface will be done either in ncurses or newt; I've not made
any decision. But, once that's done, I'll probably produce a gtk+ equivalent
for the mouse entrapped. :slight_smile:

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
                  Making environmentally-resposible mining happen.

2

Rich Shepard wrote:

> recently you (Eric) posted a list of descriptions generated from XML.
> Do you mind to send the script to me (I don't want to re-invent the wheel)
> or add it to CVS?

  Eric did indeed generate such a list and sent it to me. As I reorganized
it yesterday I noticed that it was not complete. For example, as I compiled
the section on remotely sensed data, there was nothing appropriate for
aerial photographs. I added i.ortho.photo but not the internally-called
modules.

The XML descriptions are generated by the G_parser() function if the
--interface-description flag is given. Interactive programs don't
generally use G_parser(), so they don't support this flag (they don't
support the "help" option either).

A list of programs which don't support this feature can be found in
messages between myself and Eric at the tail of the thread entitled
"Darwin Pre1 gtty stty errors".

I'm slowly working on eliminating some of the more gratuitous
exceptions; however, some programs can't readily be made to conform
(i.ortho.photo is probably the most extreme example).

  My reason for doing this is to design a menu system that will make
learning and using GRASS easier for my clients. The people using the systems
I'm developing are geologists and engineers and totally unfamiliar with GIS.
I need to give them both a turn-key system and one that they can use from
scratch with minimal training as they add new data and discover new analyses
they need/want.

In which case, you might want to look at some of what was said in the
aforementioned thread; it basically concerns the conflict between
individual programs implementing their own UI and trying to construct
a global "framework".

--
Glynn Clements <glynn.clements@virgin.net>

3

On Fri, Jun 15, 2001 at 04:48:00PM +0100, Glynn Clements wrote:

Rich Shepard wrote:

> > recently you (Eric) posted a list of descriptions generated from XML.
> > Do you mind to send the script to me (I don't want to re-invent the wheel)
> > or add it to CVS?
>
> Eric did indeed generate such a list and sent it to me. As I reorganized
> it yesterday I noticed that it was not complete. For example, as I compiled
> the section on remotely sensed data, there was nothing appropriate for
> aerial photographs. I added i.ortho.photo but not the internally-called
> modules.

Okay, I've worked up a module that queries all the commands in
grass5/etc/bin/cmd with the "--interface-description". It then
generates a directory of html files -- one for each command and an
index. In general it's probably not very useful (the command listings
have very little explanation; unlike the "man" pages). More "proof of
concept" than anything. Some commands are still problematic, so there's
a switch for reporting the failed commands.

Anyway, at the moment I'm calling it g.xml2html, but that seems like a
lousy name (not very descriptive). I'm not sure where to put it in the
cvs hierarchy. Also, it depends on libxml (I've only built it against
libxml2, but libxml1 will probably work). Since, it's proof of concept
and it has a dependency on a library that isn't searched for by the
configure script, I figure it shouldn't be built by default.

I was thinking it'd probably be better to explore xlst transforms, since
such things should make it easy to turn the xml into a variety of html
documents (such as forms -- though I don't really think GRASS is very
safe for internet use).

Example output: http://www.jps.net/egm2/g.xml2html/commands/index.html
Source code: http://www.jps.net/egm2/g.xml2html/g.xml2html.tar.gz

--
Eric G. Miller <egm2@jps.net>

4

Hi Eric

"Eric G. Miller" wrote:

I'm not sure where to put it in the cvs hierarchy.

Since this appears to be a program that does not link to any GRASS
libraries, it would be a candidate for the src/libes/tools directory.
However, it appears Markus has made a tools directory off the root CVS
directory. Perhaps we should merge these two "tools" directories but I'm
not sure which location is better.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

5

On Mon, Jun 18, 2001 at 11:59:47AM +0700, Justin Hickey wrote:

Hi Eric

"Eric G. Miller" wrote:
> I'm not sure where to put it in the cvs hierarchy.

Since this appears to be a program that does not link to any GRASS
libraries, it would be a candidate for the src/libes/tools directory.
However, it appears Markus has made a tools directory off the root CVS
directory. Perhaps we should merge these two "tools" directories but I'm
not sure which location is better.

Paradoxically enough, it does work as a standard GRASS module w/
G_parser interface (need libgis to query for the "GISBASE" path). So,
it could result in listing the interface to itself, along with the
others...

However, if an xml file for each command was dumped to a directory a
priori, then I could work up a non-GRASS specific program to do various
things. Perhaps that would be more useful?

I just realized about an hour ago that G_usage_xml() (in
libes/gis/parser.c) and the corresponding DTD (in src/gui) don't have
any representation for the "key_desc" Option member, nor for the
"gisprompt" Option member. Both should probably exist. So, eventually
a client using this info could validate inputs like coordinate pairs
(key_desc = "x,y") and or prompt for certain mapset "files" (like
tcltkgrass and nviz do...). I suppose both could be added as
optional attributes to the parameter element. Like:

<parameter name="map" type="string" required="yes" multiple="no"
gisprompt="old,cell,raster">

or

<parameter name="coord" type="float" required="yes" multiple="yes"
keydesc="x,y">

Anyway...

--
Eric G. Miller <egm2@jps.net>

From neteler Mon Jun 18 09:13:26 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
  id JAA13856; Mon, 18 Jun 2001 09:13:26 +0100
Date: Mon, 18 Jun 2001 09:13:07 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5 <grass5@geog.uni-hannover.de>
Subject: Re: [GRASS5] Re: Complete module list for GRASS-5?
Message-ID: <20010618091306.D27496@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5 <grass5@geog.uni-hannover.de>
References: <20010615105435.B24595@hgeo02.geog.uni-hannover.de> <Pine.LNX.4.33.0106150700370.12334-100000@salmo.appl-ecosys.com> <15146.11824.415569.962864@cerise.nosuchdomain.co.uk> <20010617170115.A16211@calico.local> <3B2D8AC3.5A0F5526@hpcc.nectec.or.th>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B2D8AC3.5A0F5526@hpcc.nectec.or.th>; from jhickey@hpcc.nectec.or.th on Mon, Jun 18, 2001 at 11:59:47AM +0700
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5&gt;,
  <mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/&gt;
Status: O
Content-Length: 650
Lines: 22

Hi,

On Mon, Jun 18, 2001 at 11:59:47AM +0700, Justin Hickey wrote:

Hi Eric

"Eric G. Miller" wrote:
> I'm not sure where to put it in the cvs hierarchy.

Since this appears to be a program that does not link to any GRASS
libraries, it would be a candidate for the src/libes/tools directory.
However, it appears Markus has made a tools directory off the root CVS
directory. Perhaps we should merge these two "tools" directories but I'm
not sure which location is better.

perhaps we keep both?

src/libes/tools/ -> GRASS source code related tools
/tools -> CVS maintenance tools

Other suggestions are welcome,

Markus