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