On Aug 30, 2010, at 18:50 , Gabriel Roldan wrote: > 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?
Definitely. The way it is set up now, if someone reconfigures a layer's extent in GeoServer, this will change the grid. > I guess not quite, we might be fine, as GeoServer WMS accepts anything the > client provides? Right, but it won't deliver cached tiles any more. > >> 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? Absolutely right. I think it's not so much the requirement for the grid to align with the one of the base layer, but the real point is to have steady gridsets. That's what all tiling software that creates tiles for overlays on top of GMaps relies on. > 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? Both will work, especially if GeoServer uses the scale hints to advertise available resolutions in the caps document. If configured with these, OpenLayers won't request tiles for resolutions that are outside this advertised resolution range. The same is true if we use the layer's maxExtent - OpenLayers won't request tiles that are outside it. Andreas. > >> >> 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 > -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
