Following on from the discussion on relative times, I've come across an
weather display that might benefit from reference_time and named elevation
levels, vaguely like the way OGC 12-111r1 describes it.
Its pretty common to get weather data with two time dimensions:
- the date / time that the forecast was (notionally) issued
- a set of offsets from that date/time showing how the forecast changes
So for the last forecast might be "issued" at 2014-12-04T00:00:00, and there
is data at 0, 3, 6 ... 72 hours from that forecast date/time.
You can see an example of this at:
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/10m/IDY20301.windbarb-10m.000.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/10m/IDY20301.windbarb-10m.003.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/10m/IDY20301.windbarb-10m.006.png
....
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/10m/IDY20301.windbarb-10m.072.png
There will be another forecast for 2014-12-04T06:00:00, and again there is
data at 0, 3, 6 ... 72 hours from that forecast date/time.
From reading OGC 12-111r1, it looks like this can be handled by using
reference_time and time dimensions. If I'm reading it right, the "issue"
date/time would be the "reference_time" dimension, and the offsets are the
"time" dimension; although time would need to be converted from an hours offset
to an ISO8601 date/time.
*Questions*:
1. Does this look like it would be worth adding to GeoTools ImageMosaic and
GeoServer?
2. If so, should there be a special GeoTools properties extractor (or maybe
magic properties combiner) to generate "time" and "reference_time" based on a
forecast time and offset? Or does it make more sense to just have the raw
values and produce the ISO8601 datetime on the GeoServer publishing side?
Conversely, elevations aren't always in numbers. Following on from the example
above:
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/10m/IDY20301.windbarb-10m.000.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/850hPa/IDY20301.windbarb-850hPa.000.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/700hPa/IDY20301.windbarb-700hPa.000.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/500hPa/IDY20301.windbarb-500hPa.000.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/200hPa/IDY20301.windbarb-200hPa.000.png
http://www.bom.gov.au/charts_data/IDY20301/2014120400/windbarb/gradient/IDY20301.windbarb-gradient.000.png
(the same time intervals work for those interested).
OGC 12-111r1 calls that a named surface (with UNITS="computed_surface" and no
unit symbols. It looks like that will already work on the GeoTools ImageMosaic
side, and you can publish a layer with this in GeoServer but it throws an
IllegalStateException when trying to get the layer ("Unable to computer
extrema value").
*Question*
3. If the elevation is of type String, should we just publish it as a named
surface? It would require some slightly different logic on GetMap (essentially
the decision tree shown in Figure 6 of the OGC document).
4. It looks to me like the elevation part is probably a lot easier. Any
suggestions for implementation?
5. If I do implement it, would it require GSIP? One for each of elevation and
reference_time?
Brad