[Qgis-user] Qgis-server recompute always the layer bbox ?

[Marco Hugentobler]

Hi Bernhard

That option was meant to give the webclient a hint where to zoom first. 
But it probably was forgotten in the server and I agree it would be good 
to overwrite the calculated box in the toplevel group.

Regards,
Marco

On 14.02.2014 10:58, Bernhard Ströbl wrote:
> Hi Marco,
>
> I have a question in this context (I thought I made ticket but cannot 
> find it)
> What is the sense of setting the bounding box in OWS tab if it is 
> always calculated to the sum of the bboxes of the layers in the 
> project? IMHO setting the bbox in the project properties should 
> override any calculation result.
> Background: One of my layers became empty because a user deleted the 
> last record thus its bbox was calculated to be the whole earth 
> resulting in QGIS server propagating the whole earth as bbox for this 
> project.
>
> Bernhard
>
> Am 14.02.2014 10:34, schrieb Marco Hugentobler:
>> Hi Andrea, Giovanni
>>
>> QGIS Server doesn't calculate the bbox itself, but it queries the extent
>> from the layers. So it can be that certain providers calculate the bbox
>> (of course only if the layer / capabilities document is not cached).
>>
>> For a faster startup, having a persistent cache as Giovanni suggested
>> might help.
>>
>> Regards,
>> Marco
>>
>> On 14.02.2014 10:18, G. Allegri wrote:
>>>
>>>
>>>     I don't understand why the qgis-server eed to calculate always the
>>>     bbox.
>>>     In the server project windows,
>>>     qgis ask for the published bbox.
>>>     Why it don't use it as bbox rather than calculate it on every
>>>     request ?
>>>
>>>
>>> Marco, correct me if I'm wrong.
>>> QGIS Server doesn't calculate the BBOX, it parses the layers extents
>>> from the .qgs project and then combine them to obtain the entire BBOX.
>>> The only operation it does is reprojecting the extents to WGS84 to
>>> create the EX_GeographicBoundingBox element.
>>>
>>> Anyway, in case the project advertises and extent, the combined extent
>>> won't be calculated, so in your case this phase shouldn't be the
>>> bottleneck...
>>>
>>> giovanni
>>>
>>>
>>>
>>>
>>>     The FastCGI don't help really.
>>>     In a publishing environment every few hour the instances are
>>>     restated to removed zombi process.
>>>     This mean that every few hours the FastCGI are emptied and 
>>> reloaded.
>>>     A fastcgi environment mean to load 20 instances of QGIS-server and
>>>     every of them do them own elaboration .
>>>     As the bbox calculation for every layer.
>>>
>>>     GASP.
>>>     The start could ask about one hours and more.
>>>
>>>     Also another problem with the fastcig is that when
>>>     I change something on a project I need to restart to Web instances
>>>     to dismiss the actual project and reload the new.
>>>
>>>     So every change in a qgis project need a restart of all proccess
>>>     (20 and so on in a fastcgi enviroment) every with a slow bbox
>>>     calculation phase.
>>>
>>>     mmhh...
>>>
>>>     :/
>>>
>>>
>>>
>>>     2014-02-14 9:13 GMT+01:00 G. Allegri <giohappy at gmail.com
>>>     <mailto:giohappy at gmail.com>>:
>>>
>>>
>>>
>>>
>>>         2014-02-14 Marco Hugentobler <marco.hugentobler at sourcepole.ch
>>>         <mailto:marco.hugentobler at sourcepole.ch>>:
>>>
>>>             Hi Andrea
>>>
>>>
>>>             >I suspect that QS try always to recalc the box of every
>>>             layer.
>>>
>>>             QGIS server caches layers (up to 100, but that can be
>>>             enhanced using the environment variable
>>>             MAX_CACHE_LAYERS).  Furthermore, the GetCapabilities
>>>             documents are cached (so no recalculation if using 
>>> FastCGI).
>>>
>>>
>>>         Thanks Marco, you confirmed what I told Andrea.
>>>         It would be a good enhancement if caching could be done in a
>>>         persitent manner (out of memory). We could consider, in the
>>>         future, to use memcache or something similar.
>>>
>>>         giovanni
>>>
>>>         _______________________________________________
>>>         Qgis-user mailing list
>>>         Qgis-user at lists.osgeo.org <mailto:Qgis-user at lists.osgeo.org>
>>>         http://lists.osgeo.org/mailman/listinfo/qgis-user
>>>
>>>
>>>
>>>
>>>     --
>>>     -----------------
>>>     Andrea Peri
>>>     . . . . . . . . .
>>>     qwerty àèìòù
>>>     -----------------
>>>
>>>
>>>
>>>
>>> -- 
>>> Giovanni Allegri
>>> http://about.me/giovanniallegri
>>> Twitter: https://twitter.com/_giohappy_
>>> blog: http://blog.spaziogis.it
>>> GEO+ geomatica in Italia http://bit.ly/GEOplus
>>
>>
>> -- 
>> Dr. Marco Hugentobler
>> Sourcepole -  Linux & Open Source Solutions
>> Weberstrasse 5, CH-8004 Zürich, Switzerland
>> marco.hugentobler at sourcepole.ch  http://www.sourcepole.ch
>> Technical Advisor QGIS Project Steering Committee
>>
>>
>>
>> __________ Information from ESET Mail Security, version of virus
>> signature database 9421 (20140213) __________
>>
>> The message was checked by ESET Mail Security.
>> http://www.eset.com
>>
>>
>> _______________________________________________
>> Qgis-user mailing list
>> Qgis-user at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>>
>> __________ Information from ESET Mail Security, version of virus 
>> signature database 9421 (20140213) __________
>>
>> The message was checked by ESET Mail Security.
>> http://www.eset.com
>>
>


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee