Allow GeoServer to return the closest time/elevation/custom dimension value available, in respect to the requested one.

Andrea Aime

This proposal is for GeoServer 2.14-beta. A backport to stable might happen, but it's not currently in the plans.

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

Allow imprecise specification of dimensions (human friendliness) as well as overlaying dimension enabled layers having mismatched dimension values.

GeoServer WMS supports "WMS-T", that is, supports time, elevation and custom dimensions, including listing their values in the capabilities document.

The implementation right now requires the requested dimension value to be an exact match for a value available in the server, which in turns can cause issues in various cases, e.g.:

• when the default value is not a match (e.g., "current" for time)
• when multiple layers are involved in the request, without having synchronized times (e.g. one layer having monthly frequency while another having daily one).

The specification allows to advertise "nearest match", when enabled the layer will use the closest dimension value to the one requested, and return the actual value used as a HTTP header.

This also poses some challenges, as "nearest" does not actually mean anywhere near the requested value, it just means the closest.

This GSIP allows some extended configuration syntax to enable controlled matching, in particular, allowing to match in a given direction (e.g. only in the past) and/or at a given distance (e.g., no more than 1 day away from the requested value).

This GSIP will add nearest match support only for the time dimension, on both raster and vector layers, while leaving the possibility to add support for nearest match on elevation/custom dimensions at a later date, depending on development resource availability

In particular, the user interface for a layer will have two new entries in the "dimensions" tab, for the time dimension:

In particular:

• The "Nearest Match" checkbox would enable nearest matching (off by default for backwards compatibility)
• The "Acceptable interval" would control how far away to look for a match

The "Acceptable interval" allows three possible inputs:

• An empty value would imply no limit (default behavior)
• A single value would allow a symmetric search in both before/lower and after/higher directions
• Two values separated by a slash would allow to setup an asymmetric search range, e.g., P1D/P0D to search at most one day in the past, but not in the future. The time period syntax comes from ISO and it's already supported used when setting default values for time.

It is to be noted that setting a search range would make the server not comply with the WMS specification, but still, in custom applications and controlled environments it will allow for a more useful behavior (e.g., overlaying data that is far away in time would normally make the user looking at the map draw invalid conclusions).

The WMS service will be modified so that:

• Capabilities returns the nearest match attribute on time dimension, if configured
• GetMap/GetFeatureInfo follow the nearest match specification and, complying with the spec, return a HTTP header reporting the actual matched dimension values, e.g. "Warning: 99 Nearest value used: time=2018-01-12T00:00:00.000Z ISO8601", for each dimension and layer in use.
• When no match is found a blank image will be used, matching the current behavior without nearest match enabled.

The new settings default values imply no nearest match, so there will be no backwards compatibility issue.

Project Steering Committee:

• Alessio Fabiani: +1
• Andrea Aime: +1
• Ben Caradoc-Davies: +1
• Brad Hards: +1
• Christian Mueller:
• Ian Turton: +1
• Jody Garnett: +1
• Jukka Rahkonen: +1
• Kevin Smith: +1
• Simone Giannecchini: +1

• Email Discussion