d.labels doesn't place labels exactly on coordinate point in label file.

[wolf]

The attached patch fixes the issue by introducing a new keyword none for label placement, which will keep the label exactly on the coordinate point, without affecting the other placement algorithms of d.labels. This is needed for v.label.sa to work correctly, since it calculates the exact position where a label can be placed with minimum overlap. The secnd patch also adds support for the none placement keyword to ps.map

[wolf]

Patch for d.labels

[wolf]

Patch for ps.map

[hamish]

Pending review.

FWIW, this is an intentional part of the design, not a flaw. The needed enhancement (AIUI) is how to skip the automatic padding for placement= LEFT,RIGHT,TOP,BOTTOM so v.label.sa can place the label without worry that it will be by moved overly helpful rendering code later on.

i.e. how to accomplish the desired result without using "xref=yref=NONE", which to me is an incorrect and confusing terminology. Perhaps LEFT_0 and BOTTOM_0 could mean bottom-left with no-padding, or better yet, v.label.sa could position relative to CENTER,CENTER, which is not padded.

more later today or tomorrow once I study it properly, the above is from old memory,

Hamish

[hamish]

do I have this right?

d.labels: patch skips adjustments for dealing with multi-line labels (desired?), and puts bottom left corner of text box at the exact coordinate.

like:

  _____________
 .|_text here_|

ps.map: just like LOWER,LEFT placement but without any X,Y_just_offset which keeps the label off of the symbol.

I would prefer, in this order:

• use ref: center,center as the basis for offsets
• ref: bottom_0,left_0 instead of none,none to indicate where + no padding.

If it can be done with "ref: center,center" I'd be a lot happier.

some other points:

• I would not move the above rendering offsets into v.label.
• From the user's perspective I'd think they'd expect SA placement to be an optional flag of v.label. Codewise that may be harder, but I am just speaking about what a user might expect and long term goals.
• I do not have plans to replace v.label with v.label.sa. For one thing v.label has had some fixes after v.label.sa forked which AFAIK have not been ported (mostly to do with correctly handling rotation). I suspect there are a few other small things.
• v.label does not sort smallest label on top, nor (by default) IMO should it. Fine for SA, but isn't the whole point of SA that they not overlap in the first place, so not an issue?. See related filled-area "v.bubbleplot" for/against discussions to sort points to put smallest circles on top.

Hamish

[wolf]

Replying to hamish:

do I have this right?

d.labels: patch skips adjustments for dealing with multi-line labels (desired?), and puts bottom left corner of text box at the exact coordinate.

ps.map: just like LOWER,LEFT placement but without any X,Y_just_offset which keeps the label off of the symbol.

Yes, that is correct. It keeps track of all the lower left points of labels. However multi-line labels might not work. I haven't tested.

I would prefer, in this order:

• use ref: center,center as the basis for offsets
• ref: bottom_0,left_0 instead of none,none to indicate where + no padding.

If it can be done with "ref: center,center" I'd be a lot happier.

Okay. Thanks for that. I'll change the v.label.sa to calculate the center point, and use ref: center center

some other points:

• I would not move the above rendering offsets into v.label.

That is quite ok with the "inexact labels", I suppose that the label placement code could be moved to d.labels instead, and would work with on screen pixels... Perhaps it will be done so in the future. I made it this way because now I have an easy way to access vector layer info such as points, lines etc.

• From the user's perspective I'd think they'd expect SA placement to be an optional flag of v.label. Codewise that may be harder, but I am just speaking about what a user might expect and long term goals.

I agree.

• I do not have plans to replace v.label with v.label.sa. For one thing v.label has had some fixes after v.label.sa forked which AFAIK have not been ported (mostly to do with correctly handling rotation). I suspect there are a few other small things.

v.label.sa is NOT a fork or v.label, it doesn't do the "ordinary" label placement as v.label does. It only does "optimized" label placement. It does share a tiny fragment of code with v.label, namely the generation of the labels file entries, but even that is not a direct copy. It does have compatible options for ease of use.

• v.label does not sort smallest label on top, nor (by default) IMO should it. Fine for SA, but isn't the whole point of SA that they not overlap in the first place, so not an issue?. See related filled-area "v.bubbleplot" for/against discussions to sort points to put smallest circles on top.

Nor does v.label.sa. It now has an optional feature to hide all overlapping labels except for the one with the greatest weight.

--Wolf