ps.map: various enhancements

[mmetz]

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

[hamish]

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

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

[mmetz]

Replying to 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.

[mmetz]

Replying to 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 *.

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

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

thanks, Hamish

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

Michael

[hamish]

Replying to 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

[cmbarton]

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

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

Michael

[martinl]

Milestone renamed

[neteler]

Ticket retargeted after milestone closed

[martinl]

What is the state of this ticket?

[martinl]

All enhancement tickets should be assigned to 7.6 milestone.

[cmbarton]

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

[martinl]

Ticket retargeted after milestone closed

[martinl]

Ticket retargeted after milestone closed