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

GRASS GIS GRASS GIS developer
1

this bug's URL: http://intevation.de/rt/webrt?serial_num=3350
-------------------------------------------------------------------------

Subject: ps.map: vpoints draws before grid

In ps.map, vpoint "markers" are drawn under the grid lines. Not sure if same
is true for vector lines, but markers should go on top. Need to have a call in
ps_map.c after do_grid() to call do_vectors().

Not sure how to handle masked points, I think they'll always have to be drawn
before the grid lines.

Proposed solution: make (ie separate out) a do_vpoints() function in
do_vectors.c, conditionalize a call to it within the do_vectors() function so
it only runs when masked, then place a call to do_vpoints() after do_grid() in
ps_map.c if not masked.

?
Hamish

-------------------------------------------- Managed by Request Tracker

2

Hamish

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.

Maciek

----- Original Message ----- From: "Request Tracker" <grass-bugs@intevation.de>
To: <grass5@grass.itc.it>
Sent: Thursday, June 16, 2005 6:45 AM
Subject: [GRASS5] [bug #3350] (grass) ps.map: vpoints draws before grid

this bug's URL: http://intevation.de/rt/webrt?serial_num=3350
-------------------------------------------------------------------------

Subject: ps.map: vpoints draws before grid

In ps.map, vpoint "markers" are drawn under the grid lines. Not sure if
same
is true for vector lines, but markers should go on top. Need to have a
call in
ps_map.c after do_grid() to call do_vectors().

Not sure how to handle masked points, I think they'll always have to be
drawn
before the grid lines.

Proposed solution: make (ie separate out) a do_vpoints() function in
do_vectors.c, conditionalize a call to it within the do_vectors() function
so
it only runs when masked, then place a call to do_vpoints() after
do_grid() in
ps_map.c if not masked.

?
Hamish

-------------------------------------------- Managed by Request Tracker

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

3

Hi Maciek,

> In ps.map, vpoint "markers" are drawn under the grid lines. Not sure
> if same is true for vector lines, but markers should go on top. Need
> to have a call in ps_map.c after do_grid() to call do_vectors().

Done in CVS by adding do_vpoints().

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?

Vectors of the same masking level are drawn in the order you list them.

You can control the order further by using "masked [y|n]" for the
features that support that. Masked features are drawn first, even if
there isn't a mask in place.

Letting people draw text or scalebars on top of or under a legend, e.g.,
isn't very high on my priority list. The idea is that by default it does
the "right thing". i.e.:

General order:

1. raster maps
2. vector maps (areas & lines)
3. grid lines
4. point markers, symbols/icons, including vector points
5. labels, text, legends, scalebars, etc.

How would you rearrange that list?

Hamish

4

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

Hi Maciek,

> In ps.map, vpoint "markers" are drawn under the grid lines. Not sure
> if same is true for vector lines, but markers should go on top. Need
> to have a call in ps_map.c after do_grid() to call do_vectors().

Done in CVS by adding do_vpoints().

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.

Vectors of the same masking level are drawn in the order you list them.

You can control the order further by using "masked [y|n]" for the
features that support that.

Masked features are drawn first, even if
there isn't a mask in place.

I didn't know that. Could it be put in the manual?

Letting people draw text or scalebars on top of or under a legend, e.g.,
isn't very high on my priority list. The idea is that by default it does
the "right thing". i.e.:

General order:

1. raster maps
2. vector maps (areas & lines)
3. grid lines
4. point markers, symbols/icons, including vector points
5. labels, text, legends, scalebars, etc.

How would you rearrange that list?

Looks ok. Do you mind putting the "General order:" you listed in the manual as well, somewhere in the begining?

WISH: anyway total freedom in arranging the order and rendering by the order in instructions file would make things clear and simple. I understand though there is notime for doing it now.

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?

Much thanks for taking care of ps.map.

Maciek

5

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

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

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.

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.
:slight_smile:

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.

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).
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. :slight_smile:

Hamish

6

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

..

You can do bold or italics by changing the "font" subinstruction I
think. Watch this space. text+labels really need better fontsize
control.

e.g. bold:

comments comments.txt
  where 1.0 10.8
  font Helvetica Bold
  fontsize 13
  end

Hamish

7

From: "Hamish" <hamish_nospam@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.
:slight_smile:

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. :slight_smile:

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

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

8

I'm short on time (currently in the hardcopy output stage you see...) so
I won't address larger issues right now (e.g. ordering of layers), but:

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

..

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

..

> You can do bold or italics by changing the "font" subinstruction I
> think. Watch this space. text+labels really need better fontsize
> control.
> e.g. bold:
>
> comments comments.txt
> where 1.0 10.8
> font Helvetica Bold
> fontsize 13
> end

I have just added a "fontsize" sub-command to the "text" command and
v.labels parsing code in ps.map. enjoy.

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

No, I can't.

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

Yes. If it sees the "%" it calculates based on position in the map box.
I had a cursory look at doing this last night for the scalebar. It
wasn't as easy as I first thought so I won't get to this in the near
future.

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?

bug probably. Can you provide a ps.map command file using the spearfish
dataset which reproduces this?

"maploc" will auto-adjust itself to the default margin limits or as defined
in the "paper" command.

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

command file: Don't know. (that doesn't mean it isn't possible)
in the code: find where it draws it, /* comment it out */, and recompile.
   may require trial and error, but easier than you might think.

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

Yes, but what resolution? Generic .eps + 1.3333:1 aspect ratio?

Using d.* + d.out.png is better for this?

ps -> png:
pstoimg -aaliastext -flip r90 -out output.png -scale 1.3 -crop a input.ps

('pstoimg' is part of the latex2html debian package)

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.

I've added internal links to the help page in CVS:
  http://grass.ibiblio.org/grass61/manuals/html61_user/ps.map.html

Hopefully it makes the HTML version of the man page easier to use.

Hamish

9

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

I'm short on time (currently in the hardcopy output stage you see...) so
I won't address larger issues right now (e.g. ordering of layers), but:

I have just added a "fontsize" sub-command to the "text" command and
v.labels parsing code in ps.map. enjoy.

Great.

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

No, I can't.

Anybody?

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?

bug probably. Can you provide a ps.map command file using the spearfish
dataset which reproduces this?

Will do about weekend.

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

command file: Don't know. (that doesn't mean it isn't possible)

Any ps.map user who knows?

in the code: find where it draws it, /* comment it out */, and recompile.
  may require trial and error, but easier than you might think.

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

Yes, but what resolution? Generic .eps + 1.3333:1 aspect ratio?

Don't know. Folks?

Using d.* + d.out.png is better for this?

No vector width control, ugly vectors, ugly barscale, legend and comments,
harder to use for map series production. Naah.

ps -> png:
pstoimg -aaliastext -flip r90 -out output.png -scale 1.3 -crop a input.ps
('pstoimg' is part of the latex2html debian package)

Noted down, thank you. So far I've been using Image Magick's convert or GIMP.

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.

I've added internal links to the help page in CVS:
http://grass.ibiblio.org/grass61/manuals/html61_user/ps.map.html

Hopefully it makes the HTML version of the man page easier to use.

Yes, a little. Thanks.

Maciek

10

Since you are discussing wishes for ps.map:

How difficult would it be to add the 'size_att' option we had for sites in 5.4
ps.map to the vpoints command in ps.maps 6.1 ?

Moritz

On Tue, June 21, 2005 22:59, Maciek Sieczka said:

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

I'm short on time (currently in the hardcopy output stage you see...) so
I won't address larger issues right now (e.g. ordering of layers), but:

I have just added a "fontsize" sub-command to the "text" command and
v.labels parsing code in ps.map. enjoy.

Great.

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

No, I can't.

Anybody?

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?

bug probably. Can you provide a ps.map command file using the spearfish
dataset which reproduces this?

Will do about weekend.

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

command file: Don't know. (that doesn't mean it isn't possible)

Any ps.map user who knows?

in the code: find where it draws it, /* comment it out */, and recompile.
  may require trial and error, but easier than you might think.

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

Yes, but what resolution? Generic .eps + 1.3333:1 aspect ratio?

Don't know. Folks?

Using d.* + d.out.png is better for this?

No vector width control, ugly vectors, ugly barscale, legend and comments,
harder to use for map series production. Naah.

ps -> png:
pstoimg -aaliastext -flip r90 -out output.png -scale 1.3 -crop a input.ps
('pstoimg' is part of the latex2html debian package)

Noted down, thank you. So far I've been using Image Magick's convert or
GIMP.

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.

I've added internal links to the help page in CVS:
http://grass.ibiblio.org/grass61/manuals/html61_user/ps.map.html

Hopefully it makes the HTML version of the man page easier to use.

Yes, a little. Thanks.

Maciek

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

11

Since you are discussing wishes for ps.map:

How difficult would it be to add the 'size_att' option we had for
sites in 5.4 ps.map to the vpoints command in ps.maps 6.1 ?

You mean for doing this sort of thing?

http://grass.ibiblio.org/grass60/screenshots/images/d.vect.chart_pie.png

seems like a nice idea, but I'm not working on it right now.

Hamish

12

On Wed, June 22, 2005 7:02, Hamish said:

Since you are discussing wishes for ps.map:

How difficult would it be to add the 'size_att' option we had for
sites in 5.4 ps.map to the vpoints command in ps.maps 6.1 ?

You mean for doing this sort of thing?

http://grass.ibiblio.org/grass60/screenshots/images/d.vect.chart_pie.png

Well, I wasn't even that ambitious (although this would be the ideal). Just
being able to make the size of the symbol vary according to a value in one
column of the attribute table would already be very useful. It doesn't sound
too complicated, but then again, I haven't even looked at the source code,
yet.

seems like a nice idea, but I'm not working on it right now.

Well, if I have some time these days, I'll try to look into and understand the
source code...

I don't know why, but sizeable symbols never seem a priority in cartographic
software...

Moritz