Jonathan, thank you for the detailed explanation.
I think that the proposed fix it is the one proposed by Renè and involves a patch to QGIS desktop to allow storing of arbitrary bboxes per-layer (default to feature's bbox) and a patch to the server component to read those bboxes and advertise them in GetCapabilities response. On Mon, May 13, 2019 at 2:28 AM Jonathan Moules < jonathan-li...@lightpear.com> wrote: > Hi list, > > Unless GeoServer has changed it of late, the way they do BBOX definition > is: > > * Layer BBOXes are defined at layer creation time. > > * Layer BBOXes are entered manually, though there is a button to > automatically calculate it from the data extent which automatically fills > in the manual boxes - the values can then be manually tweaked as desired. > > * Layer BBOXes are not automatically calculated at use-time. > > ---- > > It looks like GeoServer also turns a single point into a BBOX of a single > point: > https://gis.stackexchange.com/questions/113166/the-request-bounding-box-has-zero-area > > ---- > > De-factor treatment of bounding boxes: Layers do often have BBOXes that do > not actually represent the data. > > In fact, of the 1.2million WMS, WFS, WCS, WMTS layers in my database, > nearly 55,000 don't even have BBOXes (or have not-valid-wgs84 coordinates)! > > There's no easy way to check how many of the rest are declaring the > correct BBOX, but experience suggests a lot don't. > > ---- > > De jure usage: I've just taken a quick glance at the standards (WMS 1.3, > WFS 2, WCS 2) and they standards themselves don't seem to address the issue > of keeping the bboxes contemporary at all or even exactly what they're for. > The closest I could find as to specifying the exact purpose of the bboxes > is in the WFS 2 spec: > > "The ows:WGS84BoundingBox element may be used to indicate the edges of an > enclosing rectangle in decimal > degrees of latitude and longitude in WGS84. Its purpose is to facilitate > geographic searches by indicating where > instances of the particular feature type exist. Since multiple > ows:WGS84BoundingBox elements may be > specified, a WFS may indicate where various clusters of data exist. This > knowledge aids client applications by > letting them know where they should query in order to have a high > probability of finding feature data." > > And this is mildly telling from the WMS 1.3 spec: > > "There is no provision for describing disjoint bounding boxes. For > example, consider a dataset which covers two > areas separated by some distance. The server cannot provide two separate > bounding boxes in the same Layer using the > same CRS to separately describe those areas. To handle this type of > situation, the server may either define a single larger > bounding box which encloses both areas, or may define two separate Layers > that each have distinct Name and BoundingBox > values." > > So it doesn't look like handling changing extents is something the spec > writers have specified. > > And I can assure you, many servers don't have valid BBOXes defined. In fact > > Cheers, > > Jonathan > > > On 2019-05-09 15:37, Alessandro Pasotti wrote: > > > On Thu, May 9, 2019 at 4:16 PM Eric Lemoine <eric.lemo...@oslandia.com> > wrote: > >> On Thu, 9 May 2019 11:28:00 +0200 >> Andreas Neumann <a.neum...@carto.net> wrote: >> >> > Hi QGIS (server) devs, >> >> Hi Andreas >> >> > >> > We came across issues around calculating bounding boxes in QGIS >> > server. >> > >> > 1. Layers with only one point feature: >> > >> > If a layer contains only one single point feature, QGIS server >> > calculates a bounding box where the minx equals maxx and miny equals >> > maxy, so resulting in a bounding box without a width and height. >> > Sounds logical to QGIS server developers, >> >> >> Yes. The BBOX of a point has minx=maxx and miny=maxy. Even PostGIS says >> so :) >> >> >> > but combined with the fact >> > that QGIS server doesn't take into account rendered symbol sizes >> > (another issue we have, see issue nr 2), it means that no WMS client >> > will ever see this one single symbol rendered, which can't be the >> > solution here ... >> >> >> If the GetMap request's BBOX param is set to the layer extent (the >> BBOX with no dimension here) then it makes sense that there's nothing >> rendered in the resulting image. If the GetMap request's BBOX param is >> set to a BBOX that contains the layer extent then the point should be >> rendered in the resulting image. >> >> So to me this is a client issue, not a QGIS Server issue. >> >> >> > 2. Layer bounding boxes do not take into account rendered symbol >> > sizes: >> > >> > Please have a look at >> > http://www.carto.net/neumann/temp/qgis_server_bounding_box_issue.png >> > - The green rectangle and the green arrows are not part of the QGIS >> > server rendering, but they are added as an annotation to the rendered >> > QGIS server graphics, to highlight the issues. >> >> >> What software do you use on the client side? Does the green >> rectangle correspond to the BBOX requested by the client? And does the >> requested BBOX equal the layer extent in this case? Or does it contain >> the layer extent? >> >> I may be wrong but I understand that the requested BBOX (the green >> rectangle) is the layer extent. And in that case it makes sense that >> the symbols are cut for points that are closed to the boundaries. Again >> it's a client issue. >> >> >> > Here we have the issue that QGIS server only uses the "raw" geometry >> > of point symbols without taking into account rendered symbol sizes. >> > Now, I do understand that calculating symbol sizes is scale dependent >> > and there is no single solution to that, but again, I think the >> > current behavior of QGIS server (simply cutting off symbols at layer >> > bounding boxes) is not a good and nice behavior. At least, I think >> > the author of the WMS service should have a chance to define an extra >> > margin to be added to the bounding boxes of the raw geometries of the >> > point layer, either as a "per project" or "per layer" QGIS server >> > configuration. >> > >> > @Andrea: I wonder what Geoserver does in such cases? >> > >> > Any thoughts how to solve these issues? The current behavior of QGIS >> > server is not satisfactory to me, for both cases. >> >> I'd like to better understand the issues that you're seeing but from >> what I currently understand the behavior of QGIS Server is correct. >> Happy to be proven otherwise :) >> >> Cheers, >> > > Hi Èric, > > I agree with you that QGIS Server does the right thing here, I think that > the main question is: > > 1. is the WMS GetCapabilities layer's BoundingBox meant to be the features > BBOX or can it be larger than that? > 2. if the latter is true, we need a way to tell QGIS Server that he needs > to advertise a BoundingBox in GetCapabilities which is not the layer's BBOX > stored in the QGIS project but it's a different (probably larger) one. > > all the rest will follow, because the client will get a larger BBOX from > GetCapabilities and it will request a larger image that has enough buffer > for the symbols. > > Note that I checked mapserver and it behaves by default exactly like QGIS > Server does (I didn't check the single point but the symbols are cut-off at > the layer's bbox in general), except that mapserver allows you to override > the layer extent per-layer. > > IMO the fix is in the client, either by allowing to override the layer > extent advertised by the server and to store it in the project itself (this > may require some work in the server side too in order to handle the > override) or by setting an option in the WMS provider that will always > request the canvas extent. > > Cheers > > -- > Alessandro Pasotti > w3: www.itopen.it > > _______________________________________________ > QGIS-Developer mailing listqgis-develo...@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Alessandro Pasotti w3: www.itopen.it
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer