[GRASS5] Ps.map wish/question

[Michael Barton]

On 5/16/05 6:34 PM, "Hamish" <hamish_nospam at yahoo.com> wrote:

>> Maybe I missed it in my cursory look at the ps.map docs, but it seems
>> like some d.* command options are a subset of the ps.map commands. I
>> assume that people using ps.map would continue to use the richer
>> ps.map commands (i.e., not replace ps.map commands, but have ps.map
>> also recognize some d.* commands).
> 
> d.* is better for web & presentation graphics.
> ps.map is better for hardcopy (ie paper) output for reports etc.
> GMT is more powerful than ps.map, but less integrated with GRASS.
> 
> 
>> I was thinking that if ps.map also would read relevant d.* commands it
>> would be more easily scriptable.
> 
> Have a peek at the code for the file->print option in the d.m menu.

This is what made me start to thinking about this.

> 
> See also  http://intevation.de/rt/webrt?serial_num=1717

This was what I had in mind.

> 
> 
> the ultimate way would be to have a command line flag --psmap or
> something to have the display modules output their commands in ps.map
> form. These could be cat-ed together for a prototype ps.map command
> script. 

It could go this way too.

I was thinking that perhaps ps.map could just recognize "d.rast [options]"
the way it does "rast [options]". Maybe this is too complicated.

> Perhaps that is a lot more trouble than it is worth, and a
> shell/perl/python script to translate a couple of the more common d.*
> commands from d.save into a ps.map command file is all that is needed.

This would be doable of course, but seems like it would require a lot of if
or case statements.

Michael

> 
> 
> 
> Hamish

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ  85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>