[GRASS-dev] Re: [GRASS GIS] #340: d.labels doesn't place labels exactly on coordinate point in label file.

[GRASS GIS]

#340: d.labels doesn't place labels exactly on coordinate point in label file.
--------------------------+-------------------------------------------------
  Reporter:  wolf         |       Owner:  hamish          
      Type:  enhancement  |      Status:  closed          
  Priority:  minor        |   Milestone:  6.4.0           
 Component:  default      |     Version:  svn-develbranch6
Resolution:  worksforme   |    Keywords:                  
  Platform:  All          |         Cpu:  Unspecified     
--------------------------+-------------------------------------------------
Changes (by wolf):

  * status:  assigned => closed
  * resolution:  => worksforme

Comment:

 Replying to [comment:3 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

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/340#comment:4>
GRASS GIS <http://grass.osgeo.org>