[GRASSLIST:1179] ps.map pixel size and line attributes

GRASS GRASS user
1

Folks,

I'm trying to construct an illustration that contains a large number of
lines (hydrologic features, roads and a rectangular grid for a ground
water model) overlain on a raster map showing results from the ground
water model.

Using ps.map from version 5, beta 7 I set the resolution of my postscript
device to 360 (supposedly, 360 dpi) and I specify that the vector files
should be plotted with a line width of 1 pixel. The line I get is several
times wider than the 0.003 inch (approximate) thickness that it should be.
I need very fine lines on this map or the lines obscure each other and the
model results.

Is there some other way to reduce this pixel size? I tried using
fractional pixel widths with no improvement. I also tried using the
"cwidth" specification in ps.map.new and found that the lines in the model
grid vector file were not categorized, which brings up an entirely
different question.

I constructed the file with the model grid from an imported ascii file and
no attributes file was created when the file was imported. I tried using
the bulk labeling option in v.digit to label the lines (there are over
13,000 lines, so manually labelling them would be inefficient at best),
but it doesn't work -- no errors are produced, but I get no labelled
lines. Is there some other way to label the lines? I program; if someone
can tell me how the lines are identified in the attribute files, then I
can construct the attribute file myself.

Roger Miller

2

On Fri, Nov 24, 2000 at 02:00:00PM -0700, Roger S. Miller wrote:

Folks,

I'm trying to construct an illustration that contains a large number of
lines (hydrologic features, roads and a rectangular grid for a ground
water model) overlain on a raster map showing results from the ground
water model.

Using ps.map from version 5, beta 7 I set the resolution of my postscript
device to 360 (supposedly, 360 dpi) and I specify that the vector files
should be plotted with a line width of 1 pixel. The line I get is several
times wider than the 0.003 inch (approximate) thickness that it should be.
I need very fine lines on this map or the lines obscure each other and the
model results.

I'm not sure, but I think that width maybe should be "points" rather
than pixels. If that's the case, 1 point = 1/72 inch (according to
Adobe). But I don't know for sure. I don't know what "pixels" would be
in reference to.

Is there some other way to reduce this pixel size? I tried using
fractional pixel widths with no improvement. I also tried using the
"cwidth" specification in ps.map.new and found that the lines in the model
grid vector file were not categorized, which brings up an entirely
different question.

I constructed the file with the model grid from an imported ascii file and
no attributes file was created when the file was imported. I tried using
the bulk labeling option in v.digit to label the lines (there are over
13,000 lines, so manually labelling them would be inefficient at best),
but it doesn't work -- no errors are produced, but I get no labelled
lines. Is there some other way to label the lines? I program; if someone
can tell me how the lines are identified in the attribute files, then I
can construct the attribute file myself.

Well, did you try running v.support on the file before doing the bulk
labelling. I think it needs that to work (though it should produce an
error when it can't perform the operation).

Anyway, the line labels are identified by two files. The first:
dig_att/<map> holds a series of entries identified as 'P' for points,
'L' for lines and 'A' for areas. Each entry is then followed by an
easting, northing and a category value. The coordinates of the entry
should fall on the degenerate line for a point, the line for lines, or
within the area (but outside of islands) for areas.

The second file is the dig_cats/<map> file, and after a small header has
entries like:

n1: Some Label
n2: Another Label

The numbers in the first column connect with the dig_att/<map> file
category numbers. The part following the ':' is the category value.

If you're really interested, there's a programming manual available from
the website.

--
Eric G. Miller <egm2@jps.net>

3

On Fri, 24 Nov 2000, Eric G . Miller wrote:

I'm not sure, but I think that width maybe should be "points" rather
than pixels. If that's the case, 1 point = 1/72 inch (according to
Adobe). But I don't know for sure. I don't know what "pixels" would be
in reference to.

I rechecked the man page and it definitely says pixels. I took that as
being a line width (literally correct only for vertical and horizontal
lines) in terms of the postscript device resolution specified in the
ps.devices directory and selected with "ps.select". If the document
should say "points" then that might explain the behavior.

Well, did you try running v.support on the file before doing the bulk
labelling. I think it needs that to work (though it should produce an
error when it can't perform the operation).

I did run v.support.

Anyway, the line labels are identified by two files. The first:
dig_att/<map> holds a series of entries identified as 'P' for points,
'L' for lines and 'A' for areas. Each entry is then followed by an
easting, northing and a category value. The coordinates of the entry
should fall on the degenerate line for a point, the line for lines, or
within the area (but outside of islands) for areas.

Thanks a lot, Eric. That should be the info I need. I've been waiting to
download the programmer's manual until I have a little more time on my
hands to study it. If it contains this sort of information then I should
probably read it before I bother the list much more.

Roger Miller

4

On Fri, Nov 24, 2000 at 09:59:34PM -0700, Roger S. Miller wrote:

On Fri, 24 Nov 2000, Eric G . Miller wrote:

> I'm not sure, but I think that width maybe should be "points" rather
> than pixels. If that's the case, 1 point = 1/72 inch (according to
> Adobe). But I don't know for sure. I don't know what "pixels" would be
> in reference to.

I rechecked the man page and it definitely says pixels. I took that as
being a line width (literally correct only for vertical and horizontal
lines) in terms of the postscript device resolution specified in the
ps.devices directory and selected with "ps.select". If the document
should say "points" then that might explain the behavior.

> Well, did you try running v.support on the file before doing the bulk
> labelling. I think it needs that to work (though it should produce an
> error when it can't perform the operation).

I did run v.support.

Hi,

maybe you take a look at v.alabel and v.llabel to bulk label
areas/lines in a vector map.

Markus

5

On Sat, 25 Nov 2000, Markus Neteler wrote:

maybe you take a look at v.alabel and v.llabel to bulk label
areas/lines in a vector map.

I used v.alabel to label the areas in the model grid. It worked very
well. My 5beta7 release came with the manual page for v.llabel, but I
can't find the program itself.

For what it's worth, the model grid was built from an ascii digitizer
file. I wrote a little program that read the ascii digitizer file and
produced a list that matched Eric's description, with all of the attribute
values set to 1. I patched that list into the original attributes file
(which originally contained entries only for the areas), then re-ran
v.support. After that, the cwidth specification in ps.map.new gave me the
thin lines I needed.

Thank's for the help.

Roger Miller

6

On Sat, Nov 25, 2000 at 06:35:07PM -0700, Roger S. Miller wrote:

On Sat, 25 Nov 2000, Markus Neteler wrote:

> maybe you take a look at v.alabel and v.llabel to bulk label
> areas/lines in a vector map.

I used v.alabel to label the areas in the model grid. It worked very
well. My 5beta7 release came with the manual page for v.llabel, but I
can't find the program itself.

Hi Roger,

the v.llabel appears in 5beta8 onwards.

For what it's worth, the model grid was built from an ascii digitizer
file. I wrote a little program that read the ascii digitizer file and
produced a list that matched Eric's description, with all of the attribute
values set to 1. I patched that list into the original attributes file
(which originally contained entries only for the areas), then re-ran
v.support. After that, the cwidth specification in ps.map.new gave me the
thin lines I needed.

O.k. fine. Please note that from 5beta8 onwards ps.map.new is ps.map
(so we replaced the old version).

Regards

Markus

PS: GRASS 5 beta9 is scheduled for end of November (as soon as possible).
    This release is expected to be the last beta release, then
    GRASS 5.0stable shall be published.