Specific software configurations for weather reporting websites

There are four distinct approaches to assembling the software for a weather website:

1. Choose ready-made AWS software which offers all of the functions needed to create web content and web upload. This is the simplest and quickest option, but is subject to a number of limitations. Be aware that a radical software rebuild may be necessary down the line if, having taking this option as the easiest initial route more operational reliability or flexibility is subsequently required.
2. Write all the software routines from scratch. This is certainly possible, even using easier programming languages such as Visual Basic, and some of the detailed issues involved are discussed later. It will clearly help if you're already a programmer and the availability of blocks of code from the AWS makers and other programming libraries will also ease the task.  In practice, for most people, the formatting flexibility offered by the best of the third party AWS software will be more than sufficient. And there are enough good utilities for the subsequent steps that writing new software is not really necessary.
3. A third basic but universal approach uses the fact that all AWS software creates an on-screen display of current weather information in one form or another.  The relevant part of this display can easily be captured by a screen 'grabbing' utility and saved as an image file, which can then be further processed and uploaded to the web site by additional specialist utilities. In many ways this is an attractive approach. It will work with any AWS software, irrespective of whether it has additional (eg web upload) functions or not. The modern screen capture utilities work well and produce good quality images. And the best examples of other utilities, eg for controlling the upload process, can be chosen. The main limitation is that the format of the weather data image is fixed by the AWS software and may be non-configurable, ie you may be stuck with a given layout of weather data and graphics and, for example, graph-scaling may also be fixed. Note especially that this approach calls for all processes downstream of the AWS screen display to be built and controlled by additional utilities. This is not difficult but does require some significant development effort.
4. Use a good example of AWS software, but supplemented with extra utilities. This is the pragmatic compromise which seeks to take advantage of the best aspects of available AWS software and to replace the weaker aspects with specialist utilities.
   When implementing this type of mixed software, it's important to remember that a typical weather update takes place as a linear sequence of steps from logging a new set of data through to upload to the web server. In general, the components of the standard AWS package can only be used to a certain point in this sequence and then a complete switch made to processing by specialist utilities. Thus the AWS package can't, for example, be used for logging and for upload, with other utilities used for the intermediate step of content generation, because there is usually no mechanism for the AWS software to give up control of processing at some point and then subsequently to take back control. Once processing control is yielded by the AWS package, that becomes a point of no return. Commonly, the AWS software might be used to save a well formatted data image to the local hard drive and then other utilities take over to perform further image processing and to control the the upload process. ( As a qualification, it's perhaps worth noting that in on-line AWS systems where a direct connection to the web server is permanently available, there is the opportunity to further process an image file on the server even after the upload process has completed. In this very particular circumstance, a standard AWS package could carry out all of the basic processes, including the normally final upload step, but with a further image processor acting directly on the server file.)

Design recommendations

In practice, and this is a key point, there is a clear choice between the straightforward option of only using whatever web content creation and upload functions might be built into your chosen AWS software and accepting significant limitations and problems that can ensue from this approach, or, opting for the slightly more complex, but ultimately more powerful and flexible approach of using a small set of additional utilities.

So, a suggested overall design of an on-line AWS system might translate into the following three sets of functional components:

1. A standard PC-linked AWS complete with data buffer, for initial acquisition of the electronic weather data under good AWS software such as Weatherlink;
2. Using AWS software additionally to capture the current weather data as an initial image, which may require further processing prior to upload (having chosen the AWS with this secondary capability specifically in mind);
3. Using extra software utilities to manage web uploads and to make the overall system more robust and more flexible;