I haven’t used ps.map. It seems like a very useful module, but one that is fairly complex to use. While looking though the docs, however, it became apparent that it performs the same kind of display functions (to paper/postscript file) as many of the d.* modules do (to the display monitor)–and does a number of other special functions like setting paper size and margins of course. However, it uses a slightly different syntax to perform equivalent functions. E.g., rast [mapname] for ps.map vs. d.rast [mapname] for screen display.
This led me wonder if it would be difficult to have ps.map accept as an alternative syntax, the d.* commands for which it has equivalent functions. D.vect (vareas, vlines, vpoints), d.rast (rast), d.barscale (scalebar), d.grid (grid or geogrid) seem easily apparent. There might be reasonably straightforward translation for additional d.* commands like d.frame and d.graph also.
If this could be done, then either a set of normal GRASS commands—or even nicer, the file produced by d.save—could be piped to ps.map to make nice postscript output.
How feasible would this be?
Michael
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
I haven¹t used ps.map. It seems like a very useful module, but one that is
fairly complex to use. While looking though the docs, however, it became
apparent that it performs the same kind of display functions (to
paper/postscript file) as many of the d.* modules do (to the display
monitor)--and does a number of other special functions like setting paper
size and margins of course. However, it uses a slightly different syntax to
perform equivalent functions. E.g., rast [mapname] for ps.map vs. d.rast
[mapname] for screen display.
This led me wonder if it would be difficult to have ps.map accept as an
alternative syntax, the d.* commands for which it has equivalent functions.
D.vect (vareas, vlines, vpoints), d.rast (rast), d.barscale (scalebar),
d.grid (grid or geogrid) seem easily apparent. There might be reasonably
straightforward translation for additional d.* commands like d.frame and
d.graph also.
If this could be done, then either a set of normal GRASS commands‹or even
nicer, the file produced by d.save‹could be piped to ps.map to make nice
postscript output.
How feasible would this be?
It would be simple enough to define aliases for existing ps.map
commands. However, users would probably be confused by the significant
differences between the ps.map commands and their d.* counterparts.
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).
I was thinking that if ps.map also would read relevant d.* commands it would
be more easily scriptable.
Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
From: Glynn Clements <glynn@gclements.plus.com>
Date: Sun, 15 May 2005 12:18:08 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5 developers list <grass5@grass.itc.it>
Subject: Re: [GRASS5] Ps.map wish/question
Michael Barton wrote:
I haven?t used ps.map. It seems like a very useful module, but one that is
fairly complex to use. While looking though the docs, however, it became
apparent that it performs the same kind of display functions (to
paper/postscript file) as many of the d.* modules do (to the display
monitor)--and does a number of other special functions like setting paper
size and margins of course. However, it uses a slightly different syntax to
perform equivalent functions. E.g., rast [mapname] for ps.map vs. d.rast
[mapname] for screen display.
This led me wonder if it would be difficult to have ps.map accept as an
alternative syntax, the d.* commands for which it has equivalent functions.
D.vect (vareas, vlines, vpoints), d.rast (rast), d.barscale (scalebar),
d.grid (grid or geogrid) seem easily apparent. There might be reasonably
straightforward translation for additional d.* commands like d.frame and
d.graph also.
If this could be done, then either a set of normal GRASS commands?or even
nicer, the file produced by d.save?could be piped to ps.map to make nice
postscript output.
How feasible would this be?
It would be simple enough to define aliases for existing ps.map
commands. However, users would probably be confused by the significant
differences between the ps.map commands and their d.* counterparts.
I use ps.map regularly. As it is now ps.map scripts fairly easily.
The PNG driver can be used to get hard copy output that exercises all of the
limited capabilities of the d.* commands. There really isn't much point to
using ps.map just to do what the d.* commands can do.
Roger Miller
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).
I was thinking that if ps.map also would read relevant d.* commands it would
be more easily scriptable.
Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
From: Glynn Clements <glynn@gclements.plus.com>
Date: Sun, 15 May 2005 12:18:08 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: grass5 developers list <grass5@grass.itc.it>
Subject: Re: [GRASS5] Ps.map wish/question
Michael Barton wrote:
I haven?t used ps.map. It seems like a very useful module, but one that is
fairly complex to use. While looking though the docs, however, it became
apparent that it performs the same kind of display functions (to
paper/postscript file) as many of the d.* modules do (to the display
monitor)--and does a number of other special functions like setting paper
size and margins of course. However, it uses a slightly different syntax to
perform equivalent functions. E.g., rast [mapname] for ps.map vs. d.rast
[mapname] for screen display.
This led me wonder if it would be difficult to have ps.map accept as an
alternative syntax, the d.* commands for which it has equivalent functions.
D.vect (vareas, vlines, vpoints), d.rast (rast), d.barscale (scalebar),
d.grid (grid or geogrid) seem easily apparent. There might be reasonably
straightforward translation for additional d.* commands like d.frame and
d.graph also.
If this could be done, then either a set of normal GRASS commands?or even
nicer, the file produced by d.save?could be piped to ps.map to make nice
postscript output.
How feasible would this be?
It would be simple enough to define aliases for existing ps.map
commands. However, users would probably be confused by the significant
differences between the ps.map commands and their d.* counterparts.
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.
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. 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.
On 5/16/05 6:34 PM, "Hamish" <hamish_nospam@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.
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
> 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,
I think that a script is the least intrusive method. Script would run
d.save, parse what it could, and spit out a base ps.map command file.
but seems like it would require a lot of if or case statements.
well whatever language it is in will need that. I suggested perl/python
as they're probably better at dealing with text strings than shell
scripts are.
I use ps.map regularly. As it is now ps.map scripts fairly easily.
The PNG driver can be used to get hard copy output that exercises all of the
limited capabilities of the d.* commands. There really isn't much point to
using ps.map just to do what the d.* commands can do.
ps.map will produce much better results for vectors.
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. 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.
Only a few d.* commands have ps.map equivalents. For most of those,
ps.map only has an approximate equivalent. Also, you can't combine
ps.map commands in the same way that you can combine d.* commands.
The most obvious example is that there is no ps.map equivalent of:
d.rast map1
d.rast -o map2
as ps.map only allows a single raster, and doesn't have an equivalent
of the -o switch (and that could only be implemented for level 3
PostScript; earlier versions don't support masked images).
More generally, the d.* commands draw directly to the monitor, whereas
ps.map commands tend to be stored up, and the rendering only starts
once all of the commands have been read. The order in which commands
are "executed" (i.e. rendered) doesn't necessarily correspond to their
order in the input file.