ps.map: various enhancements

[landam]

Reported by mmetz on 21 Sep 2011 16:21 UTC 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

All patches are against trunk

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/1453

[landam]

Attachment from mmetz on 21 Sep 2011 16:22 UTC

https://trac.osgeo.org/grass/attachment/ticket/1453/r_plt.patch

[landam]

Attachment from mmetz on 21 Sep 2011 16:22 UTC

https://trac.osgeo.org/grass/attachment/ticket/1453/do_plt.patch

[landam]

Attachment from mmetz on 21 Sep 2011 16:22 UTC

https://trac.osgeo.org/grass/attachment/ticket/1453/get_scalebar.patch

[landam]

Attachment from mmetz on 21 Sep 2011 16:22 UTC

https://trac.osgeo.org/grass/attachment/ticket/1453/do_scalebar.patch

[landam]

Attachment from mmetz on 21 Sep 2011 16:23 UTC

https://trac.osgeo.org/grass/attachment/ticket/1453/key_data.patch

[landam]

Attachment from mmetz on 21 Sep 2011 16:23 UTC

https://trac.osgeo.org/grass/attachment/ticket/1453/ps_clrtbl.patch

[landam]

Attachment from mmetz on 21 Sep 2011 16:23 UTC

https://trac.osgeo.org/grass/attachment/ticket/1453/ps_fclrtbl.patch

[landam]

Attachment from mmetz on 21 Sep 2011 16:23 UTC

https://trac.osgeo.org/grass/attachment/ticket/1453/ps_map.patch

[landam]

Attachment from mmetz on 21 Sep 2011 16:23 UTC

https://trac.osgeo.org/grass/attachment/ticket/1453/ps_vlegend.patch

[landam]

Comment by hamish on 22 Sep 2011 02:49 UTC 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.

thanks, Hamish

[landam]

Comment by hamish on 22 Sep 2011 02:55 UTC

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] ?

[landam]

Comment by mmetz on 22 Sep 2011 09:27 UTC 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.

[landam]

Comment by mmetz on 22 Sep 2011 09:31 UTC 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 .

[landam]

Comment by hamish on 26 Sep 2011 12:53 UTC

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

scalebar, vlegend: I haven't looked at these yet.

thanks, Hamish

[landam]

Comment by cmbarton on 26 Sep 2011 15:22 UTC 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?

Michael

[landam]

Comment by hamish on 26 Sep 2011 23:42 UTC 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)

Hamish

[landam]

Comment by cmbarton on 27 Sep 2011 16:02 UTC Understood.

It is certainly nice to be able to access ps.map more easily now (and of course come up with suggestions for more work). ;-)

Michael

[landam]

Comment by cmbarton on 30 Oct 2011 15:42 UTC 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.

Michael

[landam]

Modified by @landam on 12 May 2016 06:42 UTC

[landam]

Modified by @landam on 25 Aug 2016 15:51 UTC

[landam]

Comment by @landam on 27 Aug 2016 13:42 UTC Milestone renamed

[landam]

Comment by neteler on 26 Jan 2018 11:40 UTC Ticket retargeted after milestone closed

[landam]

Modified by neteler on 12 Jun 2018 20:48 UTC

[landam]

Comment by @landam on 25 Sep 2018 12:24 UTC What is the state of this ticket?

[landam]

Comment by @landam on 25 Sep 2018 16:51 UTC All enhancement tickets should be assigned to 7.6 milestone.

[landam]

Comment by cmbarton on 25 Sep 2018 22:06 UTC Not clear if any of the suggested enhancements were ever made. Is the cartographic composer just an interactive interface to ps.map or is it a different beast (with the option of saving a ps.map file)?

[landam]

Comment by @landam on 25 Jan 2019 21:07 UTC Ticket retargeted after milestone closed