[mapserver-dev] LABEL BUFFER behavior changes

[Tamas Szekeres]

I think this change is related to this commit:

https://github.com/mapserver/mapserver/commit/18b51c4a36e6447793a48744f64adcb7c20585e2

Best regards,

Tamas


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>