This page describes the various mechanisms used in
commercially available software to add live weather data content to
web pages. The two straightforward approaches are either to use html
placeholders to insert data as text fields into pre-existing web
pages or to embed the data within graphic images in standard formats
such as .gif or .jpg.The html placeholder approach
This technique is now widely used by a number of different
weather station packages including Weatherlink Toolbox (WLT),
Virtual Weather Station (VWS), Weather View 32 (WV32), Weather
Monitor (WM) and others. It involves the prior construction of a
web page template which contains unique strings or 'tags' at
positions in the page where weather data is subsequently to appear.
(The tags act as placeholders for the actual data values). For
example, WV32 would require the string 'wvcur01wv' to be placed at a
position on the page where the a value for current temperature
should appear. Often an HTML table provides a neat container in
which to group a number of different items of weather data. Other
than the inclusion of these tags ('placeholders'), the web page is
laid out according to standard design principles and can include any
reasonable amount of other text and formatting in the usual way.
The conversion or 'parsing' of placeholders into actual data is
carried out by the weather station package according to a schedule
set by the user. Often this will happen as part of the same FTP
process by which the converted page is uploaded to the target web
server, but formally the two are distinct processes. It is generally
possible to trigger the conversion without an FTP upload, which may
be useful when the web page is to be viewed locally or distributed
via a LAN rather than via a web server.
Some packages such as WV32 have a very extensive library of tags
which can be inserted, including minimum and maximum values of
multiple weather parameters, associated times of occurrence, values
for yesterday as well as today, and individual fields from up to 150
different METAR reports! Other packages have a more limited
repertoire!
There are perhaps four limitations of the placeholder approach:
- Placeholders cater only for the insertion of text fields
into web pages and therefore the impact of colourful graphic
representations of data is not available using this approach
alone. Of course, for those packages which allow the
creation of separate graphic images - dials and gauges for
example - there is no reason why these cannot be included on the
same web pages as placeholders. Indeed the combined technique of
using both placeholders and image files (see below) may often be
the preferred approach for creating a striking and attractive
web page. But not all packages offer the facility of combining
both approaches.
- The number of different web pages which are available for
parsing at any one time is limited. It may be as few as a single
page (with the current version of WM), but the ten pages of WV32
is more typical. (How much of a limitation this is will depend
on the planned sophistication of the site. For many standard
sites, a single page will be perfectly adequate. But as a site
becomes popular, requests for extra items of weather information
may have to be dealt with. It's easy to reach the point where
more information needs to be presented than will comfortably fit
on a single web page) The file names of the web pages to be
parsed will need to follow a specific convention, which varies
with the package. The names may be fixed (WV32) or variable but
requiring prior declaration to the weather package (VWS or WM)
or require a distinct file extension (the .htx of Weatherlink
Toolbox).
- There may be some technical limitations in the design of the
web pages to be parsed. For example, Weatherlink Toolbox limits
any line on a web page to a maximum of 255 characters.
- The use of the placeholder approach is, strictly speaking,
not compatible with the use of web site managers such Microsoft
FrontPage because the 'manager' software no longer controls the
final creation and upload of the page. This can cause the
manager's records of the site to become disrupted, occasionally
with serious consequences requiring major maintenance to the web
site. To what extent this actually becomes a problem in practice
can only be established by trial and error, but the use of
placeholder techniques in conjunction with, for example,
FrontPage is unlikely to be trouble-free over an extended
period.
Embedding weather data in graphic images
All the packages reviewed here can, to a greater or lesser degree,
embed recently logged weather data into standard graphic images, for
example in gif or jpg format. Once the graphic image file has been
created, it behaves as a standard image file and can therefore be
stored, uploaded to remote servers and included within web pages in
all the usual ways. Whenever the weather software is set to update
its data output, a new version of each graphic file is generated,
overwriting the previous version. Because the use of graphic image
files is such a standard technique of web page design, this approach
to distributing weather data is very generally and straightforwardly
applicable. The only notable drawback is that the file size of
larger graphic images can, without care, become relatively large and
can slow down the loading of web pages considerably. This important
issue of image
file size is discussed elsewhere.
Weather software packages vary considerably in the extent and
flexibility of generating graphic images of data. The packages take
one of two distinct approaches to creating the images. All of the
packages except WV32 share one common approach in creating a
separate image file for each individual item of weather data. Thus
any item of updateable weather data whether it be a text-based
graphic, a dial, gauge, trend graph, iconic representation or
whatever will have its own associated image file. (Note though that
some packages provide for only a very limited range of data images -
Weather Monitor for example has a choice of only half a dozen fairly
basic trend graphs and no other graphical data objects to add to its
standard text placeholders). Not surprisingly, for complex web pages
there can be a substantial number of image files to be tracked and
uploaded and there can be minor problems recalling the (generally
unmemorable) file names of a large number of such files.
WV32 takes a different approach in that it deals primarily in
pre-arranged composite images or 'screens' and not with individual
images for every data item. Each WV32 screen consists of a set of
any reasonable number of data elements (text, dials, trend graphs
etc as before) and laid out within the WV32 application as
required. This composite screen is then saved and updated by WV32
as a single image. WV32 uses its screens both as the primary view
for the local display of current weather data and as the
basis for generating images for inclusion in web pages. Up to five
such composite screens can be updated simultaneously. So while the
relative layout of the various weather elements in packages other
than WV32 is achieved solely at the level of the web page, in WV32
itself the detailed layout design is performed primarily within the
WV32 application, though of course additional overall layout design
is still possible at the level of the web page.
Whether one of these two approaches is better than the other is
really a matter of individual preference - operationally they can
achieve much the same result. I personally would opt for the
composite screens of WV32 for three reasons: (i) it is conceptually
a little simpler to deal with the same set of images for both local
display and the web page; (ii) it is impossible to be sure how
accurately older or less common browsers will deal with the task of
reassembling many small images into the designer's planned layout.
This issue doesn't arise for a single image; (iii) the sheer number
of image files required to lay out a complex web page and to arrive
at the exact required positioning can be a minor design headache
with the individual image approach, especially if any
post-processing of the image files may be required - for example
further compression of file size to minimise download times. Again,
this problem simply doesn't arise with the single composite image
file of WV32.
|
