Hey GeoNoders, I'm working on tighter GWC integration for the GeoServer WMS. So far it's going well, but I have a couple questions as I'm quite new to OL development. The thing is, with this kind of integration, GWC sits in front of the normal WMS and if the incomming getmap request matches a GWC tile, then it's served directly from the cache, providing automatic caching for the regular WMS. This is happening on the following git branch: <http://github.com/groldan/geoserver_trunk/tree/gwc_integration> With the previous improvements on truncating the cache based on the transactions affected area, this makes for a really improved experience and scalability. Tiles served this way are marked as non http cacheable and contain an ETag, so that the browser must revalidate. In the event the browser has the latest version already, an HTTP 304 code is returned. 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? 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? Desperately looking for your help :) Gabriel. Gabriel Roldan groldan@opengeo.org Expert service straight from the developers
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, 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. 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. -Andreas. > > > Desperately looking for your help :) > Gabriel. > > Gabriel Roldan > groldan@opengeo.org > Expert service straight from the developers > -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
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 >> groldan@opengeo.org >> Expert service straight from the developers >> > > -- > Andreas Hocevar > OpenGeo - http://opengeo.org/ > Expert service straight from the developers. > Gabriel Roldan groldan@opengeo.org Expert service straight from the developers
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 >>> groldan@opengeo.org >>> Expert service straight from the developers >>> >> >> -- >> Andreas Hocevar >> OpenGeo - http://opengeo.org/ >> Expert service straight from the developers. >> > > Gabriel Roldan > groldan@opengeo.org > Expert service straight from the developers > -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
http://github.com/GeoNode/gxp/blob/master/src/script/plugins/WMSSource.js#L98is the code that handles setting up layers in the web viewer. Basically the process is: Fetch WMS caps doc Find layer by name If the layer advertises a bbox in EPSG:900913, use that. Otherwise, reproject from Lon/Lat to get a bbox in EPSG:900913. That bbox gets set as the maxExtent for the layer, which means that all tiles fetched by OpenLayers will be aligned to some factor-of-2 grid subdivision of that bbox. In the application we also set the layer to use the bottom/left corner of this bbox as the tilesOrigin parameter in WMS requests. I imagine this situation could be improved by making GeoNode's viewer WMS-C aware. I'm not sure we need to make GeoServer do this though; can't we just point straight to GWC for a WMS-C capabilities document? -d On Sun, Aug 29, 2010 at 9:38 PM, Gabriel Roldan <groldan@opengeo.org> wrote: > Hey GeoNoders, > > I'm working on tighter GWC integration for the GeoServer WMS. So far it's > going well, but I have a couple questions as I'm quite new to OL > development. > > The thing is, with this kind of integration, GWC sits in front of the > normal WMS and if the incomming getmap request matches a GWC tile, then it's > served directly from the cache, providing automatic caching for the regular > WMS. > > This is happening on the following git branch: < > http://github.com/groldan/geoserver_trunk/tree/gwc_integration> > With the previous improvements on truncating the cache based on the > transactions affected area, this makes for a really improved experience and > scalability. > > Tiles served this way are marked as non http cacheable and contain an ETag, > so that the browser must revalidate. In the event the browser has the latest > version already, an HTTP 304 code is returned. > > 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? > > 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? > > > Desperately looking for your help :) > Gabriel. > > Gabriel Roldan > groldan@opengeo.org > Expert service straight from the developers > >