[GRASS-dev] discussion: replacing ps.map

[Hamish]

> > Roger wrote:
> > > ps.map does a better job of placing labels than does
> > > d.paint.labels, which is basically broken -- at least in 6.2.
> > Hamish:
> > please explain? bug #? what is broken with d.labels? (note rename)
> > If it is broken I will try and fix it. AFAIK it has been working
> > well since GRASS 6.1.0.
Roger:
> Rotated labels appear in incorrect locations.  The rotation is
> correct. The same labels plotted with ps.map appear in the correct
> locations.

Ok.

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).


> I think the symbols we have are fine.  What we have now is a vast
> improvement over previous versions.  We just need to provide more of
> them, either in the standard distribution or in downloadable packages.
> In my field (I'm a hydrogeologist) there are probably more than a 100
> fairly standardized point symbols in common use.  I recently printed
> out pages of data on the USGS map symbology with the hopes that I
> would have the time to build at least part of that set.  That much
> time is hard to come by.

Start with the 5 you use most, then add more as needed....

In the past I have looked at creating a symbol set for weather maps,
some links added to the wiki page:
  http://grass.gdf-hannover.de/wiki/IconSymbols#Future_contribions

We must be careful not to package with the GRASS source code symbols
which are derived from other symbols which are under traditional
copyright. Stick to designs which are in the public domain.


R:
> > > I agree that ps.map support for legends is not very good.
> > H:
> > do you mean raster categorical legends, raster floating point
> > legends, or vector legends? what do you miss?
> R:
> Any of the above and more.  My specific and recurring problem is with
> symbol keys.  The two built-in facilities for legends (the colortable
> and vlegend) are not configurable enough to be generally useful.

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.


Jachym:
> What about line symbols? You can influence the line style "only" by
> plotting dashed line. You can not add borders, various decorations
> (for electrick lines, pipe lines, etc.), labels are ploted one over
> another (ee, or this was the case some time ago).

work-around:
v.buffer;  for railroad you might do something like v.parallel +
{v.segment/v.split/v.lrs.label points or lines}.

> where you can use eps files for area filling, this does not appear in
> the legend (?)

yes it does. (at least since $GISBASE/etc/paint/patterns/ was added)
(only simple .eps supported??)

try making the spearfish "Example ps.map script" here:
  http://grass.gdf-hannover.de/wiki/AreaFillPatterns
  http://grass.gdf-hannover.de/wiki/Psmap_fill_patterns


Jachym:
> more raster maps in one map, so you would need to patch them, before
> you want to use them. Equivalent usage of d.his and d.rgb would be
> useful too.

ps.map has a "rgb" instruction already.
r.his could make rgb layers for rgb instruct?


> I would put than need for documentation/script, which would create
> such legend very high on the priority list. Without legend, there is
> no map. And you can not easy create map, if there is no easy way, how
> to create legend.
> 
> On the other hand, if this issues would be solved, I do not see any
> reason for using external tool.

we must decide if effort to fix ps.map > effort to start from scratch.
(I think the fixes are not so impossible)



Hamish