[GRASS-dev] discussion: replacing ps.map

roger at spinn.net roger at spinn.net
Fri Mar 30 14:48:55 EDT 2007


Hamish writes: 

> v.label has a warning if you use roatate=:
> G_warning("Currently the rotation option only works correctly for left
> 	   justified text."); 
> 
> actually that should be "upper-left justified text", and given by
> d.labels not v.label (as you say, rotate works fine in ps.map).
> Warning moved in CVS. But even the upper-left d.labels placement 
> could use some slight adjustment (upwards).

The user may not have many choices about where the label text is justified, 
and GRASS offers no facility to change the justification. 

> what config options would you like to see? 
> 
>> Fixing the limitations with legends is a pretty big task -- especially
>> since there are so many different kinds of legends.
> 
> We fix/add things one feature at a time. Evenatually the collection
> matures.

That works as long as you have the structure to work within. 

As far as the desired features are concerned, that is a difficult question.  
The available legends are so unsuited to my use that I haven't used them in 
years.  I ran some tests with mapinfo and vlegends to see what I could get 
them to do.  There have been improvements, but I still had these problems: 

mapinfo is placed with a coordinate system in inches, originating at the 
bottom left of the map and increasing up and to the right.  Other ps.map 
commands that use lengths (rather than percents) use a coordinate system 
that starts at the top left and increases down and to the right.  The 
content of the mapinfo block isn't configurable and includes region 
information that I would probably never place on a map.  Also, the mapinfo 
product was never drawn with a bounding box, even when the bounding box 
color was specified. 

vlegends is placed with a coordinate system like that used for mapinfo, 
except that if the mapinfo block is present, the origin of the legend is at 
the bottom left of the information block rather than at the bottom left of 
the map.  Y coordinates less than 0 were ignored (this is documented 
behavior), which means that the legend will always be attached without a 
margin to the bottom edge of either the mapinfo block or the map itself. 

It would be nice to have a consistent means of locating features on a map, 
and it would be nice to be able to set locations below the map. 

The example map I used had data from 3 vector files - two with areas and one 
with points.  The legend produced by vlegend never contained more than 2 
entries.  It appeared to pick up the first area vector and skip all 
subsequent area vectors.  I also plotted 4 separate polygons from one of the 
files with a different color for each polygon.  That was done with 4 varea 
entries in the ps.map configuration file, each specifying a different cat 
number and a different color.  The legend still contained only one entry -- 
the entry for first varea in the configuration file. 

The legend contained an entry for the point data, but no entry for the 
boundary lines. 

All of the vector features were grouped together into one legend.  It would 
be nice to separate them.  In fact, it would generally be a good thing to be 
able to select what vector features appeared in the legend. 

When the legend was split into more than one column I got a different box 
around each column.  That should be configurable.  I would normally prefer 
that the legend fall entirely within one box.  The spacing between columns 
was large and also not configurable; it should be configurable. 

The user should be able to specify the width and/or style of the border line 
drawn around the legend.  It would also be good to specify the margin 
between the legend content and the bounding line. 

The user should be able to add a title for the legend. 

The list could go on and on.  I didn't really run that many experiments.  If 
you add enough configurable features to make the legends useful, then people 
will start using them; more problems will come up and more options will be 
needed. 


Roger




More information about the grass-dev mailing list