<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <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">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.<br>
    </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."<br>
    </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."<br>
    </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<br>
    </p>
    <p>Cheers,</p>
    <p>Jonathan</p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2019-05-09 15:37, Alessandro Pasotti
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAL5Q673N8PBpq=z5wbyKfSVWFufJaQ0DWE9O=pbva2-vN8gVNw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr"><br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Thu, May 9, 2019 at 4:16
            PM Eric Lemoine <<a
              href="mailto:eric.lemoine@oslandia.com"
              moz-do-not-send="true">eric.lemoine@oslandia.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">On Thu, 9 May 2019
            11:28:00 +0200<br>
            Andreas Neumann <<a href="mailto:a.neumann@carto.net"
              target="_blank" 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"
              rel="noreferrer" target="_blank" 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,<br>
          </blockquote>
        </div>
        <br>
        <div>Hi Èric,</div>
        <div><br>
        </div>
        <div>I agree with you that QGIS Server does the right thing
          here, I think that the main question is: <br>
        </div>
        <div><br>
        </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.<br>
        </div>
        <div><br>
        </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><br>
        </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><br>
        </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. <br>
        </div>
        <div><br>
        </div>
        <div>Cheers<br>
        </div>
        <div><br>
        </div>
        <div>-- </div>
        <div dir="ltr" class="gmail_signature">Alessandro Pasotti<br>
          w3:   <a href="http://www.itopen.it" target="_blank"
            moz-do-not-send="true">www.itopen.it</a></div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
QGIS-Developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">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">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
    </blockquote>
  </body>
</html>