> > > 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 <[email protected] >>> <mailto:[email protected]>>: >>> >>> >>> >>> >>> 2014-02-14 Marco Hugentobler <[email protected] >>> <mailto:[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] <mailto:[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, Switzerland >> [email protected] 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 >> [email protected] >> 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: [email protected] > 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 > [email protected] > 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
_______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user
