geoserver/geoserver — pull request #430 by ilkkarinne (2013-12-20 11:27:03+00:00)
Title: Change the selection strategy for the "current" value of TIME Dimension in WMS

The current Geoserver code always selects the maximum available time for the "current" time in WMS GetMap requests. For the data sets with the TIME dimension representing future times, like weather forecasts, this default is very bad one in most cases, as the forecast representing the furtherest forecast time is chosen by default if the user does not explicitly select a time dimension value. From the user perspective this interpretation of "current" time is completely unexpected.

This point is also included as Recommendation b. in the "OGC Best Practice for using Web Map Services (WMS) with Time-Dependent or Elevation-Dependent Data"

> Rec. b The default time dimension value SHOULD be the value that is closest to the time at
which the request was received.

(http://external.opengeospatial.org/twiki_public/pub/MetOceanDWG/MetOceanWMSBPOnGoingDrafts/12-111r1_Best_Practices_for_WMS_with_Time_or_Elevation_dependent_data.pdf, page 18)

For most cases, the "current" time should be the one nearest to the current system time. For past times, this yields the same result as before, but for time steps in the future, the one nearest to the current time is chosen.

The main interest points of the change:

* The current time selection logic is refactored from the class org.geoserver.wms.WMS into a two Strategy implementations org.geoserver.wms.LatestCurrentTimeSelectionStrategy and org.geoserver.wms.NearestCurrentTimeSelectionStrategy

* The new "nearest" time selection strategy is only used if the system property "org.geoserver.wms.currentTimeSelectionStrategy" has value "nearest". This is intended as a temporary and a bit ugly way to select the wanted behavior, but it keeps current time behavior exactly the same as before unless the user actually wants to take advantage of the improved current time selection strategy. In future it would probably be a good idea to make this behavior configurable on a layer basis in org.geoserver.catalog.DimensionInfo.

* A new unit test call has been added for both the new and the old behavior: org.geoserver.wms.WMSCurrentTimeTest. This class includes a bit of a hacky private methods for dynamically creating a new raster resource with filenames reflecting time steps in the future at the time of running the test. This was necessary for testing if the new current time selection strategy works correctly for future times.

I've implemented this change is part of the commission from the Finnish Meteorological Institute regarding the use of Geoserver for providing meteorological forecast data as Open Data. I hope this change can also be back-ported into version 2.4.x and 2.3.x branches, as these versions are currently in production use at FMI.

I'm happy to provide any further info or refine this solution according to your wishes.