RFC-60: Add ability to skip ANGLE FOLLOW labels with too much character overlap

[dmorissette]

As part of the FOSS4G 2010 Benchmarking exercise, one of the layers to render was contours with labels, and we've seen that MapServer did a poor job of labeling some contours with sharp curves using ANGLE FOLLOW, resulting in overlapping characters and unreadable labels.

OTOH, we found that GeoServer for instance didn't have this type of problematic labels because it simply detected the overlapping chars and skipped those labels, leaving room for other/better labels to fall around the same spot... leading to a better looking map.

This ticket is about implementing a similar mechanism to detect overlapping characters in ANGLE FOLLOW chars and skipping those labels.

Note that ticket #2221 started discussing this option as part of a wider discussion of curved label problems, but since #2221 aims to address a different issue using b-spline to smooth the lines an get less erratic char positioning along valid curved labels, I decided that the ability to skip invalid labels with overlapping chars along very sharp curves should get its own ticket (and eventually RFC).

[dmorissette]

Contour labels produced by MapServer 5.6

[dmorissette]

Conour map produced by GeoServer

[dmorissette]

Here is the WMS request used for mapserver-wms.png for future reference (a similar request was used by GeoServer):

​http://12.189.158.78:8081/cgi-bin/mapserv_label?MAP=/benchmarking/mapserver/spain-shapefiles.map&LAYERS=vector_benchmarking_2010&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=2.0887561798092,41.693440914151,2.1016307830806,41.706315517423&WIDTH=600&HEIGHT=600

[jmckenna]

This is a good description of the current issue. Do we need an RFC for rejecting problem labels? (just asking, I am not questioning the process...I'll help out either way)

[aboudreault]

Well, yes, I suppose... since we plan to add a new mapfile keyword (new feature), MAXOVERLAPANGLE, which allows the user to configure the angle used in the label placement to bails labels.

[sdlime]

What's the new parameter specify? Why wouldn't we just want to drop labels with overlap unconditionally? I guess I don't know what there is to tune from a users perspective...

Steve

[dmorissette]

Because dropping labels means...err... dropping labels, and some users may prefer overlapping labels to no label at all... that was our thinking anyway. If we introduce this feature unconditionally in 6.0, I can already hear the comments on the users and dev list that we caused a regression.

What we were thinking was to leave the default behavior as it is now (i.e. do not reject anything), and add a MAXOVERLAPANGLE (better keyword name welcome) whose value is the max angle between two consecutive chars before the label is dropped. In Alan's tests, he found that 22.5 degrees seems like a good default value, so we would recommend in the docs that users use 22.5 as default to get started when they enable the feature, and tune it up or down depending on the type of data and their tolerance to bad labels.

[aboudreault]

Exact. But in a few other tests, I had to increase that angle value to get the result I wanted. So, there are no absolute values for this feature.

[sdlime]

My 2 cents is that nobody *wants* crappy labels so why give them the option to keep them. I think users tolerate them now and would be happy if they weren't visible. Plus, I hate adding keywords... ;-)

How is overlap being determined? Just by angle or are you testing character bboxes?

Steve

[aboudreault]

I understand that nobody wants crappy labels.... but mapserver is not able to determine which one is a crappy label. The overlapping is determined only with that angle value..... since we couldn't do it using the bboxes. The bboxes just always overlap.This will be mentionned in the RFC with an image as example.

[dmorissette]

How'bout we enable this by default with a default value of 22.5 degrees, and add a keyword (sorry Steve) for those who want to disable or tweak it?

[aboudreault]

In my opinion... it's not a good idea. Since it's not an absolute value... this could just *really* fails on some maps. This is not a *brillant* test. Why would we force the user to get something worst (in a few cases), with less labels. Let the user with what he already has... which was probably ok if he still uses mapserver :P... and just give them the possibility to get something better.

[dmorissette]

mapserver-label-with-fix.png - MapServer map in which labels with char overlap > 22.5 degrees are skipped

[sdlime]

I guess I'd prefer to have this discussion in the context of the RFC. With vast data sets and display scales being so common I think it's going to be hard to control in practice.

I wonder if AGG's curved label support could somehow be leveraged now that it's a required component. Some of the splined text support demos are spectacular. Visit ​http://www.antigrain.com/demo/index.html and look at the trans curve examples.

Steve

[dmorissette]

Contour map using MAXOVERLAPANGLE 22.5, REPEATDISTANCE 400 and MINDISTANCE 100

[tbonfort]

Replying to sdlime:

I wonder if AGG's curved label support could somehow be leveraged now that it's a required component. Some of the splined text support demos are spectacular. Visit ​http://www.antigrain.com/demo/index.html and look at the trans curve examples.

Can't really be used as it needs a smooth curve to obtain correct results (see the distortion in characters on the sharp turns on the example image). In the mapserver case where we don't have curves but a succession of line segments, the output is illegible.

[dmorissette]

BBoxes of individual chars in contour labels

[dmorissette]

FYI, RFC-60 created and open for discussion on the -dev list:

http://mapserver.org/development/rfc/ms-rfc-60.html

[dmorissette]

Here is another example showing MAXOVERLAPANGLE 22.5 on a street map

[aboudreault]

Fixed and committed in r10525. Changing component to documentation.

[sdlime]

Is this ticket closed? There are a number of other tickets #2221 and #2020 that are related. Would like to get them all off the books.

Steve

[dmorissette]

The implementation is done. The ticket has been reassigned and is left open for docs. (Or should we create another ticket for docs, Jeff?)

[havatv]

As far as I can see, this has been documented in mapfile-> label. It does not seem to have been documented for mapscript, but a lot is missing there anyway. I close this ticket, and have created a separate documentation ticket (#3984) for mapscript.