LABEL: ANGLE FOLLOW + Large number of labels = Hangup

[lithiumdex]

For example;

Rendering of one zoom level might take 20 seconds The next one in, the only change being the number of labels, it would go indefinatley (until killed by apache, 5+ mins) Switching ANGLE FOLLOW to ANGLE AUTO this zoom level would render in roughly the same time as the one before it (i.e. 20-30 seconds)

Using PHP Mapscript/kaMap /w MapServer 5.0.3, on a server running Centos 5.

[dmorissette]

I doubt this is specific to PHP MapScript?, that's just the way labelling works: automated label positioning can take time with too many labels, there is not much we can do about this unless someone has time to invest in fine tuning the algorithms.

Christopher, if you believe it's not just taking time but it actually goes into an infinite loop then please submit a complete testcase to reproduce (mapfile + testdata).

Adding Steve and Thomas to CC... what do you think?

[lithiumdex]

The hangup has occurred in places with less potential labels than places where it didn't hang up.

I.e. (Hang: Halifax NS, none: Philadelphia PA, hang: Washington DC)

Unfortunately I am not allowed to release any part of the Map file, or allow outsiders to view the map as of now.

[dmorissette]

Hard/impossible to do anything without a way to reproduce...

[sdlime]

Agreed on the test case. BTW is this using GD or AGG for rendering? Are the results consistent between them?

Steve

[lithiumdex]

I'm using AGG rendering, a GD version of this did not produce the error, however the road network data is different.

[nmandery]

exampledata for reproducing the bug

[nmandery]

It seems to me i got the same bug as described by lithiumdex, although there are not so much labels in my case. I attached an archive (bugroads.tar.gz) with all the neccesariy data to reproduce the bug. The bug seems to be dependant of the scale, at least it only occurs one some mapscales - see the request_url.txt file for a request which causes the error.

I am using version 5.2 of Mapserver.

Nico

[nmandery]

Forgot on thing: The ANGLE Follow statement which causes the trouble is in line 88 of the mapfile.

Nico

[nmandery]

I think i found the issue. The problem seems to be caused in the msDrawTextLineAGG funtion of mapagg.c. Instead of coordinates for drawing a glyph NaN-values are occasionaly returned. I attached a quick patch for the SVN-version om mapserver to abort rendering of a label in such a case, but this is only a temporary workaround. Maybe someone with more experience can look further into this issue.

Nico

[nmandery]

Quick workaround foor #2695

[tbonfort]

that one was a pain to debug !

nmandery: your shapefile has some features where there were duplicate points. we usually account for this, except if the last point was a duplicate. the duplicate points were causing the angle follow placement code to produce NaNs?, thus the problem.

fixed in trunk in r7956 fixed in 5.2 branch in r7957