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 <[email protected]> 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
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
