[Qgis-user] Qgis-server recompute always the layer bbox ?
G. Allegri
giohappy at gmail.com
Fri Feb 14 02:06:07 PST 2014
>
>
> 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.
>
This happens for the combined extent, not for the single layer. In case you
set it in the OWS tab the overall extent isn't calculated.
giovanni
> 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
>>
>>
> --
> Bernhard Ströbl
> Anwendungsbetreuer GIS
>
> Kommunale Immobilien Jena
> Am Anger 26
> 07743 Jena
>
> Tel.: 03641 49- 5190
> E-Mail: bernhard.stroebl at jena.de
> Internet: www.kij.de
>
>
> Kommunale Immobilien Jena
> Eigenbetrieb der Stadt Jena
> Werkleiter: Dr. Götz Blankenburg
>
>
> __________ Information from ESET Mail Security, version of virus signature
> database 9422 (20140214) __________
>
> 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
>
--
Giovanni Allegri
http://about.me/giovanniallegri
Twitter: https://twitter.com/_giohappy_
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20140214/56365dbd/attachment.html>
More information about the Qgis-user
mailing list