See also ​page at GRASS User Wiki.

• ?! What happened to the wiki page content describing Jachym's existing ps.map GUI-frontend python prototype? check old versions of ​the main wxGUI wiki page.

Prototype should be able to generate configuration file for ps.map based on ​example.

Please contact Hamish before getting started with the GUI front-end or before significant changes to ps.map back-end (as primary maintainer of that code).

Similar tools: ​QGIS Print composer, ArcGIS Layout mode, ​gvSig (see also ​workshop)

Prototype 1

• Configuration dialog (paper format, map scale)
• Implement the raster, colortable, vlines, vpoints, vareas(?), text, mapinfo instructions
• Interactive placement of the features
• Draft mode (lower raster region resolution)
• Generate ps.map configuration text file
• Create output using ps.map

Prototype 2

• Draft/Preview mode
• Implement other instructions
• EPS output option
• If the ps2pdf program is installed offer a PDF output option
• If pstoimg program is installed offer a PNG output option (latex2html linux package; uses ghostscript. Imagemagick's convert does not do as nice a job AFAICT. Alt to try: Inkscape can do non-interactive conversions from the commandline.)

Prototype 3

• Read configuration files
• As a parallel task, nice features from ps.output should be ported to ps.map. (contact HB)

ps.map bugs and inconsistencies

• color should support RGB for all instructions (e.g. #192)
• common usage of ref points and units (absolute, relative)
  • The trouble is, percentage is given relative to the map box (which is sized and placed dynamically at run-time), while absolute is given relative to the page size. Although it may seem like it to the end user, the existing usage is not due to the programmer's whim, it is out of necessity. Note that to place relative decorations out-of-box, it is valid to go beyond 0-100% (e.g. -25%, 115%).
  • The GUI has to do these calculations and feed ps.map what it wants in the form it wants. IMO it is not practical to have the python code mirror the C code's placement logic (a lot of work to mimic, then a lot of discipline to keep in sync). This may take a two-pass solution, e.g. a new ps.map flag which would output map box corners in inches and then exit. The GUI could then do the needed conversions between %, PostScript points(?), inches, cm, mm, or map coords. See wish #153.

Open Tickets

#153

ps.map: support for placement by % for decorations

#192

ps.map: geogrid RGB color and ellipsoid

#250

ps.map: connected lines for region instruction box

#342

ps.map: vpoints support for rgbcolumn as primary/secondary color

#487

ps.map: legend

#874

ps.map: submeter grid sizes

#876

ps.map rfe: new instruction to flood fill background color

#900

Transparent background on geogrid labels in psmap

#901

ps.map - comment command applies last location/font to all previous comments

#1225

Include support for kilometres / metres (re) as unit options, alongside of kilometers/meters (er)

#1333

ps.map mapinfo aligns horizontally to map

#1350

Ps.map mapinfo - show scale only

#1356

Ps.map vlines cwidth subcommand - can't choose other column than cat

#1453

ps.map: various enhancements

#1688

ps.map: adding negative scale and offset to vpoints plotting -- patch provided

#1906

Raster "title" longer than 100 characters segfaults ps.map -- Request to extend the field's capacity.

#1907

ps.map does not respect the drawing order of objects

#1939

Add line style option to vareas ps.map

#2948

ps.map output to stdout

#3650

Cartographic composer: scale and rotation options do not work for north arrow

#3907

ps.map: vlegend throws error