[QGIS-Developer] QGIS server issue: bounding box issues
Jonathan Moules
jonathan-lists at lightpear.com
Mon May 13 00:49:10 PDT 2019
Hi Andreas,
> I wonder if WMS clients should use bounding boxes at all
Unfortunately they solve a real problem and it'd be worse without them:
Where is the data? This isn't a problem for global datasets but:
* Over 365,000 layers (of 1.2mil) have a bounding box of less than 1,000
square km. That's a tiny area 31km on a side. Users simply won't be able
to find that from a global view.
* A lot of WMS layers have scale thresholds for rendering and won't show
anything if too far zoomed out. Assuming these are done competently then
*hopefully* the data should render when you're viewing the layer extent
on any reasonably sized screen.
> Or they should only use the top level bounding box of the whole service.
Even less of an option I'm afraid. I don't believe there's any provision
for such a service level bounding box in the WMS Spec (couldn't find one
just now on a quick glance).
I think wrong BBOXes simply falls under "just another way for a service
administrator to make a service bad/useless" (and trust me, there seem
to be a lot of ways to do that!)
Cheers,
Jonathan
On 2019-05-13 07:51, Andreas Neumann wrote:
>
> Hi Jonathan,
>
> Thanks for your feedback.
>
> Seems to me that bounding boxes are a big mess. Yet they are used to
> hide data away outside of the bounding box. That behaviour seems
> really dangerous to me. People rely on the WMS that they show "all"
> data, but if so many bounding boxes are out of date in the wild this
> means that clients can't rely on them really. And neither can servers
> (and filter away data).
>
> Also, it seems to me that OGC specifications doesn't handle edge cases
> well, such as layers with only a single point.
>
> Given the fact that many layer bounding boxes are just plain wrong, I
> wonder if WMS clients should use bounding boxes at all, they seem to
> be really, really unreliable. Or they should only use the top level
> bounding box of the whole service. Many open questions ...
>
> Andreas
>
> On 2019-05-13 02:27, Jonathan Moules 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 <mailto:eric.lemoine at oslandia.com>> wrote:
>>>
>>> On Thu, 9 May 2019 11:28:00 +0200
>>> Andreas Neumann <a.neumann at carto.net
>>> <mailto: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 <http://www.itopen.it>
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org <mailto: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190513/ba4771b1/attachment-0001.html>
More information about the QGIS-Developer
mailing list