[mapserver-dev] New Label Offset code

[thomas bonfort]

On Mon, Mar 12, 2012 at 19:58, Stephen Woodbridge
<woodbri at swoodbridge.com> wrote:
> Hi Thomas,
>
> After playing with the label leader code all morning here is some feedback.
> Overall it is a really nice enhancement. Based on the discussions in tickets
> it seems like there are more things you want to do with it for finer
> control.
>
> Here are some thoughts on what is needed. I can put some or all of these
> into ticket(s) if you like.
>
> 1. I tried the follow and it did not work:
>
>  CLASS
>    MAXSCALEDENOM 100000000
>    MINSCALEDENOM  50000000
>    TEXT ('[STUSPS]')
>    STYLE
>      COLOR "#f2efe9"
>    END
>    LEADER
>      MAXDISTANCE 30
>      GRIDSTEP 5
>      STYLE
>        GEOMTRANSFORM 'end' # also tried 'start'
>        SYMBOL 'circle-filled'
>        SIZE 6.5  # make it big to besure its not hidden
>        COLOR "#000000"
>      END
>      STYLE
>        COLOR "#000000"
>        WIDTH 0.5
>      END
>    END
>    LABEL
>      COLOR "#675844"
>      FONT "arial"
>      TYPE TRUETYPE
>      SIZE 6
>      POSITION CC
>      PARTIALS FALSE
>      BUFFER 1
>      MINDISTANCE 200
>      OUTLINECOLOR "#ffffff"
>      OUTLINEWIDTH 1
>    END
>  END
>
> My goal was to put a symbol at the start or end of the leader, but as you
> indicated it is not supported yet. I also tried to change the WIDTH on the
> leader style to no success.

That would be a rather easy feature to add, especially if no bindings
are required.

>
> 2. Label positioning.
>
> 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.

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)
>
> 3. For others that are trying to use this, I can recommend putting an
> outlinecolor on your label to minimize interference with the leader line.
Another enhancement might be to clip the leader line by the shapeObj
representing the label bounds.

>
> All in all, it is a great job. I'll continue to work with it. I know you
> have a lot on your plate trying to freeze 6.2, but keep please keep these
> suggestions in mind as you tackle related issues.
>
> Let me know if you want tickets for any of these.
All these might be better off in tickets so they don't get lost. They
most probably won't go in for 6.2, but could be aimed for in 6.4 with
funding.

Cheers,
thomas

>
> Thank you for all your effort and help with this new feature.
>
> Best regards,
>  -Steve W
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev