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

[Andrea Peri]

Hi,
thx I now start to understand better the question.

Infact I'm using spatialite db. A 4.1.1 db spatialite.
The spatialite db has an internal statistics table to perform a very fast
resolution of the bboxes of single datasets.

I always update it using the command:

select UpdateLayerStatistics();

But the problem is if the client really use that table.

Infact I guess more probably the qgis-server don't ask to spatialite the
box from this table, but instead do a more usual
sql to retrieve is.

Hi Sandro,
do you know the right query to retrieve the bbox from the statistics table
of spatialite 4.1.1 ?

I guess suspect that qgis (because it like) to be more compatible with all
the oldest (arcaic) version of spatialite, simply avoid to use this table.
:)

Many thx.


Andrea.



2014-02-14 10:34 GMT+01:00 Marco Hugentobler <
marco.hugentobler at sourcepole.ch>:

>  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>:
>>
>>>
>>>
>>>
>>> 2014-02-14 Marco Hugentobler <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
>>> 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, Switzerlandmarco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
>
>


-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20140214/6732f36f/attachment.html>