[GRASS-user] Label difficulties

GRASS GRASS user
1

I am trying to work with a map that has multi-line vector labels, over a raster basemap. I have tried it a few different ways and run into different problems with each.
I am using the 6.3 binary by William Kyngesburye on Mac.
First I just tried adding the two characters "\n" to the labels, then ran v.label.
If I then add a raster label layer it does go over several lines, and all looks correct. The problem is when I try to save it to jpg and print it that the text is too "pixelated" and looks terrible (also looks the same if I save it to a pdf). I tried changing the resolution with g.region, but it did not seem to have any effect. The current region is set to the resolution of the actual raster basemap, so maybe that is why?
Next I tried adding a postscript label layer instead. That layer looks good on the screen and when saved to a PDF, in terms of the resolution. The problem is that the "\n" in the text is showing up explicitly, as those two characters, rather then causing a new line in the labels. So the labels have these extra characters and break in odd places. This is the case both when viewing this layer in the Map display and the saved version.
So my main question is how can I get good quality multi-line labels to a saved file? Is there a way to cause the font resolution to be higher in my raster layer? Is there a way to get a vector layer to break across multiple lines where I want? Is there some other solution that I am missing?

Thanks,

--Adam

2

Adam Dershowitz wrote:

I am trying to work with a map that has multi-line vector labels,
over a raster basemap. I have tried it a few different ways and run
into different problems with each.
I am using the 6.3 binary by William Kyngesburye on Mac.
First I just tried adding the two characters "\n" to the labels, then
ran v.label.
If I then add a raster label layer it does go over several lines, and
all looks correct. The problem is when I try to save it to jpg and
print it that the text is too "pixelated" and looks terrible (also
looks the same if I save it to a pdf). I tried changing the
resolution with g.region, but it did not seem to have any effect.
The current region is set to the resolution of the actual raster
basemap, so maybe that is why?

My guess is that the crummy looking fonts is the result of a limitation
in the PS driver, although Michael might be able to confirm that. If it's
worth anything, the PNG driver actually makes the fonts look nicer than
on the xmon displays. (GUI canvas has the nice version)

What save display as.. JPEG format did you use? 95%? does the JPEG look
ok on the screen but it not print nicely?

Worst case you could take a screenshot of what you see in the display
window and clean that up using Gimp or your favorite paint program.

Next I tried adding a postscript label layer instead. That layer
looks good on the screen and when saved to a PDF, in terms of the
resolution. The problem is that the "\n" in the text is showing up
explicitly, as those two characters, rather then causing a new line
in the labels. So the labels have these extra characters and break
in odd places. This is the case both when viewing this layer in the
Map display and the saved version.

My guess is that is an oversight in that tool which hasn't been
programmed in yet. '\n' should be processed by it into a newline.

It's in gui/tcltk/gis.m/maplabels.tcl ~ line 433:
proc GmCLabels::display {}
...
  "text" {
    set opt($id,1,ltxt) $val

maybe a way to process the text string with formatting codes to newlines
automatically? (tcl is string friendly, so search and replace shouldn't
can't be too hard, although I've no idea how)

% set a {1\n2}
1\n2
% set a "1\n2"
1
2

Probably the linewrap and border box code in there needs updating too.

So my main question is how can I get good quality multi-line labels
to a saved file? Is there a way to cause the font resolution to be
higher in my raster layer? Is there a way to get a vector layer to
break across multiple lines where I want? Is there some other
solution that I am missing?

You might try ps.map or d.* commands directly on the command line, they
might not be as user friendly as the GUI, but they are more mature and
IM(biased)O ps.map creates the best looking output.

Hamish

3

On Aug 27, 2007, at 9:39 PM, Hamish wrote:

Adam Dershowitz wrote:

I am trying to work with a map that has multi-line vector labels,
over a raster basemap. I have tried it a few different ways and run
into different problems with each.
I am using the 6.3 binary by William Kyngesburye on Mac.
First I just tried adding the two characters "\n" to the labels, then
ran v.label.
If I then add a raster label layer it does go over several lines, and
all looks correct. The problem is when I try to save it to jpg and
print it that the text is too "pixelated" and looks terrible (also
looks the same if I save it to a pdf). I tried changing the
resolution with g.region, but it did not seem to have any effect.
The current region is set to the resolution of the actual raster
basemap, so maybe that is why?

My guess is that the crummy looking fonts is the result of a limitation
in the PS driver, although Michael might be able to confirm that. If it's
worth anything, the PNG driver actually makes the fonts look nicer than
on the xmon displays. (GUI canvas has the nice version)

What save display as.. JPEG format did you use? 95%? does the JPEG look
ok on the screen but it not print nicely?

I just tried out the PNG, and it looks about like the JPEG. I had been saving the JPEG at "very high resolution (300% your current resolution)" I think that the issue is that both look a bunch like the screen. But if I zoom on the screen the label font size changes and uses an appropriate number of pixels so that it looks good. But if I print the whole thing and then try to read the labels, they are pretty small and seem to be drawn with 5x7 pixels or so. In other words they look like an LED display or something.

Worst case you could take a screenshot of what you see in the display
window and clean that up using Gimp or your favorite paint program.

Essentially what I need is for the text to be higher resolution then the screen, even though the basemap is fine at the current resolution. So that won't really help.

Next I tried adding a postscript label layer instead. That layer
looks good on the screen and when saved to a PDF, in terms of the
resolution. The problem is that the "\n" in the text is showing up
explicitly, as those two characters, rather then causing a new line
in the labels. So the labels have these extra characters and break
in odd places. This is the case both when viewing this layer in the
Map display and the saved version.

My guess is that is an oversight in that tool which hasn't been
programmed in yet. '\n' should be processed by it into a newline.

It's in gui/tcltk/gis.m/maplabels.tcl ~ line 433:
proc GmCLabels::display {}
...
  "text" {
    set opt($id,1,ltxt) $val

maybe a way to process the text string with formatting codes to newlines
automatically? (tcl is string friendly, so search and replace shouldn't
can't be too hard, although I've no idea how)

% set a {1\n2}
1\n2
% set a "1\n2"
1
2

I might try to look into that.

Probably the linewrap and border box code in there needs updating too.

So my main question is how can I get good quality multi-line labels
to a saved file? Is there a way to cause the font resolution to be
higher in my raster layer? Is there a way to get a vector layer to
break across multiple lines where I want? Is there some other
solution that I am missing?

You might try ps.map or d.* commands directly on the command line, they
might not be as user friendly as the GUI, but they are more mature and
IM(biased)O ps.map creates the best looking output.

I might try to work it out that way. Although I wonder if ps.map will correctly handle a multi-line labels with the \n in them? Or will I end up with the same problem? It also looks like ps.map can only take a single raster map, when I am currently using two maps that are overlayed. I will have to do that by hand as well, but I suppose it can be done.

Hamish

Thanks,

--Adam

4

On Aug 27, 2007, at 9:39 PM, Hamish wrote:

My guess is that the crummy looking fonts is the result of a limitation
in the PS driver, although Michael might be able to confirm that. If it's
worth anything, the PNG driver actually makes the fonts look nicer than
on the xmon displays. (GUI canvas has the nice version)

I found that I actually can use the PNG driver (I had been just saving from the display to a png). And it does look better, if I crank up the size bunch.

So my main question is how can I get good quality multi-line labels
to a saved file? Is there a way to cause the font resolution to be
higher in my raster layer? Is there a way to get a vector layer to
break across multiple lines where I want? Is there some other
solution that I am missing?

You might try ps.map or d.* commands directly on the command line, they
might not be as user friendly as the GUI, but they are more mature and
IM(biased)O ps.map creates the best looking output.

But, for either using the PNG driver, ps.map, or d.* commands I can't seem to figure out how to combine two raster maps. In other words, what I am currently doing with the GUI, is displaying two raster maps, one is 50% transparent, and then adding some vector information over the top of that. With the GUI I just set the opaque to transparent slider for one of the maps.
Is there a way to do the equivalent from the command line? Or just to overlay two maps, one at 50% opaque, to generate a new raster map? It seems like it should be easy, but I am not having any luck figuring it out. I did try g.pnmcomp, that the gui uses, but it seems that it does not find the files properly and it "isn't meant for the end user" anyway.
Any ideas?

--Adam

5

Adam Dershowitz wrote:

> You might try ps.map or d.* commands directly on the command line,
> they
> might not be as user friendly as the GUI, but they are more mature and
> IM(biased)O ps.map creates the best looking output.

But, for either using the PNG driver, ps.map, or d.* commands I
can't seem to figure out how to combine two raster maps. In other
words, what I am currently doing with the GUI, is displaying two
raster maps, one is 50% transparent, and then adding some vector
information over the top of that. With the GUI I just set the opaque
to transparent slider for one of the maps.

Is there a way to do the equivalent from the command line? Or just
to overlay two maps, one at 50% opaque, to generate a new raster
map? It seems like it should be easy, but I am not having any luck
figuring it out. I did try g.pnmcomp, that the gui uses, but it
seems that it does not find the files properly and it "isn't meant
for the end user" anyway.
Any ideas?

Use g.pnmcomp, pnmcomp (from NetPBM) or GIMP (etc).

The input= and mask= arguments to g.pnmcomp refer to PPM/PGM files,
e.g. those produced by the PNG driver (despite its name, it can
produce either PNG, PPM/PGM or BMP files, depending upon the setting
of $GRASS_PNGFILE).

You can blend two raster maps with r.blend, but that only makes sense
if you're already dealing with raster maps. If you want to blend
display output, use g.pnmcomp or an image-editing program.

--
Glynn Clements <glynn@gclements.plus.com>

6

"H" == Hamish <hamish_nospam@yahoo.com> writes:

[...]

>> The problem is that the "\n" in the text is showing up explicitly,
>> as those two characters, rather then causing a new line in the
>> labels. So the labels have these extra characters and break in odd
>> places. This is the case both when viewing this layer in the Map
>> display and the saved version.

H> My guess is that is an oversight in that tool which hasn't been
H> programmed in yet. '\n' should be processed by it into a newline.

H> It's in gui/tcltk/gis.m/maplabels.tcl ~ line 433:

> proc GmCLabels::display {}
> ...
> "text" {
> set opt($id,1,ltxt) $val

H> maybe a way to process the text string with formatting codes to
H> newlines automatically? (tcl is string friendly, so search and
H> replace shouldn't can't be too hard, although I've no idea how)

> % set a {1\n2}
> 1\n2
> % set a "1\n2"
> 1
> 2

        It's rather simple:

% set a {1\n2}
1\n2
% subst -nocommands -novariables $a
1
2
%

H> Probably the linewrap and border box code in there needs updating
H> too.

7

Hamish wrote:

> maybe a way to process the text string with formatting codes to
> newlines automatically? (tcl is string friendly, so search and
> replace shouldn't be too hard, although I've no idea how)

Ivan wrote:

        It's rather simple:

% set a {1\n2}
1\n2
% subst -nocommands -novariables $a
1
2
%

Thanks Ivan, that works! Applied in 6.3cvs.

The border box still needs to be updated to count the number of lines in
the string and adjust the background box width and height accordingly. For
now you can just turn off the background box.

Bug: I notice that if you try and change the PS label background box
color or font color it just gets reset when you redraw the display.

I've little idea about Tcl/Tk so I must leave these small tasks for
someone else. The "sample" label file that comes with Spearfish has a
\n newline in it to test with.

I would hold off backporting the fixes to the 6.2.x branch until it is
all working in 6.3cvs, then do it as a single patch.

Hamish

8

I haven't made a new Mac binary in a while. I'll try to get one out today so you can test this Adam.

On Aug 29, 2007, at 4:50 AM, Hamish wrote:

Hamish wrote:

maybe a way to process the text string with formatting codes to
newlines automatically? (tcl is string friendly, so search and
replace shouldn't be too hard, although I've no idea how)

Ivan wrote:

        It's rather simple:

% set a {1\n2}
1\n2
% subst -nocommands -novariables $a
1
2
%

Thanks Ivan, that works! Applied in 6.3cvs.

The border box still needs to be updated to count the number of lines in
the string and adjust the background box width and height accordingly. For
now you can just turn off the background box.

Bug: I notice that if you try and change the PS label background box
color or font color it just gets reset when you redraw the display.

I've little idea about Tcl/Tk so I must leave these small tasks for
someone else. The "sample" label file that comes with Spearfish has a
\n newline in it to test with.

I would hold off backporting the fixes to the 6.2.x branch until it is
all working in 6.3cvs, then do it as a single patch.

Hamish

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"

- The Ruler of the Universe

9

On Aug 29, 2007, at 2:50 AM, Hamish wrote:

Hamish wrote:

maybe a way to process the text string with formatting codes to
newlines automatically? (tcl is string friendly, so search and
replace shouldn't be too hard, although I've no idea how)

Ivan wrote:

        It's rather simple:

% set a {1\n2}
1\n2
% subst -nocommands -novariables $a
1
2
%

Thanks Ivan, that works! Applied in 6.3cvs.

The border box still needs to be updated to count the number of lines in
the string and adjust the background box width and height accordingly. For
now you can just turn off the background box.

Bug: I notice that if you try and change the PS label background box
color or font color it just gets reset when you redraw the display.

I've little idea about Tcl/Tk so I must leave these small tasks for
someone else. The "sample" label file that comes with Spearfish has a
\n newline in it to test with.

I would hold off backporting the fixes to the 6.2.x branch until it is
all working in 6.3cvs, then do it as a single patch.

Hamish,
you and a few others suggested that I could use r.blend. Initially it did not work as expected. It turns out that my top map was smaller than my basemap and that r.blend was still blending beyond the border of the top map, so that the bottom map looked washed out. I ended up editing r.blend to make it work as I expected. I am not sure who this should go to, but let me suggest the following change to r.blend:
Replace this:
r.mapcalc "$GIS_OPT_OUTPUT.r = r#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - .$GIS_OPT_PERCENT) * r#$GIS_OPT_SECOND"
r.mapcalc "$GIS_OPT_OUTPUT.g = g#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - .$GIS_OPT_PERCENT) * g#$GIS_OPT_SECOND"
r.mapcalc "$GIS_OPT_OUTPUT.b = b#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - .$GIS_OPT_PERCENT) * b#$GIS_OPT_SECOND"

with this:

r.mapcalc "$GIS_OPT_OUTPUT.r = if(isnull($GIS_OPT_FIRST),r#$GIS_OPT_SECOND, r#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - .$GIS_OPT_PERCENT) * r#$GIS_OPT_SECOND)"
r.mapcalc "$GIS_OPT_OUTPUT.g = if(isnull($GIS_OPT_FIRST),g#$GIS_OPT_SECOND, g#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - .$GIS_OPT_PERCENT) * g#$GIS_OPT_SECOND)"
r.mapcalc "$GIS_OPT_OUTPUT.b = if(isnull($GIS_OPT_FIRST),b#$GIS_OPT_SECOND, b#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - .$GIS_OPT_PERCENT) * b#$GIS_OPT_SECOND)"

That way, in places where the top map is null it just leaves the bottom map alone.

Is there a particular developer or other list that this suggestion should be sent to?

Again, thanks for the help, and I do now have things working as I need.
  

10

Adam Dershowitz wrote:

you and a few others suggested that I could use r.blend. Initially
it did not work as expected. It turns out that my top map was
smaller than my basemap and that r.blend was still blending beyond
the border of the top map, so that the bottom map looked washed out.
I ended up editing r.blend to make it work as I expected. I am not
sure who this should go to, but let me suggest the following change
to r.blend:
Replace this:
r.mapcalc "$GIS_OPT_OUTPUT.r = r#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT +
(1.0 - .$GIS_OPT_PERCENT) * r#$GIS_OPT_SECOND"
r.mapcalc "$GIS_OPT_OUTPUT.g = g#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT +
(1.0 - .$GIS_OPT_PERCENT) * g#$GIS_OPT_SECOND"
r.mapcalc "$GIS_OPT_OUTPUT.b = b#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT +
(1.0 - .$GIS_OPT_PERCENT) * b#$GIS_OPT_SECOND"

with this:

r.mapcalc "$GIS_OPT_OUTPUT.r = if(isnull($GIS_OPT_FIRST),r#
$GIS_OPT_SECOND, r#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - .
$GIS_OPT_PERCENT) * r#$GIS_OPT_SECOND)"
r.mapcalc "$GIS_OPT_OUTPUT.g = if(isnull($GIS_OPT_FIRST),g#
$GIS_OPT_SECOND, g#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - .
$GIS_OPT_PERCENT) * g#$GIS_OPT_SECOND)"
r.mapcalc "$GIS_OPT_OUTPUT.b = if(isnull($GIS_OPT_FIRST),b#
$GIS_OPT_SECOND, b#$GIS_OPT_FIRST * .$GIS_OPT_PERCENT + (1.0 - .
$GIS_OPT_PERCENT) * b#$GIS_OPT_SECOND)"

That way, in places where the top map is null it just leaves the
bottom map alone.

I suggest:

$GIS_OPT_OUTPUT.r = eval(\
  n1 = isnull($GIS_OPT_FIRST), n2 = isnull($GIS_OPT_SECOND),\
  k1 = n1 ? 0 : n2 ? 1 : $GIS_OPT_PERCENT/100.0,\
  k2 = n2 ? 0 : n1 ? 1 : 1.0 - $GIS_OPT_PERCENT/100.0,\
  k1 * r#$GIS_OPT_FIRST + k2 * r#$GIS_OPT_SECOND)
$GIS_OPT_OUTPUT.g = k1 * g#$GIS_OPT_FIRST + k2 * g#$GIS_OPT_SECOND
$GIS_OPT_OUTPUT.b = k1 * b#$GIS_OPT_FIRST + k2 * b#$GIS_OPT_SECOND

Actually, I should probably get rid of the requirement that each
statement must be an assignment; the above would be more clear if the
eval() was separate to the .r calculation.

Is there a particular developer or other list that this suggestion
should be sent to?

This is the right place.

--
Glynn Clements <glynn@gclements.plus.com>

11

I fixed the bounding box size problem. It's in the cvs now. There is still a
problem, however, if the label is not aligned on center with the vector
point (this is NOT offset). When it is not aligned on center, it doesn't
match the bounding box. There needs to be more code to take care of this,
but it's really late now.

Note: if you don't click the override button, the labels will display
according to whatever is in the label file and use those defaults--reverting
the panel each time you click display. If you click the override button, it
will use whatever you set in the GUI panel and keep it showing.

Michael

On 8/29/07 2:50 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Hamish wrote:

maybe a way to process the text string with formatting codes to
newlines automatically? (tcl is string friendly, so search and
replace shouldn't be too hard, although I've no idea how)

Ivan wrote:

        It's rather simple:

% set a {1\n2}
1\n2
% subst -nocommands -novariables $a
1
2
%

Thanks Ivan, that works! Applied in 6.3cvs.

The border box still needs to be updated to count the number of lines in
the string and adjust the background box width and height accordingly. For
now you can just turn off the background box.

Bug: I notice that if you try and change the PS label background box
color or font color it just gets reset when you redraw the display.

I've little idea about Tcl/Tk so I must leave these small tasks for
someone else. The "sample" label file that comes with Spearfish has a
\n newline in it to test with.

I would hold off backporting the fixes to the 6.2.x branch until it is
all working in 6.3cvs, then do it as a single patch.

Hamish

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

12

I managed to get the box to 'follow the label' now when you pick different
alignments. Hopefully this will finish off this issue. Thanks for your help
in identifying and solving it.

Michael

On 8/29/07 2:50 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Hamish wrote:

maybe a way to process the text string with formatting codes to
newlines automatically? (tcl is string friendly, so search and
replace shouldn't be too hard, although I've no idea how)

Ivan wrote:

        It's rather simple:

% set a {1\n2}
1\n2
% subst -nocommands -novariables $a
1
2
%

Thanks Ivan, that works! Applied in 6.3cvs.

The border box still needs to be updated to count the number of lines in
the string and adjust the background box width and height accordingly. For
now you can just turn off the background box.

Bug: I notice that if you try and change the PS label background box
color or font color it just gets reset when you redraw the display.

I've little idea about Tcl/Tk so I must leave these small tasks for
someone else. The "sample" label file that comes with Spearfish has a
\n newline in it to test with.

I would hold off backporting the fixes to the 6.2.x branch until it is
all working in 6.3cvs, then do it as a single patch.

Hamish

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton