[GRASS-dev] Shell scripts

Michael Barton michael.barton at asu.edu
Thu Nov 26 01:37:03 EST 2009

On Nov 25, 2009, at 10:27 PM, grass-dev-request at lists.osgeo.org wrote:

> Date: Thu, 26 Nov 2009 01:25:48 +0000
> From: Glynn Clements <glynn at gclements.plus.com>
> Subject: Re: [GRASS-dev] Shell scripts
> To: Markus Neteler <neteler at osgeo.org>
> Cc: grass-dev at lists.osgeo.org
> Message-ID: <19213.55580.942903.873211 at cerise.gclements.plus.com>
> Content-Type: text/plain; charset=us-ascii
> Markus Neteler wrote:
>>> The remaining question is whether d.path.sh and the p.* scripts  
>>> should
>>> be converted to Python or removed. I don't think that d.path.sh  
>>> works
>>> with the GUI. The p.* scripts appear to be an attempt to implement
>>> d.mon-like behaviour for the GUI, but I don't know whether this is
>>> functional.
>> The p.* scripts are semi-functional and should be rewritten to  
>> Python.
>> Not having d.mon/d.rast/d.vect/d.zoom commands is for me, Helena,  
>> others
>> the obstacle to not use GRASS 7 as primary version.
>> Since the needed (wx)GUI pieces are there, I still hope that  
>> someone skilled
>> is rewriting it in Python. For us it is essential to continue with  
>> command line
>> in GRASS 7.
> d.rast and d.vect haven't gone anywhere.
> If you want to be able to control the GUI from the command line, that
> should be dealt with as an infrastructure issue, not by creating
> wrappers around individual commands.
> I can deal with the display/driver libraries, and with generic Python
> IPC, but some of it will need the involvement of someone who
> understands the GUI.

Winter break is near and I'll be laid up for a week. So I might be  
able to help.

Controlling the GUI from the command line is a contradiction in  
interface terms. Perhaps you really mean displaying a map from the  
command line?

If you don't want to use a mouse, there isn't much point in trying to  
work with the wxGUI map display canvas as it is--with all of its  
buttons and menus and a lot of other functionality built in. It's not  
impossible to break into it, but it is not easy either--which is why  
the p.* scripts remain non- or only semi-functional. Also, I suspect  
that command-line only display will be important primarily for users  
of Linux. So it seems like a better solution is to have a reasonably  
easy command line way to composite maps and display them (perhaps in  
pnm or png format) in a Linux-based viewer.

Glynn has mentioned the possibility of this and most of the tools  
already exist. Probably a python script could be created to 1) allow a  
user to specify a list of vector and raster maps to overlay, 2) set  
the output file grass variable and recursively cycle through d.vect  
and d.rast, 3) run the pnm files through g.pnmcomp to composite them,  
and 4) display the composited map in a Linux viewer utility of some  
sort. d.out.file might be useful as a model to get this started. If  
someone wants to attempt this, I'm happy to offer advice on the Python  

Another option could be a simplified interface to ps.map, enter maps  
only or maps and a couple of overlay options like a scale and north  
arrow, and use ps.map to do the compositing. Then display the result  
in a ps viewer. These could also be combined in a Python script. There  
used to be a TclTk script for most of this. This might produce higher  
quality visualization and has the added benefit of simultaneously  
producing high quality print files.


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

More information about the grass-dev mailing list