Hi, study-ing the qgis code, I see in the spatialite provider there is a significative piece of code conditioned by some #IFDEF SPATIALITE_VERSION_GE_4_0_0
I don't see any option in cmake setting named like this. Is this a missing ? Thx, A. 2014-02-14 10:54 GMT+01:00 Andrea Peri <aperi2...@gmail.com>: > 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.hugentob...@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 <gioha...@gmail.com>: >>> >>>> >>>> >>>> >>>> 2014-02-14 Marco Hugentobler <marco.hugentob...@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@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.hugentob...@sourcepole.ch >> http://www.sourcepole.ch >> Technical Advisor QGIS Project Steering Committee >> >> > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù -----------------
_______________________________________________ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user