<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Andreas,</p>
<p>> I wonder if WMS clients should use bounding boxes at all</p>
<p>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:<br>
</p>
<p>* 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.<br>
</p>
<p>* 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.</p>
<p>> Or they should only use the top level bounding box of the
whole service.</p>
<p>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).<br>
</p>
<p><br>
</p>
<p>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!)</p>
<p>Cheers,</p>
<p>Jonathan<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2019-05-13 07:51, Andreas Neumann
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:aebc06db3f73048622208c49994e4e4d@carto.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Jonathan,</p>
<p>Thanks for your feedback.</p>
<p>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).</p>
<p>Also, it seems to me that OGC specifications doesn't handle
edge cases well, such as layers with only a single point.</p>
<p>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 ...</p>
<p>Andreas</p>
<p id="reply-intro">On 2019-05-13 02:27, Jonathan Moules wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left:
#1010ff 2px solid; margin: 0"><!-- html ignored -->
<!-- head ignored -->
<!-- meta ignored -->
<p>Hi list,</p>
<p>Unless GeoServer has changed it of late, the way they do BBOX
definition is:</p>
<p>* Layer BBOXes are defined at layer creation time.</p>
<p>* 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.</p>
<p>* Layer BBOXes are not automatically calculated at use-time.</p>
<p>----</p>
<p>It looks like GeoServer also turns a single point into a BBOX
of a single point: <a class="moz-txt-link-freetext"
href="https://gis.stackexchange.com/questions/113166/the-request-bounding-box-has-zero-area"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">https://gis.stackexchange.com/questions/113166/the-request-bounding-box-has-zero-area</a></p>
<p>----</p>
<p>De-factor treatment of bounding boxes: Layers do often have
BBOXes that do not actually represent the data.</p>
<p>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)!</p>
<p>There's no easy way to check how many of the rest are
declaring the correct BBOX, but experience suggests a lot
don't.</p>
<p>----</p>
<p>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:</p>
<p>"The ows:WGS84BoundingBox element may be used to indicate the
edges of an enclosing rectangle in decimal<br>
degrees of latitude and longitude in WGS84. Its purpose is to
facilitate geographic searches by indicating where<br>
instances of the particular feature type exist. Since multiple
ows:WGS84BoundingBox elements may be<br>
specified, a WFS may indicate where various clusters of data
exist. This knowledge aids client applications by<br>
letting them know where they should query in order to have a
high probability of finding feature data."</p>
<p>And this is mildly telling from the WMS 1.3 spec:</p>
<p>"There is no provision for describing disjoint bounding
boxes. For example, consider a dataset which covers two<br>
areas separated by some distance. The server cannot provide
two separate bounding boxes in the same Layer using the<br>
same CRS to separately describe those areas. To handle this
type of situation, the server may either define a single
larger<br>
bounding box which encloses both areas, or may define two
separate Layers that each have distinct Name and BoundingBox<br>
values."</p>
<p>So it doesn't look like handling changing extents is
something the spec writers have specified.</p>
<p>And I can assure you, many servers don't have valid BBOXes
defined. In fact</p>
<p>Cheers,</p>
<p>Jonathan</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2019-05-09 15:37, Alessandro
Pasotti wrote:</div>
<blockquote type="cite" style="padding: 0 0.4em; border-left:
#1010ff 2px solid; margin: 0"><!-- meta ignored -->
<div dir="ltr"><br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Thu, May 9, 2019 at
4:16 PM Eric Lemoine <<a
href="mailto:eric.lemoine@oslandia.com"
rel="noreferrer" moz-do-not-send="true">eric.lemoine@oslandia.com</a>>
wrote:</div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid #cccccc; padding-left:
1ex;">On Thu, 9 May 2019 11:28:00 +0200<br>
Andreas Neumann <<a href="mailto:a.neumann@carto.net"
rel="noreferrer" moz-do-not-send="true">a.neumann@carto.net</a>>
wrote:<br>
<br>
> Hi QGIS (server) devs,<br>
<br>
Hi Andreas<br>
<br>
> <br>
> We came across issues around calculating bounding
boxes in QGIS<br>
> server.<br>
> <br>
> 1. Layers with only one point feature:<br>
> <br>
> If a layer contains only one single point feature,
QGIS server <br>
> calculates a bounding box where the minx equals
maxx and miny equals <br>
> maxy, so resulting in a bounding box without a
width and height.<br>
> Sounds logical to QGIS server developers,<br>
<br>
<br>
Yes. The BBOX of a point has minx=maxx and miny=maxy.
Even PostGIS says<br>
so :)<br>
<br>
<br>
> but combined with the fact<br>
> that QGIS server doesn't take into account rendered
symbol sizes<br>
> (another issue we have, see issue nr 2), it means
that no WMS client<br>
> will ever see this one single symbol rendered,
which can't be the<br>
> solution here ...<br>
<br>
<br>
If the GetMap request's BBOX param is set to the layer
extent (the<br>
BBOX with no dimension here) then it makes sense that
there's nothing<br>
rendered in the resulting image. If the GetMap
request's BBOX param is<br>
set to a BBOX that contains the layer extent then the
point should be<br>
rendered in the resulting image.<br>
<br>
So to me this is a client issue, not a QGIS Server
issue.<br>
<br>
<br>
> 2. Layer bounding boxes do not take into account
rendered symbol<br>
> sizes:<br>
> <br>
> Please have a look at <br>
> <a
href="http://www.carto.net/neumann/temp/qgis_server_bounding_box_issue.png"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">http://www.carto.net/neumann/temp/qgis_server_bounding_box_issue.png</a><br>
> - The green rectangle and the green arrows are not
part of the QGIS<br>
> server rendering, but they are added as an
annotation to the rendered<br>
> QGIS server graphics, to highlight the issues.<br>
<br>
<br>
What software do you use on the client side? Does the
green<br>
rectangle correspond to the BBOX requested by the
client? And does the<br>
requested BBOX equal the layer extent in this case? Or
does it contain<br>
the layer extent?<br>
<br>
I may be wrong but I understand that the requested BBOX
(the green<br>
rectangle) is the layer extent. And in that case it
makes sense that<br>
the symbols are cut for points that are closed to the
boundaries. Again<br>
it's a client issue.<br>
<br>
<br>
> Here we have the issue that QGIS server only uses
the "raw" geometry<br>
> of point symbols without taking into account
rendered symbol sizes.<br>
> Now, I do understand that calculating symbol sizes
is scale dependent<br>
> and there is no single solution to that, but again,
I think the<br>
> current behavior of QGIS server (simply cutting off
symbols at layer<br>
> bounding boxes) is not a good and nice behavior. At
least, I think<br>
> the author of the WMS service should have a chance
to define an extra<br>
> margin to be added to the bounding boxes of the raw
geometries of the<br>
> point layer, either as a "per project" or "per
layer" QGIS server<br>
> configuration.<br>
> <br>
> @Andrea: I wonder what Geoserver does in such
cases?<br>
> <br>
> Any thoughts how to solve these issues? The current
behavior of QGIS <br>
> server is not satisfactory to me, for both cases.<br>
<br>
I'd like to better understand the issues that you're
seeing but from<br>
what I currently understand the behavior of QGIS Server
is correct. <br>
Happy to be proven otherwise :)<br>
<br>
Cheers,</blockquote>
</div>
<br>
<div>Hi Èric,</div>
<div> </div>
<div>I agree with you that QGIS Server does the right thing
here, I think that the main question is:</div>
<div> </div>
<div>1. is the WMS GetCapabilities layer's BoundingBox meant
to be the features BBOX or can it be larger than that?</div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Cheers</div>
<div> </div>
<div>--</div>
<div class="gmail_signature" dir="ltr">Alessandro Pasotti<br>
w3: <a href="http://www.itopen.it" target="_blank"
rel="noopener noreferrer" moz-do-not-send="true">www.itopen.it</a></div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre">_______________________________________________
QGIS-Developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:QGIS-Developer@lists.osgeo.org" rel="noreferrer" moz-do-not-send="true">QGIS-Developer@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
<!-- html ignored --><br>
<div class="pre" style="margin: 0; padding: 0; font-family:
monospace">_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org"
rel="noreferrer" moz-do-not-send="true">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a
href="https://lists.osgeo.org/mailman/listinfo/qgis-developer"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a
href="https://lists.osgeo.org/mailman/listinfo/qgis-developer"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div>
</blockquote>
<p><br>
</p>
</blockquote>
</body>
</html>