This is how it _should_ work. Let me know if it doesn't:

- Request comes in and is intercepted by CachingWebMapService
- CachingWebMapService checks whether the request matches a configured tile
cache.
-- if it doesn't then request proceeds as normal, ultimately handled by the
regular DefaultWebMapService, and gwc does not get into the mix anymore for
the lifetime of the request
-- if it does match a tile cache (by bounds, format, layer, crs, etc), then
the map is served by gwc.

So, in order for the CachingWebMapService to forward the request to gwc,
the GWC mediator must have identified the request parameters as matching a
configured tile cache.
If you are using a TIME parameter in your request, the only way the GWC
mediator said it does match a tile cache is if you have a parameter
filter[1] for the TIME parameter keyword configured for the layer.
Check GWC.isCachingPossible(TileLayer, GetMapRequest):

    if (null != request.getTime() && !request.getTime().isEmpty()) {
        if (!filterApplies(filters, request, "TIME",
requestMistmatchTarget)) {
            return false;
        }
    }

If that's not working, then report the bug back here please.

Now, at the current state of the gwc integration, you can't configure a
parameter filter for an embedded geoserver layer. What you can do is to
configure a wmsLayer in <data dir>/gwc/geowebcache.xml, name it something
different than the geoserver layer (eg, "states" instead of "topp:states"),
make it point to the geoserver layer you want to cache, and configure a
parameter filter for time (this is about to change in the very near future.
You'll be able to configure these and other caching properties through the
geoserver UI, and enabling parameter filters for STYLES, TIME, and
ELEVATION will be as simple as a checkbox).

As Andrea mentioned, building a tile cache for all your TIME values might
lead to a huge cache. Although you don't need to pre-seed them all. You can
rather let the cache being built on demand, and set up the disk quota limit
so that gwc cleans up less recently/frequently used tiles up to a disk
quota usage limit.

Hope that helps,
Gabriel

[1] <
http://geowebcache.org/docs/current/configuration/layers/parameterfilters.html
>

On Sun, Feb 12, 2012 at 2:25 PM, Andrea Aime
<[email protected]>wrote:

> On Sun, Feb 12, 2012 at 5:39 PM, John Armstrong <[email protected]> wrote:
>
>> Hi, everybody.
>>
>> I've got something hacked together so that my CoverageReader can handle
>> TIME parameters, and I've tested it with wms calls through curl.  Now
>> I'm running into trouble when I try to hook it up to OpenLayers.  It
>> seems that GeoWebCache takes the incoming request and assembles a "fake"
>> request from it with a fixed list of parameters.  In
>> GeoServerTileLayer.buildGetMap():
>>
>>         params.put("SERVICE", "WMS");
>>         params.put("VERSION", "1.1.1");
>>         params.put("REQUEST", "GetMap");
>>         params.put("LAYERS", getName());
>>         params.put("SRS", srs);
>>         params.put("FORMAT", format);
>>         params.put("WIDTH", String.valueOf(width));
>>         params.put("HEIGHT", String.valueOf(height));
>>         params.put("BBOX", bbox.toString());
>>
>>         params.put("EXCEPTIONS", GetMapRequest.SE_XML);
>>         params.put("STYLES", "");
>>         params.put("TRANSPARENT", "true");
>>         params.put(GWC_SEED_INTERCEPT_TOKEN, "true");
>>
>>         Map<String, String> filteredParams = tile.getFullParameters();
>>         if (filteredParams.isEmpty()) {
>>             filteredParams = getDefaultParameterFilters();
>>         }
>>         params.putAll(filteredParams);
>>
>> the last line could, I suppose, be used to add other parameters to the
>> fake request, but tracing through the history of the tile object, I
>> can't find any place where it might get added to tile.fullParameters.
>>
>> Any ideas?  How does this work for ImageMosaics?  Thanks in advance.
>>
>
> It most likely doesn't.
>
> We actually did not check it, time + elevation would
>  require creating a separate tile cache for each different value passed
> in, which would
> end up requiring a massive amount of disk space, so it's a case I did not
> bother
> to check when implementing time/elevation support.
>
> Feel free to provide patches to make this case work (I suppose you have
> very
> few values for time/elevation?)
>
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:      +39 0584 962313
> mob:    +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>


-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to