#1453: ps.map: various enhancements
-------------------------+--------------------------------------------------
Reporter: mmetz | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Ps.map | Version: svn-trunk
Keywords: | Platform: All
Cpu: All |
-------------------------+--------------------------------------------------
Some suggested enhancements for ps.map:
* line width of colortables: make it a function of font size instead of
width of the colortable, otherwise the border can become really thick;
patches in ps_clrtbl.patch and psfclrtbl.patch
* allow comments in scripts, patch in key_data.patch
* do not draw vector points on top of grids, no reason why vector points
should behave different to lines and areas; patch in ps_map.patch
* add key width to points; patches in r_plt.patch and do_plt.patch
* add keys font and fontsize to scalebar; patches in get_scalebar.patch
and do_scalebar.patch
* vector area legend: use square boxes, the current shape looks weird;
patch in ps_vlegend.patch
I'll post some per-patch comments soon. explanatory screenshots are always
nice.
but quickly--
re. comments in the script, fyi they are already allowed but the # must be
the first char of the line IIRC (less than ideal). your patch as given for
# as first non-whitespace char of the line requires a space after it to
work? that is less than ideal too.
note I've been meaning to do a bit of a rewrite of the vector legend
stuff. I prefer the rectangles (esp. when mixed with lines and points in
the legend) but am happy to make the shape adjustable somehow. Jorge has
some ideas worth looking at as well.
vpoints should be under the grid lines, but points (ie annotations) should
be above.
if present in the instruction, the "masked y|n" control can help control
the order
things get rendered in.
#1453: ps.map: various enhancements
-------------------------+--------------------------------------------------
Reporter: mmetz | Owner: hamish
Type: enhancement | Status: assigned
Priority: normal | Milestone: 7.0.0
Component: Ps.map | Version: svn-trunk
Keywords: | Platform: All
Cpu: All |
-------------------------+--------------------------------------------------
Comment(by mmetz):
Replying to [comment:1 hamish]:
>
> re. comments in the script, fyi they are already allowed but the # must
be the first char of the line IIRC (less than ideal). your patch as given
for # as first non-whitespace char of the line requires a space after it
to work? that is less than ideal too.
No following whitespace required. If the first non-whitespace and non-tab
character is #, the line is skipped. Whatever comes after # is ignored.
>
> note I've been meaning to do a bit of a rewrite of the vector legend
stuff. I prefer the rectangles (esp. when mixed with lines and points in
the legend) but am happy to make the shape adjustable somehow. Jorge has
some ideas worth looking at as well.
The shape is a matter of taste I guess.
>
> vpoints should be under the grid lines, but points (ie annotations)
should be above.
That is what the patch does (it's about vpoints, not points).
> if present in the instruction, the "masked y|n" control can help control
the order
> things get rendered in.
The "masked" control is recognized for vpoints, now exactly the same like
for vector lines and areas.
#1453: ps.map: various enhancements
-------------------------+--------------------------------------------------
Reporter: mmetz | Owner: hamish
Type: enhancement | Status: assigned
Priority: normal | Milestone: 7.0.0
Component: Ps.map | Version: svn-trunk
Keywords: | Platform: All
Cpu: All |
-------------------------+--------------------------------------------------
Comment(by mmetz):
Replying to [comment:2 hamish]:
> > your patch as given for # as first non-whitespace char of the line
requires
> > a space after it to work?
>
> maybe just look at *key[0] ?
key is a char *, not a char **, therefore I am pretty sure that *key[0] is
nonsense. *key = key[0] and this is a char, not a char *.
#1453: ps.map: various enhancements
-------------------------+--------------------------------------------------
Reporter: mmetz | Owner: hamish
Type: enhancement | Status: assigned
Priority: normal | Milestone: 7.0.0
Component: Ps.map | Version: svn-trunk
Keywords: | Platform: All
Cpu: All |
-------------------------+--------------------------------------------------
Comment(by hamish):
* #comments patch applied in trunk and devbr6
* 'point' width patch applied with modification in trunk
further discussion:
- I remember now why I split off the vpoints and put them over the grid
lines by default, for complicated symbols like extra/alpha_flag it didn't
look good to have them underneath when used to represent sampling
stations. currently you can control it with the 'masked y|n' command; I'm
open to changing the default 'y|n' there to go under the grid lines if
there is popular support for having it that way, but before abusing the
masked control I think we should better get the masked support working. I
don't fully understand what it's doing, but AFAICT by looking at
do_masking.c and r_plt.c, the help page is misleading/wrong, it doesn't
have much to do with raster MASK maps after all. AFAICT the maskcolor
instruction currently does nothing.
- FP color table border width: both new and old way is a bit weird. I'll
check in a compromise which gets rid of the overly wide wierdness, as a
base for further discussion. screenshots will be helpful here.
#1453: ps.map: various enhancements
-------------------------+--------------------------------------------------
Reporter: mmetz | Owner: hamish
Type: enhancement | Status: assigned
Priority: normal | Milestone: 7.0.0
Component: Ps.map | Version: svn-trunk
Keywords: | Platform: All
Cpu: All |
-------------------------+--------------------------------------------------
Comment(by cmbarton):
Is there any way to have the order in which the command sections are read
affect the order in which they are rendered? That is, can it be set so
that if the vpoints section comes after the grid section, vpoints are on
top, but if grid comes after vpoints the grid is on top?
Also, can the grid color be given an alpha value so that it could be semi-
transparent when it overlays things?
#1453: ps.map: various enhancements
-------------------------+--------------------------------------------------
Reporter: mmetz | Owner: hamish
Type: enhancement | Status: assigned
Priority: normal | Milestone: 7.0.0
Component: Ps.map | Version: svn-trunk
Keywords: | Platform: All
Cpu: All |
-------------------------+--------------------------------------------------
Comment(by hamish):
Replying to [comment:6 cmbarton]:
> Is there any way to have the order in which the command sections are
read affect
> the order in which they are rendered? That is, can it be set so that if
the
> vpoints section comes after the grid section, vpoints are on top, but if
grid
> comes after vpoints the grid is on top?
not really. sort-by-order already works for a collection of vector maps,
and for a collection of line/rectangle/point instructions. but not for the
main the stack order (raster map on the bottom, grid in the middle,
annotations on top) which is set here:
source:grass/trunk/ps/ps.map/ps_map.c
if we've done everything right, hopefully it will just do the right thing
and people will simply not have any need or desire to subvert the default
ordering. or at least then we then see where the real demand is, not just
demand to work around what is actually a deficiency. (so identify and fix
the deficiency instead of taking the cop-out route and creating a 747
cockpit full of controls to allow the user work around all our bad default
choices)
> Also, can the grid color be given an alpha value so that it could be
> semi-transparent when it overlays things?
PostScript doesn't support that, only newer PDF (ver 1.4+ ?) and then
that's only for area vector fill color. Suggested approach is to set the
grid width to 0.25-0.5 or so. (test with your printer, if you make it too
thin it might not show up at all)
#1453: ps.map: various enhancements
-------------------------+--------------------------------------------------
Reporter: mmetz | Owner: hamish
Type: enhancement | Status: assigned
Priority: normal | Milestone: 7.0.0
Component: Ps.map | Version: svn-trunk
Keywords: | Platform: All
Cpu: All |
-------------------------+--------------------------------------------------
Comment(by cmbarton):
So here is a suggestion. Can something like d.shadedmap be added as an
alternative to d.raster as a base map? This would add considerable
versatility to raster display.
