[GRASS-dev] discussion: replacing ps.map

roger at spinn.net roger at spinn.net
Tue Mar 27 17:36:57 EDT 2007


Jachym, 

GRASS has never provided the capability to easily produce a high-quality end 
product.  That is a long standing complaint.  In the 9 years or so since I 
started using GRASS there has been improvement but the problem has never 
been given the attention that it needs. 

ps.map is the one tool that GRASS offers that can produce what I think of as 
a good product.  ps.map is difficult to use, but ps.map is the piece of the 
process that actually works.  For the most part you need to look elsewhere 
for the cause of the problems you listed. 

> just few examples:  better label placement, easy icons creation,
> better support for legends, simple style definition

ps.map does a better job of placing labels than does d.paint.labels, which 
is basically broken -- at least in 6.2. ps.map makes good use of the paint 
labels facility.  The shortcoming not that ps.map doesn't work but that 
there is no GUI for that allows you to place the labels graphically.  GUI is 
late to come to GRASS and it hasn't made it yet to the task of map 
production.  More on that later. 

ps.map uses the same icons that are used by the GRASS vector routines.  This 
is not a problem in ps.map, but a limitation that effects all GRASS 
displays.  I hope that future GRASS distributions will have more 
comprehensive symbols sets.  A symbol-editing facility would be nice, but I 
would rather just have a good standard symbol set. 

I agree that ps.map support for legends is not very good.  On the other 
hand, you can build a legend with other graphics software, save it as an eps 
file and ps.map will let you place it where you want it.  I once had a 
simple bash script (I say "once" because I just went looking for it and 
couldn't find it) that created continuous color scale legends for raster 
maps completely through a point-and-click process using just GRASS and unix 
command-line facilities.  It took me about 20 minutes to write that script.  
I'm sure someone with more skill than I have could give GRASS much better 
legend-building capabilities. 

"Simple" is a subjective term.  ps.map doesn't offer a style sheet facility 
but it does allow you to create and save template configurations and code 
blocks (e.g, for title blocks ) that can be incorporated in new products.  I 
think that's fairly simple.   I've used that ability to produce map sets 
with nearly 30 individual maps, all in the same basic style, and to do so 
over and over at an impressive rate. 

> GRASS great analytical tool. Map creation is pain even if we would
> script any gui around it (which would be pain too).

I expect that anything you want to do will be a pain if it is to be done in 
a robust and internally consistent manner, but I'm not sure that it is as 
much of a pain as you think it is.  I have a custom GUI that I've been 
developing for probably 6 years now, and it includes the ability to convert 
GRASS vector labels to paint labels configuration files, set labeling styles 
for entire label sets and to select and edit individual labels.  It also has 
a configuration editing and product review capability for ps.map.  It is 
unfortunately not consistent with the existing GRASS GUI or up to the 
programming standards that the GRASS developers want in submitted code. 

Programming the label editing GUI probably took me a couple days work.  I 
expect that it would take little more than that to develop a GUI for placing 
and editing labels in the existing GRASS GUI.  One thing that probably has 
to be done first (if it hasn't been done yet), is to fix d.paint.labels.  
Either that, or the vector labeling capabilities need to be changed in 
revolutionary ways. 

I think we agree completely that GRASS needs a better ability to produce 
high quality final product.  I just think we are close to a good native 
solution and shouldn't be starting over with third-party software. 

As an aside, if you need pdf output, just run postscript through ps2pdf.  
ps2pdf is part of the Ghostscript package. 


Roger




More information about the grass-dev mailing list