ps.map: support for placement by % for decorations

[hamish]

[ ported here from RT bug # 3335 ​http://intevation.de/rt/webrt?serial_num=3335 North arrows are now available by a number of symbols + the point command, so someone with access could close that bug. ]

ps.map allows you to set decorations in one of three coordinate systems: by map coordinate, by inches from the top-left of the paper, or by percentage of map box from the bottom left corner.

map coord and percentage work from the same line, it senses if you added a "%" to the end of the number to decide which way to use. Values outside of 0-100% are allowed so you can place decorations outside the map box. (e.g. a caption)

The following decorations work with inches from the top-left of the page and require recalculation every time you change the map scale. colortable, scalebar, comments, mapinfo, vlegend

The problem is that the map box is not sized until after all the commands are read in. So while % of region calculations can be done during the parsing stage, the % of map box placement can not.

One possible solution is to add a boolean xy_is_percent int to each decoration's control struct, then wait to call scan_percent() at the drawing stage when the map box location is known.

I've run out of time to work on this, so I'll post the patch of how far I got in the hope that someone else might be able to finish it. (I got as far as discovering the map box wasn't set at parse time, and adding the boolean flag)

The end result would be that all decorations could use % is from lower-left of map box and a map composer GUI would be a little simpler to write.

I would not advocate removing the placement by inches support as it is very useful in creating set page templates, where the scale, legend, and caption all are drawn below the map box.

Hamish

[hamish]

partial patch to allow placement of decorations by % of map box

[hamish]

ie, PS.w.west, PS.w.east (in map units) are known during the read_decoration() phase, but PS.map_left, PS.map_right (in inches on the page) are not known until map_setup() has run at the start of the do_decoration() step.

the decorations which do accept percentage placement use map coords as their natural placement unit. The decorations which do not accept percentage placement use inches-on-the-page as their natural placement unit.

Hamish

[hamish]

Hi,

to help solve this issue for future a GUI front-end I plan on adding a -b flag which will take the existing ps.map input file, run it to dynamically place and size the map box, output the bounding box of the map box (in inches), and then exit without creating a map.

output will be in the form bbox=min_x,min_y,max_x,max_y relative to the top-left corner of the paper.

As long as the paper size is set, the GUI can then use this information (and possibly g.region) to switch between %, inches, cm, mm, PostScript points, and map units. The idea is that will be invisible to the user, all they do is drag the decoration to where they'd like to see it.

IMO it is not practical or a good idea to have the python code mirror the C code's placement logic itself (a lot of work/code to mimic, then a lot of discipline to keep in sync).

Hamish

[hamish]

-b flag to print map bounding box now added in trunk.

still some work needed to clean it up: so output=dummy isn't needed, and if it's given and the file exists already the old file doesn't get deleted. (it would have been overwritten anyway, so this isn't too much worse than the normal behavior)

Hamish

[martinl]

Replying to hamish:

to help solve this issue for future a GUI front-end I plan on adding a -b flag which will take the existing ps.map input file, run it to dynamically place and size the map box, output the bounding box of the map box (in inches), and then exit without creating a map.

cc to Anna Kratochvilova who started developing GUI front-end for ps.map within her bachelor final project. I think there could the first prototype of the GUI available for testing in the end of Feb wxGUIDevelopment/GUIForPs.map.

[hamish]

Replying to hamish:

-b flag to print map bounding box now added in trunk.

backported to 6.5svn by martinl; backported to 6.4svn by me.

still some work needed to clean it up: so output=dummy isn't needed, and if it's given and the file exists already the old file doesn't get deleted. (it would have been overwritten anyway, so this isn't too much worse than the normal behavior)

done in all branches with r43678,80,81.

If there are no objections I would close this ticket as 'wontfix', and leave the issue until the next generation of some future ps.plot module.

(rather than refactor/rewrite the mature ps.map code, thus resetting the QA clock to 0 and altering the long-standing design, I would rather fork major new development & free ideas into some new ps.* module, and leave the ps.map code in retirement mode for minor iterative improvements and bug fixes)

Hamish