On 27.04.2008 17:26, Hamish wrote:
I seem to recall looking at merging "NONE" into d.labels/ps.map when you
were last working on v.labels.sa, and deciding that it was not
appropriate for unremembered reasons.
I actually never really did understand your reasons to refuse said patch. It doesn't change v.label behavior in anyway, unless ref is none.
Could you explain how none,none differs from center,center?
is it meant to be exactly lower,left of the first glyph? what if that is
a "-"? (eg elev=-100)
none,none Puts the label coordinate 0,0 exactly on the label point, and this the label will fit inside the blue skyline, which is what the module uses to represent a label. center,center puts the center of the label on the coordinate point? right?
V.label.sa takes letter shapes into account when it calculates label positions, so no worries if the letter starts with say "g" Or any other letter with descenders.
Please see [1] for example screenshots.
...
[1] http://wolf.bergenheim.net/src/GRASS/v.label.sa
yes, something is wrong there but I am pretty sure I had label placement
working correctly for all refs, so there is some mystery?
I'm sure it works as long as you use v.label, which counts on d.labels doing a bit of adjustment. But it would be hard to make v.label.sa take this final adjustment into account...
e.g. do those
labels include a newline which is making it into a 2 line label? well I
don't think it is that, but something is odd. I did a lot of work in the
past to make the placement correct. Especially the US-1 touching the road
I think I would have caught. I did do some rotation and placement fixes
after v.label.sa was started, and I don't think they were merged to .sa,
so fyi don't consider v.label.sa without overlap turned on == v.label.
v.label.sa doesn't use any code from v.label (well the label file creation is I suppose similar, and it does take a bunch of the same parameters)
Anyway, please give me the week to investigate and remember about it
before committing the patches; ps.map too. Maybe it will be ok but I want
to convince myself first.
Sure thing. In the meanwhile I'll do some adjusting. E.g. if the label is longer then the line gets treated like a point label, which is not exactly optimal, but was done in the original paper. I'll see if I can figure out a better way. Maybe reverting to v.label behavior might be a good idea here? I guess it depends on how much shorter the line is compared to the label. Another thing I'd want to add is support for multiple input vectors, so that the users won't have to combine the vector layers first. But this can wait for later.
I had hoped one day when you were happy to call v.label.sa "finished" we
could merge them and make non-overlapping labels mode a -flag of v.label.
We are very close to this. Once I get some rudimentary area label positioning code in place I'm ready to call this almost done, and think we can start merging the two. Especially if you'll accept my NONE patches 
Man, it's great to find a few minutes to hack on GRASS again! 
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
