[GRASS-dev] d.labels

[Wolf Bergenheim]

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! :D

--Wolf

-- 

<:3 )---- Wolf Bergenheim ----( 8:>