[mapserver-dev] New Label Offset code

[Stephen Woodbridge]

And add #4244 for  fine grain units support.

On 3/13/2012 2:02 PM, Stephen Woodbridge wrote:
> 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
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev