[mapserver-dev] Heads Up, RFC81 committed

[Stephen Woodbridge]

Hi Thomas,

Here are a couple of specific cases that I can not account for based on 
your explanations So take a look if you are interested. The overall 
results is awesome so I'm not too worried about these:

http://imaptools.com:8080/demo/tiger2011.html?zoom=14&lat=28.51262&lon=-81.46021&layers=0B0

Notice Soho St in the bottom left and toggle between 6.0.2 and trunk.

http://imaptools.com:8080/demo/tiger2011.html?zoom=14&lat=28.51416&lon=-81.47892&layers=B00

Notice Blakely Dr in lower left and toggle. I think this one is fine and 
related to overlaping character changes.

http://imaptools.com:8080/demo/tiger2011.html?zoom=8&lat=28.51466&lon=-81.4796&layers=B00

Ok this one looks like polygon labels on 6.0.2 are getting placed at CC 
first and LC first on trunk. Notice Ferndale  in the center over the 
lake. And Patrick AFB in the lower right. I'm somewhat familiar with 
this area and the labels on 6.0.2 are much better placed than trunk, but 
this might just be the cascade of bboxes shifting.

Oh, interesting all the shifting is toward the center of the image. I 
bet that is caused by not using the MS_INT rounding. Regardless, its 
looks great. Now to convert my Annotation layers to label styles and see 
how that helps performance and impacts styling.

Thanks,
   -Steve W

On 3/10/2012 5:44 AM, thomas bonfort wrote:
> Hi Steve,
> thanks for the feedback
>
> On Fri, Mar 9, 2012 at 22:14, Stephen Woodbridge
> <woodbri at swoodbridge.com>  wrote:
>> Hi Thomas,
>>
>> Wow! nice job. I just finished building trunk and I thought you would like
>> to look at 6.0.2 vs 6.1-dev
>>
>> http://imaptools.com:8080/demo/tiger2011.html?zoom=15&lat=41.86762&lon=-87.66218&layers=B00
>>
>> Open the layer switcher and you can toggle between the two versions. Zoom
>> out and compare it at various versions.
>>
>> This is using the same mapfile on both maps at the moment. I few
>> observations and comments, none of which is highly problematic, ie: does not
>> need to be fixed. But the differences might mean something more to you.
>>
>> 1. Annotation layer text seems to be moved closer to the symbol. Note: all
>> labels with symbols are currently using annotation layers. I will look into
>> converting the mapfile to use symbol styles.
> I had already noticed the issue, which does not seem to happen with
> point layers and label styles. After investigation I believe I have
> cornered the problem and will fix soon.
>
>>
>> 2. I get a slight shift of labels in part due to 1. I also noticed that some
>> road labels change, this might be because of the shift in bboxes for the
>> other labels, but I'm not sure tht is always the case.
> A slight shift in labels is expected as we are not doing MS_NINT
> integer roundings on label bounding boxes and anchor points anymore.
> As the label placement is an iterative process, a slight shift on a
> given label can chain down to the following ones and result in a very
> different output. So for the time being I will "blame" these
> differences on this slight shifting, but can investigate further if we
> notice that another issue is at stake.
>
>>
>> 3. I have seen at least one case that look like the order or priority of the
>> labels was not the same. I will have to find that again and see if I can
>> verify that is the case.
> I would need more info to speak up on this. In theory the label
> priority code has not been touched.
>
>>
>> 4. I have seen a couple of cases where text following a road disappeared in
>> 6.1-dev, this might be because of interlabel character overlaps being
>> different.
> I have also seen some differences between 6.0 and trunk, in places
> that I believe are not affected by labelcache collision detection. I
> believe these differences are due to some bug corrections in the
> labelpath computation code with respect to the max overlap angle.
>
>>
>> As I said, nothing critical at the moment, unless one of these hints at a
>> bug you might want to look at. I'll work on converting the mapfile to use
>> label styles and then post an updated link with a new layer in it.
>>
>> Thanks for all your effort in this.
>
> Welcome! Along with Steve's refactoring in rfc77 I think we have gone
> a good step in the direction of cleaning up some spaghetti code in the
> rendering functions, which will ease maintainability and future
> enhancements. The removal of annotation layers is the next one.
>
>>
>> -Steve W
>>
>>
>> On 3/9/2012 9:45 AM, thomas bonfort wrote:
>>>
>>> Hi guys,
>>>
>>> RFC81 with its offset labels with leader lines has just been committed
>>> to trunk. Along with the new functionality, there has been some
>>> significant refactoring to the code in mapdraw.c (notably the shape
>>> and labelcache drawing) to make it more readable and cut down on
>>> unnecessary computation and memory allocations. Along with the work in
>>> RFC77 on multiple labels, this implies that there are some subtle
>>> rendering differences in label placement compared to 6.0, and although
>>> I have msautotested the new code and tried to extensively test all
>>> use-cases, there might be some more significant issues. Please bring
>>> those up on this list if you consider any change of behavior as a bug.
>>>
>>> The second impact of RFCs 77 and 81 is that we are seriously
>>> considering deprecating ANNOTATION layers in 6.2, with a planned
>>> removal in 7.0. We believe that all the functionality they implement
>>> can now be achieved with label styles, and the removal will allow us
>>> to cut down on code complexity in the drawing and labelcache phases.
>>> The new multi-label support of RFC77 and RFC81 will not work on
>>> annotation layers, and will produce an error message.
>>>
>>> With the inspire code committed, I believe we can start getting ready
>>> for the 6.2 release phase ?
>>>
>>> cheers,
>>> thomas
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>>