[mapserver-dev] LABEL BUFFER behavior changes

Tamas Szekeres szekerest at gmail.com
Tue Jul 18 02:53:53 PDT 2017

I think this change is related to this commit:


Best regards,


2017-07-18 2:40 GMT+02:00 Lime, Steve D (MNIT) <steve.lime at state.mn.us>:

> Since symbol scale is applied to the label size and corresponding symbols
> it seems reasonable to scale the buffer accordingly. The old computation
> seems insufficient too. Problem is that you can't control the min/max
> buffer size. That could lead to some odd behavior. Could use min/max labels
> sizes to constrain buffer values.
> Did you happen to identify the commit that accompanied the change? There
> were some some broad label refactoring RFCs where this probably happened.
> Steve
> ------------------------------
> *From:* mapserver-dev <mapserver-dev-bounces at lists.osgeo.org> on behalf
> of Tamas Szekeres <szekerest at gmail.com>
> *Sent:* Monday, July 17, 2017 4:17:52 PM
> *To:* mapserver-dev at lists.osgeo.org
> *Subject:* [mapserver-dev] LABEL BUFFER behavior changes
> Hi Devs,
> Was that intentional that the BUFFER paramerer for the label depends on
> SYMBOLSCALE in mapserver 7?
> For mapserver 6.x the buffer has been calculated as follows (in mapdraw.c):
> label_buffer = (labelPtr->buffer*image->resolutionfactor);
> For mapserver 7.x we use this formula:
> textSymbolPtr->label->buffer * textSymbolPtr->scalefactor
> where textSymbolPtr->scalefactor is in fact the layer->scalefactor
> According to the documentation the buffer should be interpreted in pixels
> so the 7.x behaviour is incorrect I think, where the buffer depends on the
> actual scale/zoom.
> I'm not aware of an RFC which would explain this change.
> Let me know if I missed anything in this regard.
> Thanks,
> Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20170718/29709bd6/attachment.html>

More information about the mapserver-dev mailing list