[GRASS5] [bug #3350] (grass) ps.map: vpoints draws before grid

[Maciek Sieczka]

From: "Hamish" <hamish_nospam at yahoo.com>

>> >> Wouldn't it be usefull for any element to be rendered by the order
>> >> of appearance in the file containing mapping instructions?
>> >> So the vpoints (or any other element) could be drawn over or under
>> >> the grid (or any other piece of map), as the user wishes.
>> >
>> > Is this with respect to a specific preference or just a general
>> > idea?
>>
>> My preference and my (?) idea and usefull for others I think. But I
>> don't mean to insist.
>
> Clearer:
>
> Can you give a specific example of something that is not layered to your
> liking?

Clear enough. And the answer is: no, a general idea.

> Lines over or under the grid lines comes to mind -- GPS track might be
> over the grid line but roads should be under.
> shrug.

Good example - any order the user likes.

>> WISH: anyway total freedom in arranging the order and rendering by the
>> order in instructions file would make things clear and simple.
>
> Current code aspires to produce reasonable output by default. With a
> program as hard to get started with as ps.map, this is a very good thing,
> even if it hurts overall "power". + I see no reason to build a second GMT.

Applying my wish wouldn't make that much change for sure. No harm for the
easyness of use. The opposite I think. Reasons:
1. The user wouldn't have to wonder which layer goes fisrt - the sequence of
instructions would explain it all. So less need to jump to manual and back,
less trial and error.
2. The user is free to decide which layer goes where. No need to wondering
what trick to use if his preference is non-standard.
3. The user is always right. (joke) (to some extent)

> Everyone is free to swap around the do_*() calls in ps_map.c & recompile
> to get the order they like. Very little to no programming skills
> required.
> :)

Well, that is some consolation but I wouldn't dare to start messing with the
code when I have to produce and print a non-standard map for my boss who is
not going to wait longer than five minutes.

>> BTW talking of ps.map - are you planning to unify the method for
>> describing  the position of different map elements? Settling for units
>> of the hardcopy (cm in my preference :)) for all instructions would
>> be an important improvement IMO, instead of geographical and percents
>> mixed with inches.
>>
>> I think a big improvement would also be choosing only one method for
>> the  fontsize in all instructions, dropping "width" sub-instruction in
>> "text" section, adding "bold" and "italics" for all instructions
>> realated to font. Do you think these would be usefull and possible to
>> apply?
>
> I find this to be frustrating too, so both are on my TODO list.
>
> Specifically: if the "where" x,y contains a %, use percentage of map
> window instead of inches for decorations. ie "x y" instead of "x% y%"
> use inches. Both ways have their merits & uses.

And both either x%,y% or x,y will be possible to use in any instruction
which requires position? That'd be excellent.

> Things are entrenched in inch units due to that is the unit which the
> PostScript language uses (inch/72). When you set font size to "10",
> you are really setting it to 10/72". It runs deep. + placement is
> confusing enough as it is. I don't want to make it worse.
>
> re. font sizing. Yes, the text, labels, and comments instructions are
> awkward. If you don't give "text" a fontsize it defaults to 10points.
> Currently I edit the .ps file in a text editor to change that to
> 8points or whatever if I need to. But I'm not going to drop existing
> functionality just becasue I don't use it (ie ground based sizing).

Can you tell what is the reason for ground based font sizing in map
production?

> You can do bold or italics by changing the "font" subinstruction I
> think. Watch this space. text+labels really need better fontsize
> control.
>
>
>> Much thanks for taking care of ps.map.
>
> Total self interest I assure you. :)

Gosh, and I thought you where spending your time just to satisfy my egotic
demandings... ;)

Please let me bother you with some remarks on ps.map. I'd be grateful if you 
could take a look.

1. Problems with margins ie. the black frame extents. The bottom cannot be
set eg. to 0. The possible minimun is always the S region value. Also, when
using 0 for top and right the output is not like one would expect, and
different in regard to paper size. Eg. in case of a4 the resulting top and
right borders are trunctated. In the opposite I recall when I used some
non-standard paper size I got a one pixel column of map canvas standing out
the frame, while the three other borders where ok. What could it be?

2. How to get rid of the frame for good?

3. Could there be a 'presentation slide' paper size preset added (bad
idea?)?

4. Regarding the manual: could the mapping instructions be grouped into
thematic sections instead of alphabetical order? Say general options,
rasters, vectors, decorations, externals (for eps, psfile, read). Much
easier to learn then in my opinion.

Regards
Maciek