Details
Improvement
Closed
Major
Description
The rendering buffer is a vendor parameter used for GetMap and GetFeatureInfo.
It takes into account that the features are drawn with a style that makes them larger/bigger, in GetMap that will have the effect of increasing the queried area to catch the features that sit outside of it but whose symbolizer is big enough to get into it, and for GetFeatureInfo, it represents the search area
Normally the buffer is computed automatically using a static analysis of the style, but that won't work if the style has attribute dependencies of any kind (stroke width stored in an attribute, dynamic symbolizers, etc).
For those cases a &buffer=xxx param should be specified, but not all clients allow to setup that param in the request.
Allow the admin to specify a buffer hint on a per layer basis instead
Issue Links
- depends upon
-
GEOT-3236
Bad interaction between advanced projection handling and rendering buffer handling
-
Here is a patch that addresses the issue.
It allows to configure a new rendering buffer parameter in the GUI, and takes care of it in GetMap and GetFeatureInfo methods.
To allow for testing and avoid too much code duplication some code had to be moved around, that makes the patch look bigger than it is.
Btw, I decided to store the buffer in the layer metadata, since it's a publishing concern. I could also have stored it as a first class property.
Also noticed some publishing properties such as http caching are actually stored in the feature type info metadata map... makes no sense to me, but the damage is done, 2.0.x shipped with that....
Justin, opinions?