(it's not split in the script but is here to fit the MUA.)
I don't see the text in column 'str_1' on the display. Do I need to
explicitly declare a font and the other attributes? If so, where do I find a
list of acceptable names?
Also, on a related note, how can I change the column names in those .dbf
tables?
I don't see the text in column 'str_1' on the display.
add display=attr
Along this line, may I make a feature request/suggestion?
In the wxpython gui, when I setup the display options for a vector feature, the choice of which column to use for the labels is on one tab, but the display=shape,attr,cat etc is on another tab. Even tho' I know this, I've found myself often selecting the the attribute column, and forgetting to enable display of attributes, then wondering why the labels don't display.
Is it possible to auto-magically enable display=attr once an attribute column is selected for labeling?
Thanks,
Micha
Along this line, may I make a feature request/suggestion?
In the wxpython gui, when I setup the display options for a vector
feature, the choice of which column to use for the labels is on one tab,
but the display=shape,attr,cat etc is on another tab. Even tho' I know
this, I've found myself often selecting the the attribute column, and
forgetting to enable display of attributes, then wondering why the
labels don't display.
Is it possible to auto-magically enable display=attr once an attribute
column is selected for labeling?
In general those are the generic automatically generated module GUIs so
fancy tricks are out. However we could move display= to the Selection tab
for a bit more visibility I guess. Although it's stretching the definition
somewhat.
or even make it Required=YES so it gets on the first tab (I don't like
abusing that if we can help it, but in this case you might be able to
make a case that display= something should always be set).
(yeah, d.vect has an abundance of options.
if overwhelmed see svn/grass-addons/display/d.shortcuts/ )
I'm not clear that either d.mark or d.stations will help. My problem is
that the three project-related sits are close to each other and the labels
overlap on the whole basin map.
What I see of the xref and yref controls is they apply to all labels. Is
there a way to specify the position for each label relative to the site
itself? For example, if the two almost vertically aligned had labels to
their left, and the third site (almost horizontal, and slightly below the
second site) had its label to the right there would be no overlap.
My problem is that the three project-related sits are close to
each other and the labels overlap on the whole basin map.
What I see of the xref and yref controls is they apply to all
labels. Is there a way to specify the position for each label
relative> to the site itself? For example, if the two almost
vertically aligned had labels to their left, and the third site
(almost horizontal, and slightly below the second site) had its
label to the right there would be no overlap.
you should use the v.label module if you want advanced placement control.
it is one case when you are encouraged to hack the x,y offsets in the
$MAPSET/paint/labels/ text file by hand. It goes well with unix power-
tools. Use d.labels + d.redraw while tweaking the labels file in a text
editor in another window.
for automatic overlap conflict-resolution you can try the v.label.sa
module.
you should use the v.label module if you want advanced placement control.
it is one case when you are encouraged to hack the x,y offsets in the
$MAPSET/paint/labels/ text file by hand. It goes well with unix power-
tools. Use d.labels + d.redraw while tweaking the labels file in a text
editor in another window.
for automatic overlap conflict-resolution you can try the v.label.sa
module.
Hamish,
v.label.sa works just fine for labeling the project-specific points of
interest. Thank you.
Now I need to find the way to place a label without reference to a
specific table and attribute column. d.label displays the labels created
with v.label[.sa], and displays _all_ stream names visible in the region.
This would not normally be an issue, but within the one basin, each
tributary is given the same name as the main creek, and all I want is a
single label I can place along the mainstem of the drainage.
d.text seems to be the appropriate module, but I've bumped into an
interesting situation with it. Here's the command:
The above displays the creek name in blue, rotated, and the background
rectangle in white, horizontal, and outside the string itself. Yet, when I
remove the bgcolor= option, the text does not display. Check mate.
How can I get either 1) the background color box to match the alignment
and rotation of the text or b) leave the background color box off while
allowing the text to display?
How can I get either 1) the background color box to match the alignment
and rotation of the text or b) leave the background color box off while
allowing the text to display?
Found that d.text does the latter; for some reason it was out of the view
initially.
tip: 'd.where -f' is handy for figuring out what at= should be set to.
How can I get either 1) the background color box to match
the alignment and rotation of the text or
added as bug # 855
b) leave the background color box off while allowing the
text to display?
fixed in 6.5svn r40214. (will be ported to other branches asap)
previously you just had to not use the bgcolor= option at all,
bgcolor=none was leaving it in limbo.
tip: 'd.where -f' is handy for figuring out what at= should be set to.
Minor trial-and-error worked well, too. Tweaking the x and y positions a
percent or two, and the rotational angle a few degrees got it properly
placed. However, as my later posts pointed out, using d.out.file moves the
text (and increases its size) relative to the monitor display.
added as bug # 855
Thank you. I don't know if this is something we mere users do directly.
fixed in 6.5svn r40214. (will be ported to other branches asap) previously
you just had to not use the bgcolor= option at all, bgcolor=none was
leaving it in limbo.
Strangely enough, it started working without the bgcolor= option. I am
using 6.5svn but I don't know the svn version number.
Thank you. I don't know if this is something we mere
users do directly.
filing bug reports? go for it!
there is some text on the website about how we like our bug
reports.. usual stuff- add as much detail as possible, stick to
specific behaivour, try the latest version first, etc.
the only barrier to entry is that you have to create yourself
an osgeo account. (just takes a minute & helps keep out the spam)
> fixed in 6.5svn r40214.
Strangely enough, it started working without the
bgcolor= option.
right. "bgcolor=none" was the culprit.
I am using 6.5svn but I don't know the svn version number.
well I just fixed it 20 minutes ago after reading your email...
filing bug reports? go for it! there is some text on the website about how
we like our bug reports.. usual stuff- add as much detail as possible,
stick to specific behaivour, try the latest version first, etc.
That's normal.
right. "bgcolor=none" was the culprit.
I am using 6.5svn but I don't know the svn version number.
well I just fixed it 20 minutes ago after reading your email...
I don't remember if I had set bgcolor=none, or just eliminated that
option. Regardless, first few times it didn't work so I sent the message,
then I must have accidently did it correctly so it did work properly.