[GRASS-dev] [GRASS GIS] #153: ps.map: support for placement by % for decorations

GRASS GRASS developer
1

#153: ps.map: support for placement by % for decorations
-------------------------+--------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
     Type: enhancement | Status: new
Priority: minor | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Keywords: ps.map |
-------------------------+--------------------------------------------------
[ 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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/153&gt;
GRASS GIS <http://grass.osgeo.org>

2

#153: ps.map: support for placement by % for decorations
--------------------------+-------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: enhancement | Status: new
  Priority: minor | Milestone: 6.4.0
Component: ps.map | Version: svn-develbranch6
Resolution: | Keywords: ps.map
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------
Changes (by hamish):

  * platform: => Unspecified
  * component: default => ps.map
  * cpu: => Unspecified

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/153#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

3

#153: ps.map: support for placement by % for decorations
--------------------------+-------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: enhancement | Status: new
  Priority: minor | Milestone: 6.5.0
Component: ps.map | Version: svn-develbranch6
Resolution: | Keywords: ps.map
  Platform: All | Cpu: All
--------------------------+-------------------------------------------------
Changes (by hamish):

  * platform: Unspecified => All
  * cpu: Unspecified => All
  * milestone: 6.4.0 => 6.5.0

Comment:

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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/153#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

4

#153: ps.map: support for placement by % for decorations
-------------------------+--------------------------------------------------
Reporter: hamish | Owner: hamish
     Type: enhancement | Status: assigned
Priority: major | Milestone: 6.5.0
Component: Ps.map | Version: svn-develbranch6
Keywords: ps.map | Platform: All
      Cpu: All |
-------------------------+--------------------------------------------------
Changes (by hamish):

* cc: grass-dev@… (added)
  * owner: grass-dev@… => hamish
  * status: new => assigned
  * priority: minor => major

Comment:

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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/153#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

5

#153: ps.map: support for placement by % for decorations
-------------------------+--------------------------------------------------
Reporter: hamish | Owner: hamish
     Type: enhancement | Status: assigned
Priority: major | Milestone: 6.5.0
Component: Ps.map | Version: svn-develbranch6
Keywords: ps.map | Platform: All
      Cpu: All |
-------------------------+--------------------------------------------------

Comment(by 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/153#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

6

#153: ps.map: support for placement by % for decorations
-------------------------+--------------------------------------------------
Reporter: hamish | Owner: hamish
     Type: enhancement | Status: assigned
Priority: major | Milestone: 6.5.0
Component: Ps.map | Version: svn-develbranch6
Keywords: ps.map | Platform: All
      Cpu: All |
-------------------------+--------------------------------------------------
Changes (by martinl):

* cc: annakrat, martinl (added)

Comment:

Replying to [comment:3 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
[wiki:wxGUIDevelopment/GUIForPs.map].

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/153#comment:5&gt;
GRASS GIS <http://grass.osgeo.org>

7

#153: ps.map: support for placement by % for decorations
-------------------------+--------------------------------------------------
Reporter: hamish | Owner: hamish
     Type: enhancement | Status: assigned
Priority: major | Milestone: 6.5.0
Component: Ps.map | Version: svn-develbranch6
Keywords: ps.map | Platform: All
      Cpu: All |
-------------------------+--------------------------------------------------

Comment(by hamish):

Replying to [comment:4 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/153#comment:6&gt;
GRASS GIS <http://grass.osgeo.org>