User defined order for LABEL POSITION AUTO

[mapserver-bot]

Reporter: woodbri
Date: 2012/03/13 - 18:57
Trac URL: http://trac.osgeo.org/mapserver/ticket/4242
I mentioned in another thread the it would be nice to be able to control the order of the label attempts, maybe by listing them in order of preference. I found it very hard to get a layout of labels that I felt looked good. Using POSITION CC ended up being the best for the example of placing state abbreviations on the states. Using AUTO biases the labels to the left as we start labeling positions with UL

In most of the Automatic Label Positioning papers I have read they seem to express that the cartographically preferred order to be: CR, CL, UC, LC, UR, LR, UL, LL or in matrix form:

 7 3 5
 2 X 1
 8 4 6

Where X is the label point. That said, I think the order should be

 6 1 5
 4 X 3
 8 2 7

or UC, LC, CR, CL, UR, UL, LR, LL. And often I would use CC in the first position.

I bring this up because we probably need also to change the label positioning order dynamically (algorithmically) when there is a leader line and my assumption is that have some facility to do this would benefit both. The ideal order for positioning the label at the end of the leader would be to pick positions that are farthest from the object end of the leader. I think this will make for better looking labels and layout.

  5 3 1
  7 X 2
  8/6 4
  /           6 4 2
 o------------8-X 1
  \           7 5 3
  8\6 4
  7 X 2
  5 3 1

Above are few examples where o is the object end of the leader, X is the label end of the leader and the number are the positions to try in order.

The above forces the label to minimize intersection with its own leader and in general pushes the label away from an already crowded area.

'''tbonfort responded with:'''

For the time being this kind of adjustment isn't possible. The whole
shapeObj representing the label+markers is computed during the normal (i.e. not offsetted) phase of the labelcache rendering. If the label collides during this labelcache phase, then the offsetted position is determined by translating the computed shapeObj until it fits somewhere else. As such, it isn't possible to modify the label position once the offsetting phase has started, without having to recompute the shapeObj of the label+marker at each offsetted position.

I do agree that the final result would be better this way for certain use-cases (the use-case aimed-for for this initial implementation actually requires the label to remain fixed compared to its marker), and would apply when using label-level leader lines (instead of class-level ones, implemented now)

[mapserver-bot]

Author: tbonfort
Date: 2012/03/15 - 18:02
see also #4249

[mapserver-bot]

Author: olt
Date: 2012/03/15 - 18:27
#4249 contains two images that compare the default placement with a placement that starts with UC.

[mapserver-bot]

This is an automated comment

This issue has been closed due to lack of activity. This doesn't mean the issue is invalid, it simply got no attention within the last year. Please reopen with missing/relevant information if still valid.

Typically, issues fall in this state for one of the following reasons:

• Hard, impossible or not enough information to reproduce
• Missing test case
• Lack of a champion with interest and/or funding to address the issue