Tuesday, July 31, 2012

Forecast Periods, Time-Zones and More Sizes

We have updated the SARWeather production system again. The changes mostly have to do with the period covered by each forecast and the way time-zones are handled.

We also reverted a previous change which allowed more fine-grained selection of the forecast period, but unfortunately made pre-processing 3 times slower.

Better Forecast Period Handling

We now keep an archive of weather data, initially going back to the beginning of July 2012, and users can request a "forecast" from this period, which will in actuality be based on observational data and the weather model used to down-scale and fill the gaps in the observations. For example, here we can see the recent torrential rains in Beijing.

We now also allow forecasts up to 7 days into the future. This has become possible because we allow a forecast to be started using data just retrieved from NOAA even before the whole data-set has arrived, or even generated. This way, we don't need to balance the amount of data fetched with how soon it can be used for forecasting.

Finally, we allow forecasts which start out using the archived observational weather data and smoothly transition to forecast mode when required. All this is done transparently behind the scenes and the users need not worry about the details. It's all just weather.

New Period Selection UI

All this extra flexibility calls for a better user interface for period selection. Now, when the user presses the area in the side-bar where period information is shown, then a dedicated pop-up period editor appears.

The period editor allows selecting the start and end times for the forecast separately. It ensures that the period is within the bounds of available data, and that the forecast is at least 3 hours. If either the start or end time is moved too close to the other, so there would not be at least 3 hours between them, then the other blinks yellow and is automatically updated.

On the right-hand side of the period editor we show a table of available weather data. This table has at least 2 rows: Analysis and Forecast. They show the period covered by available analysis data based on observations, and forecast data for the period following the analysis. If the period selected by the user requires that analysis data is used, then that row will be shown in green, and likewise for the forecast row.

Some times, when new forecast data is being retrieved, then the newest forecast data will not reach as far into the future as the previous forecast did. In those cases, a third row is shown, marked as Previous. If the user selects a period which can't be covered by the analysis and latest forecast data, then the previous forecast will be used instead and this row is shown in a warning orange.

Note that the user can still choose to ignore the data availability and usage table and simply select the required period.

Simpler Time-Zone Handling

We have moved all time-zone handling out into the browser, where it uses the client system's time-zone setting. This allowed us to remove all time zone configuration from SARWeather.

Please let us know if there are any problems with the time-zone handling, since this is all new code and difficult to fully test.

More Forecast Sizes

A few weeks ago we detached the length of a forecast from the forecast type, which made the list of forecasts much smaller. This now gave us room to add two new forecast types, a larger 3 km-resolution forecast and a smaller 9 km-resolution forecast. We now cover the range from 30 km to 1015 km reasonably well.

1 comment:

  1. Thank you for the good article.
    With all the variety of forecast software, we have a significant obstacle on the way. This is data loss. Especially the one made intentionally. This is the only reason I would use secure data room services to keep data safe.