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 ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
