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.lemo...@oslandia.com <mailto:eric.lemo...@oslandia.com>> wrote:
On Thu, 9 May 2019 11:28:00 +0200
Andreas Neumann <a.neum...@carto.net
<mailto: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 <http://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
_______________________________________________
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@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
