Re: [Geoserver-devel] New community module: dynamic dimension defaults

[Jody G. <jod...@gm...>]

New community module seems fine, although it seems like a small bit of
functionality that could be added to WMS as long as it is optional.

Normally I ask that extensions be listed in a vendor capabilities section
of GetCapabilities, but I feel like this is a losing battle. What would it
take for us to start documenting our extensions in this fashion?


On Friday, April 18, 2014, Andrea Aime <and...@ge...> wrote:

> Hi,
> I'm writing to propose a new community module that allows to set rules
> to dynamically select WMS dimension values based on what is provided
> in the request, instead of using the static ones configured in the
> capabilities
> document.
>
> The common issue that we see with COTS/legacy clients is that they often
> support no dimensions, or maybe just time, or time and elevations, but they
> rarely provide support for dynamic dimensions.
>
> Now, there is a set of user cases in which the dimension domains are
> irregular from an overall point of view, in other words, picked a certain
> value in a dimension, there is no guarantee that the defaults in the others
> will form a set that matches an actual data entry, which results in the
> client getting back a blank image.
>
> A client supporting the full set of dimensions will at least give the user
> the opportunity to try different dimension values combinations, but with
> a client that only supports time, it's really a russian roulette.
>
> So we want to create a community module that allows the default
> values of the dimensions the client did not specify in a dynamic fashion,
> in particular support two modes:
> * associate the default value of a dimension to a CQL expression of
>   other dimensions (e.g., default value of DIM_RUN_TIME is a function of
> TIME)
> * use the policy set in the default values, but restrict it to the domain
>   of values allowed by the other selected dimensions, e.g., if the
> elevation
>   is set to the minimum value, and time is T0, then select the minimum
>   elevation among the values that have T0 as the time
>   (for vector data it's obvious how to implement it, for raster data we can
>   only do this for StructuredGridCoverageReaders, by accessing the
> GranuleSource)
> * provide a evaluation order, so that we know in which order to perform
>   the domain reduction in case there is more than one dimension whose
>   value is not specified
>
> The idea is to put in the Spring context
> a DimensionDefaultValueSelectionStrategyFactory
> with a ExtensionPriority higher than the default one, so that WMS will use
> that
> one, and this new factory will take into account the above configurations,
> falling back on the default factory when no value could be determined
> (a little change will be needed in WMS, instead of having
> DimensionDefaultValueSelectionStrategyFactory factory =
> this.applicationContext.getBean(DimensionDefaultValueSelectionStrategyFactory.class);
> we'll need:
> DimensionDefaultValueSelectionStrategyFactory factory =
> GeoServerExtensions.extendions(DimensionDefaultValueSelectionStrategyFactory.class).get(0);
>
> (I already hear Kevin complaining that it's difficult to unit test that
> way because
> of that, if that's too much of a pain I guess we could add a setter and
> have
> the extension programmatically set in its factory, but this will not work
> well
> if someone needs to further override these factories, at least
> GeoServerExtension
> gives some degree of control on that)
>
> Please note that this would happen in parallel with the existing default
> dimension
> code, it would not fully replace it, it would simply override it for
> GetMap requests,
> but for the capabilites documents generation the current code stays.
>
> Plus, I guess at least for the time being we don't want a non standard
> compliant
> behavior to be available by default. If there is big demand for this we
> can think
> of merging the two concepts in a single configuration later (at this time
> we just
> don't have enough time/resources for the extra work needed for a potential
> core inclusion)
>
> Feedback and votes welcomed
>
> Cheers
> Andrea
>
>
> --
> ==
> Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
> for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>


-- 
Jody Garnett