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

[Jonathan Moules]

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 
mailto:eric.lemo...@oslandia.com>> wrote:


On Thu, 9 May 2019 11:28:00 +0200
Andreas Neumann mailto:a.neum...@carto.net>> wrote:

> Hi QGIS (server) devs,

Hi Andreas

>
> We came across issues around calculating bounding boxes in QGIS
> server.
>
> 1. 

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

[Alessandro Pasotti]

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-li...@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 
> wrote:
>
>> On Thu, 9 May 2019 11:28:00 +0200
>> Andreas Neumann  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 

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

[Andreas Neumann]

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  wrote: 
On Thu, 9 May 2019 11:28:00 +0200
Andreas Neumann  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 

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

[Jonathan Moules]

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 > wrote:


On Thu, 9 May 2019 11:28:00 +0200
Andreas Neumann 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 

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

[Eric Lemoine]

On Thu, 9 May 2019 11:51:25 +0200
René-Luc Dhont  wrote:

> In QGIS Server, the layer extent is used to restrict the rendering to 
> the WMS layer extent.

I don't observe this.  I'd be interested to know where is the QGIS
(Server) code this restriction is implemented.  Thank you.




-- 
Éric Lemoine
Oslandia


pgpi4RQdajRWr.pgp
Description: OpenPGP digital signature
___
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

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

[Alessandro Pasotti]

On Thu, May 9, 2019 at 4:16 PM Eric Lemoine 
wrote:

> On Thu, 9 May 2019 11:28:00 +0200
> Andreas Neumann  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 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

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

[Eric Lemoine]

On Thu, 9 May 2019 11:28:00 +0200
Andreas Neumann  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,


-- 
Éric Lemoine
Oslandia


pgpYckP65NICZ.pgp
Description: OpenPGP digital signature
___
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

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

[Alessandro Pasotti]

On Thu, May 9, 2019 at 12:08 PM René-Luc Dhont  wrote:

> Hi Andreas
>
> Le 09/05/2019 à 11:59, Andreas Neumann a écrit :
> > Hi René-Luc,
> >
> > Thanks for the explanation. Any chance we can "influence" that extent
> > calculation (e.g. adding a user-defined margin to that extent?) - I
> > guess a fully manual override would not be satisfactory as data
> > changes, but adding a user-defined margin to that extent might help
> > for both issues we have.
> >
> > Also, this fact that layer extents are stored in QGIS worries me quite
> > a bit. We live in a GDI where any minute data can be changed by any
> > client (QGIS, ArcGIS, Geomedia, you name it). What if Geomedia adds
> > features outside of the layer extent that is stored in the QGIS
> > project, would that data then be ignored by QGIS server, because it is
> > outside of the extent stored in the project file in QGIS?
>
> Yes, new features outside the extent will be ignored by QGIS Server and
> QGIS Desktop if the user does not recalculate the layer extent.
>
> >
> > Anyway - I would rather have global bounding boxes for all layers
> > (defined globally per project) than some calculated exents stored in a
> > QGIS project file that might be outdated quite easily, because other
> > GIS edit the data meanwhile. I am not worried about bounding boxes
> > being too big, but worried about bounding boxes that hide away
> > existing data.
> >
> > Andreas
> >
>
> We, a customer and I, would like to add the ability to define manually
> the extent for each layer. The extent could be calculated, based on the
> CRS and modified by user.
> Do you think, could it be a solution ?
>

That depends on whether the "" tag in the WMS GetCapabilities
reponse is meant to be the layer's extent or the features's extent.

If it's the latter, we should not advertise an extent which is differed
from the extent of the features contained in the layer.


-- 
Alessandro Pasotti
w3:   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

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

[René-Luc Dhont]

Hi Andreas

Le 09/05/2019 à 11:59, Andreas Neumann a écrit :

Hi René-Luc,

Thanks for the explanation. Any chance we can "influence" that extent 
calculation (e.g. adding a user-defined margin to that extent?) - I 
guess a fully manual override would not be satisfactory as data 
changes, but adding a user-defined margin to that extent might help 
for both issues we have.


Also, this fact that layer extents are stored in QGIS worries me quite 
a bit. We live in a GDI where any minute data can be changed by any 
client (QGIS, ArcGIS, Geomedia, you name it). What if Geomedia adds 
features outside of the layer extent that is stored in the QGIS 
project, would that data then be ignored by QGIS server, because it is 
outside of the extent stored in the project file in QGIS?


Yes, new features outside the extent will be ignored by QGIS Server and 
QGIS Desktop if the user does not recalculate the layer extent.




Anyway - I would rather have global bounding boxes for all layers 
(defined globally per project) than some calculated exents stored in a 
QGIS project file that might be outdated quite easily, because other 
GIS edit the data meanwhile. I am not worried about bounding boxes 
being too big, but worried about bounding boxes that hide away 
existing data.


Andreas



We, a customer and I, would like to add the ability to define manually 
the extent for each layer. The extent could be calculated, based on the 
CRS and modified by user.

Do you think, could it be a solution ?

René-Luc
___
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

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

[Andreas Neumann]

Hi René-Luc,

Thanks for the explanation. Any chance we can "influence" that extent 
calculation (e.g. adding a user-defined margin to that extent?) - I 
guess a fully manual override would not be satisfactory as data changes, 
but adding a user-defined margin to that extent might help for both 
issues we have.


Also, this fact that layer extents are stored in QGIS worries me quite a 
bit. We live in a GDI where any minute data can be changed by any client 
(QGIS, ArcGIS, Geomedia, you name it). What if Geomedia adds features 
outside of the layer extent that is stored in the QGIS project, would 
that data then be ignored by QGIS server, because it is outside of the 
extent stored in the project file in QGIS?


Anyway - I would rather have global bounding boxes for all layers 
(defined globally per project) than some calculated exents stored in a 
QGIS project file that might be outdated quite easily, because other GIS 
edit the data meanwhile. I am not worried about bounding boxes being too 
big, but worried about bounding boxes that hide away existing data.


Andreas

Am 09.05.19 um 11:51 schrieb René-Luc Dhont:

Hi Andreas,

The layer extent is not calculated by QGIS Server. It is read from the 
project, and the extent in the project is provided by QGIS when saving 
it.


In QGIS Server, the layer extent is used to restrict the rendering to 
the WMS layer extent.


Regards,
René-Luc

Le 09/05/2019 à 11:28, Andreas Neumann a écrit :

Hi QGIS (server) devs,

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, 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 ...


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.


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.


Thanks for your replies,

Andreas

___
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
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

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

[René-Luc Dhont]

Hi Andreas,

The layer extent is not calculated by QGIS Server. It is read from the 
project, and the extent in the project is provided by QGIS when saving it.


In QGIS Server, the layer extent is used to restrict the rendering to 
the WMS layer extent.


Regards,
René-Luc

Le 09/05/2019 à 11:28, Andreas Neumann a écrit :

Hi QGIS (server) devs,

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, 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 ...


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.


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.


Thanks for your replies,

Andreas

___
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
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Andreas Neumann]

Hi QGIS (server) devs,

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, 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 ...


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.


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.


Thanks for your replies,

Andreas

___
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