[mapserver-dev] New Label Offset code

[Stephen Woodbridge]

Thomas,

I have created tickets #4240, #4241, #4242, and #4243 to cover these issues.

Thank you for your thoughts and comments on them.

-Steve W

On 3/13/2012 10:31 AM, thomas bonfort wrote:
> 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