This would make it seem like it is possible to select a combination
like MODELRUN_TIME=2009-11-27T00:00&TIME=2009-11-26T00:00, and the
goal is to find a way to express which combinations that are
(im)possible, so that a sufficiently advanced client can select any
combination of dimensions that will return an image.

Capabilities document unsuitable?

I've been thinking of different ways of expressing these combinations
as effectively as possible within the capabilities document, and I've
come to the conclusion that it's not possible. If a layer offers many
dimensions with many dependencies in other dimensions, you can't
present a complete set of combinations without creating a huge
document. Conversely, if you want to express the combinations
compactly, you must hide some of the possible combinations from the
client.

GetDimensions

I propose that we instead define a new WMS operation, called
GetDimensions. The purpose of this operation is to return only those
dimension values that are still available when the user has selected
values from the other dimensions.

Now the TIME dimension has been truncated to only include the forecast
times available for MODELRUN_TIME=2009-11-26T00:00. Note that
MODELRUN_TIME still includes all available modelruns, and the
attribute userValue, which repeats the selected value.

and so on. Every time the user changes the value of any dimension, or
selects a new layer, a new GetDimension request is issued by the
client. The returned XML-document will contain all values that the
client shall present to the user, and assuming the user only changes
one dimension value at a time, it will be impossible for the user to
select an impossible combination.

Mutually exclusive dimensions

This solution could also be extended to work in situations where a
layer offers multiple dimensions that are mutually exlusive. One
example is the use of hour offsets instead the forecast time. The
layer allows you to use both the TIME dimension and the OFFSET_TIME
dimension, but using both in the same request will not make sense.

This can be solved by using a new element to group dimensions. I've
called it DimensionGroup, but suggestions are welcome.

In this case, the client should present the user with an option to
choose between using TIME or OFFSET_TIME, and when the user has made
the selection, it'll be possible to select a value for that dimension.
When the user selects a value, another GetDimension request is issued,
just like in the other situations.

Note that the TIME dimension now contains all values available for the
selected MODELRUN_TIME, and completely ignores the OFFSET_TIME
dimension. When generating the list of available values the server
shall ignore any dimensions from the same dimension group. This way,
the client can allow the user to switch back from OFFSET_TIME to TIME,
and make a new TIME selection, based on the TIMEs available from the
currently selected MODELRUN_TIME.

Vertical dimensions

So far, I've only used temporal dimensions as examples, but this
mechanism should be powerful enough to allow for vertical dimensions
as well

Conclusion

I think this way of dealing with dealing with dimensions is flexible
enough for all our needs. It necessarily adds some complexity to the
client, but I think this is unavoidable anyway.

I also suggest that the capabilities document must contain all
possible values for all possible dimensions for each of the
layers. This will allow users of less sophisticated clients to still
access all available data. It will be possible for those users to
create request that asks for impossible combinations of dimensions,
but it's still better than not being able to access the data at all.

There's one thing I haven't made an effort to address, and that's the
situation when there's no complexity, and the use of GetDimensions is
unnecessary. This can vary from layer to layer, and I think it would
be a good idea to limit the use of GetDimensions to only those layers
that needs it.

I also think it could be an idea to add more attributes to the
elements. Maybe there should be a "name"-attribute to the
DimensionGroup element? Perhaps an attribute to Dimension that
indicates if the values are ascending or descending? An attribute that
declares if the unitSymbol is postfix or prefix could also be useful.

This client will only request dimension values when a layer is switched on or off, and my suggestion will require a new GetDimension request every time the user changed the value of any dimension as well, but it shouldn't be too difficult to apply this change.

The information you supply is used for OGC purposes only. We will never pass your contact details to any third party without your prior consent. If you enter content here you are agreeing to the OGC privacy policy.