[QGIS-Developer] QGIS server issue: bounding box issues

Sun May 12 23:53:48 PDT 2019

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-lists at 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.lemoine at oslandia.com>
> wrote:
>
>> On Thu, 9 May 2019 11:28:00 +0200
>> Andreas Neumann <a.neumann at 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-Developer at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190513/1abb7312/attachment-0001.html>