[Mapserver-dev] Labeling Question

[woodbri at swoodbridge.com]

Steve, Daniel, et al,

It is really great that you guys implement things faster than I can 
think of them :), you guys are what makes this product so great! 

Also this is a great explanation of how it currently works, and I 
didn't know you stepped through the labelcache in reverse order - I 
now need to change all my mapfiles :) 

Thanks,
  -Steve W.

On 3 Sep 2003 at 12:33, Steve Lime wrote:

> 
> > Hi all,
> 
> > I have been thinking about labelling and have a question about
> > mapserver's strategy or lack there of :)
> 
> Oh, there's a strategy, but it has certainly evolved over time...
> 
> > It seems to me that the when constructing a mapfile that the layers
> > are put down like polygon areas, then minor line art, then major
> > line
> 
> > art, then point objects BUT when labelling the map you want your
> > labels to be generated in the reverse priority ie: label points
> > first, then major line art, them minor line art, then polygons, etc.
> 
> Yup, and labeling steps through the labelcache in reverse order.
> 
> > So in the mapfile you can either label objects when you lay them
> > down
> 
> > or you can take a second pass through all your layers to change the
> > order of labelling. The label as you go is faster but your labels
> > are
> 
> > prioritized backwards or you have to scan your files twice. An
> > lastly, labels are added to the cache in the same basic order as
> > they
> 
> > are found in the data sets which may or may not make sense.
> 
> There are actually 3 types of labeling. As you go, the normal
> labelcache
> and special postlabeling labeling. Typically the last option is used
> for things like placing copyright statements  not for real map
> elements. There are instances when you'd like a layer drawn early on
> in the map to have high priority labels and at the moment you have to
> process the layer twice in that case: once as normal (to draw the
> features) and a second time as an annotation layer. A pain in the ass
> but it works and gives you lots of control.
> 
> > Assuming that I got this right so far ... probably a big wrong
> > assumption on my part :)
> 
> > Wouldn't is make more sense to construct a list of potential labels
> > and then load the list backwards into the label cache to deal with
> > collisions. This would cost a little more in memory, but I think it
> > would faster and and cutdown on the number of layers and give better
> 
> > results for probably 90+% of the cases. You could still have 
> > ANNOTATION layers for more control or set up other additional 
> > strategies for prioritizing important labels.
> 
> This is how it is done. Labels are processed in the reverse order of
> how they were placed in the cache. Collision avoidance in then done
> against those already rendered. In addition, for POINT layers care is
> taken not to cover up points being labeled already on the map. The
> label cache not caches labels but feature locations (what's the point
> of labeling something that's covered up by another label).
> 
> > A related idea would be to be able to give labels attributes like
> > LEVEL=n and FORCE=0|1 these would have the effect of allowing you to
> 
> > set the force labels on on a label by label or expression and level
> > would allow you to class labels into layers the get added to the
> > cache based on their LEVELs. 
> 
> This is already on the drawing board. Basically the idea is to set a
> label priority. This would avoid the scenario I mentioned earlier when
> a piece of data would have to be drawn twice to control labeling. In
> practice the label cache would have to be split into n caches with
> labels added to the right segment based on priority. I've thought
> about just storing priority as part of the labelObj, but looping
> through the entire cache mutliple times looking for a certain priority
> level would be a significant performance hit.
> 
> > For example, I would like to label polygons with a muted color in
> > the
> 
> > background and force those labels on, but I don't want them to bump
> > other labels out of the cache. So I might say
> >   LEVEL=0
> >   FORCE=1
> >   CACHE=0
> > which would cause these labels to be drawn first (LEVEL=0) and they
> > would be forced to be drawn and they would not be added to the cache
> 
> > so other labels might be drawn later over them. I might make
> > LEVEL=-1
> 
> > to mean that the label is drawn at the time the layer is drawn.
> 
> Your idea of attaching meaning to the priority level is a good one and
> should be part of the implementation. That would allow us to ditch the
> LABELCACHE and FORCE parameters. So PRIORITY -1 could be at render
> time, value of 0 could behave like the force option and values 1-9 (or
> whatever) would dictate a relative priority (default of 5).
> 
> > Thoughts, comments, and flames welcome.
> 
> > -Steve W.
> 
> Steve
> 
> Stephen Lime
> Data & Applications Manager
> 
> Minnesota DNR
> 500 Lafayette Road
> St. Paul, MN 55155
> 651-297-2937
>