When using the GeoServer "pre-generalized features" module, or eventually when querying an SLD-enabled LayerGroup (StyleGroup) that returns scale-appropriate features via both the GetMap and GetFeatureInfo interfaces, it's a necessity to clip the returned feature to the bbox that is provided in the request.
The reason is simple: when zoomed way in (large scale) on a very large feature (e.g. Canada's North West Territories, or Nunavut), returning the entire feature in response to a query is prohibitively slow due to the high resolution of data. In such a case the feature should be clipped on the server side to the bbox that is provided by the query , so that the feature response is a) of manageable size, and b) relevant the the request.
This is already done by the WMS GetMap processing in GeoServer >= 2.26, however we are planning to make it a reality in the WMS GetFeatureInfo processing in an upcoming release.
This raises another issue, however, which is: how can the client establish the bounds of the feature, which underlies the "Zoom to here" link in feature popups, if only a clipped portion of the feature is available to establish the bounds to which to zoom.
The issue is compounded in the WMTS GetFeatureInfo interface, in which only the bounds of the tile itself are declared by the query (implicitly, at least via the tile's {z}/{x}/{y} parameters - the tile bounds can be calculated from the tile coordinates). Returning the tile bounds as representing the feature geometry would look odd and not be visually meaningful (square feature), nor would it be practically useful for zooming or any other function. It might be possible to put WMTS GetFeatureInfo on the same footing as WMS GetFeatureInfo by adding a MapML format-specific bbox parameter to the query link which would return the clipped feature. That puts WMTS GetFeatureInfo on the same foot as WMS: a query returns a partial feature that is not much use for establishing the actual bounds of the feature, nor useful as a basis for the "Zoom to here" function.
A solution might be to add an optional bbox attribute to the \ that would set the bounds of the feature without having to a) go through all the feature's coordinates and b) be sometimes available when the entire feature was not present inside the map for calculation. The bbox attribute would be expected to be xmin,ymin,xmax,ymax in the same coordinate system as the coordinates of the feature.
When using the GeoServer "pre-generalized features" module, or eventually when querying an SLD-enabled LayerGroup (StyleGroup) that returns scale-appropriate features via both the GetMap and GetFeatureInfo interfaces, it's a necessity to clip the returned feature to the bbox that is provided in the request.
The reason is simple: when zoomed way in (large scale) on a very large feature (e.g. Canada's North West Territories, or Nunavut), returning the entire feature in response to a query is prohibitively slow due to the high resolution of data. In such a case the feature should be clipped on the server side to the bbox that is provided by the query , so that the feature response is a) of manageable size, and b) relevant the the request.
This is already done by the WMS GetMap processing in GeoServer >= 2.26, however we are planning to make it a reality in the WMS GetFeatureInfo processing in an upcoming release.
This raises another issue, however, which is: how can the client establish the bounds of the feature, which underlies the "Zoom to here" link in feature popups, if only a clipped portion of the feature is available to establish the bounds to which to zoom.
The issue is compounded in the WMTS GetFeatureInfo interface, in which only the bounds of the tile itself are declared by the query (implicitly, at least via the tile's {z}/{x}/{y} parameters - the tile bounds can be calculated from the tile coordinates). Returning the tile bounds as representing the feature geometry would look odd and not be visually meaningful (square feature), nor would it be practically useful for zooming or any other function. It might be possible to put WMTS GetFeatureInfo on the same footing as WMS GetFeatureInfo by adding a MapML format-specific
bboxparameter to the query link which would return the clipped feature. That puts WMTS GetFeatureInfo on the same foot as WMS: a query returns a partial feature that is not much use for establishing the actual bounds of the feature, nor useful as a basis for the "Zoom to here" function.A solution might be to add an optional that would set the bounds of the feature without having to a) go through all the feature's coordinates and b) be sometimes available when the entire feature was not present inside the map for calculation. The
bboxattribute to the \bboxattribute would be expected to be xmin,ymin,xmax,ymax in the same coordinate system as the coordinates of the feature.