Thanks Dave and Andreas for the insights, please read bellow. On Aug 30, 2010, at 12:52 PM, Andreas Hocevar wrote:
> On Aug 30, 2010, at 03:38 , Gabriel Roldan wrote: > >> But there's a thing I need to polish. For all this to actually work, we need >> to ensure that the client's layer resolutions match the ones in GWC (and >> also the tileOrigin?). >> >> So I'd appreciate some advise on how to ensure that to the extent possible. >> How do the OL clients figure out the tile origin and resolutions when >> dealing with the regular WMS? do them just use the CRS area of validity? > > OpenLayers sets up the grid for each zoom level based on the maxExtent the > layer is configured with, So, am I right in thinking that, if the layer extent changes during the lifetime of the OL application that got configured that way, this may lead to troubles? I guess not quite, we might be fine, as GeoServer WMS accepts anything the client provides? > and the current resolution (which is a factor-of-2 subdivision of the > maxResolution of the map's base layer). I think this does not work with GWC, > because the resolutions come from a different layer than the extent. > > As David already pointed out, in GeoNode, we take the maxExtent for each > layer from the WMS capabilities. And the tileOrigin vendor param is > configured on the application level for the layer, as the lower left corner > of this maxExtent. > > >> Would it help if we enhance the GeoServer WMS GetCapabilities document to >> supply the WMS-C VendorSpecificCapabilities if the GetCapabilities request >> comes with TILED=true? > > We would not benefit from that, because the resolutions array is always > determined by the map's base layer, not the layer itself. > > In my opinion, our best option would be to always configure the map with the > validity extent of the CRS and a maxResolution that fits the maxExtent's > width in the CRS map units to 256 pixels (or whatever resolution assumption > is made - this is the one for EPSG:900913). All layers should request tiles > that match this grid. Totally agree. I was just thinking about that and writing a mail to the geoserver ml on the topic. The point being that, I guess, most of the time the tiled layers are used to create mash ups so they need (or is it just better?) to seamlessly overlap the map's grid, and a good way to achieve that is to have steady gridsets based on the area of validity of the CRS rather than random ones based on the layer bounds? After all, if the layer occupies only a tiny part of the CRS area of validity, the number of tiles for the higher zoom levels is gonna be small anyways, or we could also tell the server to cache a given layer only for a range of zoom levels, while still fitting the overall gridset. Does that make sense? > > The question is: how crucial is the tilesorigin vendor param to avoid > duplicated labels? If the tilesorigin can also be the origin of the CRS > validity extent, we wouldn't even have to parse GetCapabilities for WMS at > all. I guess so. Good point. I'm not completely sure how crucial the tilesOrigin is to avoid duplicated labels... I _guess_ it's not that crucial cause I think geoserver only relies on metatiling to do so. Gabriel. > > -Andreas. > >> >> >> Desperately looking for your help :) >> Gabriel. >> >> Gabriel Roldan >> [email protected] >> Expert service straight from the developers >> > > -- > Andreas Hocevar > OpenGeo - http://opengeo.org/ > Expert service straight from the developers. > Gabriel Roldan [email protected] Expert service straight from the developers
