Establish a mechanism to prioritize labeling.

[sdlime]

At the moment labeling uses a last in first out (LIFO) mechanism to plot labels
on a map. The results in excessive use of ANNOTATION layers to make certain
labels more prominent. It would be desireable to be able to prioritize LABEL
objects for layers in place. One idea might be to create a new layer or class
parameter called LABELPRIORITY with values from 1 (lowest) to 10 (highest). LIFO
would still be used to prioritize labels within a priority class but all the
class 10s would be drawn first, 9's next and so on. Default priority would be
something like a 5. 

I think this could be done by maintaining 10 cache lists in the label cache.
This would add one extra loop to the label cache processors (there are a bunch
of them, a most one for each output driver). The increased overhead would be
offset by not having to process layers multiple times. Cache counters would make
skipping empty priority classes very simple.

Collision avoidance would be the same as always.

Dan mentioned he has some ideas in this area as well so I've added him to the CC
list...

Steve

[dmorissette]

Actually, the LABELPRIORITY was exactly the idea that I had in mind too, except
that I would have accepted any arbitrary number as the priority level instead of
limiting to 10 values. Thinking about it now, limiting to 10 levels of priority
would simplify the implementation and should be enough for most uses.

We should probably run that 10 levels limit by some power users to see what they
think of it.

[sdlime]

Any idea who those power users might be: Bart, Tom K., Steve W., 
somebody at DMSG?

Steve

[dmorissette]

Probably more Steve W and Jeff. Bart and Tom are more into the OGC stuff that
into the fancy map styling. The best might be to email the -dev list, power
users interested in this stuff would be listening there.

[sdlime]

With regards to an arbitrary priority number. Were you thinking of doing
something like a bubble sort on the cache based on that number and then
processing the cache as normal? There might be some benefit there depending on
how fast a cache can be sorted. Just wondering...

Steve

[dmorissette]

No, sorting would be a waste of processing time. I was thinking of maintaining
multiple cache lists, the same way that you suggest, except that instead of
using an array of 10 cache lists (which is probably what you had in mind), I
would have used another mechanism such as a hash table or a chained list to
maintain the list of cache lists (I had not really fully thought about that).

After reading your proposal above I realized that limiting to 10 (or say 20?)
levels would be sufficient for most uses and much more efficient since finding
the right cache list to insert a label would just be a matter of accessing the
array index... instead of searching a chained list or a hash table, or whatever.

So I'm with you on the fixed number of levels. Perhaps let's make it a
configurable parameter in map.h, with a default of 10, and if users find that
they need more, they can always increase the value to 20, or even 50 and
recompile, and the cost of increasing the value would not be that big.

[dmorissette]

Taking this ticket. Preparing RFC 27 for this: ​http://mapserver.gis.umn.edu/development/rfc/ms-rfc-27

(Note that the RFC proposes the addition of a PRIORITY parameter inside the LABEL object instead of LABELPRIORITY inside LAYER/CLASSES as was initially discussed in this bug)