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 < [email protected]>: > 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 <[email protected]>: >> >>> >>> >>> >>> 2014-02-14 Marco Hugentobler <[email protected]>: >>> >>> 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 >>> [email protected] >>> 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, [email protected] > http://www.sourcepole.ch > Technical Advisor QGIS Project Steering Committee > > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù -----------------
_______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user
