maxoverlapangle: does not work if value is set to 0

[assefa]

It is specified in te RFC that setting the value to 0 should result into having the behavior as in 5.x but there seems to be an issue with that. I will attach a patch

[assefa]

Alan,

if you get a chance can you check the patch?

I also realizes that the maxoverlapangle is not part of the migration guide. I think adding there make sense since the default behavior can change the map.

[tbonfort]

There was already a test in place in previous versions that suppressed labels if they overlapped by more than 0.4*MS_PI, see ​http://trac.osgeo.org/mapserver/browser/branches/branch-5-6/mapserver/mapprimitive.c#L1863 .

I do not think your patch should be applied, aside from the 2nd chunk. There's a typo in the 3rd chunk also: maxoverlapangle will always be > 0, so there's no need to test for it.

are you having an issue that didn't occur with 5.6 ?

[assefa]

So lets apply the 2nd part just the test if(label->maxoverlapangle >=0) . There is definitively an issue with values set to 0. As I mentioned It is specified in the rfc that 0 will keep things as is. Actually in our case, our maps are with 5.4 so when upgrading to 6.0, we would like to have the possibility to keep things look the same. Can this be done for the 6.0 release? It seems very localized.

[tbonfort]

+1 for applying the second chunk of the patch only. Assefa, I'll let you do it, but please report back if it actually fixes the issue you where having (it should I hope)

[assefa]

Thanks. It does fix the issue with a test case, where putting the value to 0 did not work as expected. I have added Daniel in cc to see if committing make sense now. There is also #3855 that I want to apply before the release. But I would wait if that push the release.

[tbonfort]

I think that this one can be committed now. it's a bug regarding the maxoverlap rfc, and has no backwards compatibility issues as it concerns a feature that was introduced for 6.0.

[assefa]

committed in r11630. documentation committed in r11631.

[assefa]

To resume this from the logs on IRC:

• the maxoverlapangle = 0.4 * MS_PI; is actually correct
• I have tested the patch against a sharp angle data and the setting to 0 works back to the pre-6.0 value (which ends up being 72 and not 22.5 as I initially thought)
• I have attached the patch for that

But I run msautotest on renderes/line_label_follow.map and tests did not pass. I tested this same map with rc1 (before fixes related to this bug), and It still fails for me. Does this test works for someone else? I want to make sure that the problem is with the test suite and not with the fixes.

[tbonfort]

Assefa,

I can confirm the problem is with the test suite. Unsurprisingly, the 22.5 value for maxoverlap is not a silver bullet, and does discard labels that were perfectly valid. Until we come up with a better solution, we'll have to live with it.

[assefa]

I can "fix" the test suite. Playing a bit with it, if I set the maxoverlapangle to 30, I get an image comparable to what was initially in the expected result set. Let me know on this and I can commit the mapfile and the new result sets.

[tbonfort]

I'm fine with setting maxoverlap to 30 to get it back to the previous state. thanks for taking this on.

[assefa]

ok committed in r11636 in trunk

r11637 for the doc

r11638 for the test suite.

Thanks.

[dmorissette]

Added a note about this to MIGRATION_GUIDE.TXT in r11644.