Geography Reference
In-Depth Information
The structure of the
location map
is fundamental to holding information about data
structures with any number of dimensions in a fixed set of two-dimensional tables. The
g data map table defines the cellRefs and associates each with the nCube to which it belongs.
However, information held in
g data coord
locates it within the nCube: cells within a one-
dimensional nCube, based on a single variable, have just one linked entry in
g data coord
, the
value of coordNo always being '1' and the value of coordVal identifying the category; a cell in
a three-dimensional nCube, on the other hand, has three linked entries in
g data coord
, with
values of coordNo running from 1 to 3. The system would still work without also holding
the ID of the relevant category in
g data coord
, but this substantially accelerates the system.
Another way we accelerate the system is by pre-computing all values of defined rates, and
these are held in
g data rate
, with labelling information in
g data rate summary
. There is
one row in
g data rate summary
for each combination of rate ID, unit type and date, so
essentially each row describes a map. Information held includes values of sextiles, which
define the keys for the default mapping. However, this is obviously to support a particular
visualization interface, which we now discuss; it would be perfectly possible but slower to
generate maps directly from the rate definitions and the raw counts in the main data table.
One obvious question is why this approach has not been taken before. The main answer
is that it uses far more disk space than storing statistics in large numbers of separate tables:
conventional methods of data archiving were originally developed in the 1970s, when disk
space was very expensive. The world has changed, and the whole of the database behind
Vision of Britain
, including the scanned images of maps, which take up most of the space,
could comfortably be held on an iPod.
13.4 Driving visualization in
Vision of Britain
Thus far little has been said about visualization, other than as a justification for extensions to
the DDI standard. The Great Britain Historical GIS is a data structure designed to support
many activities, while visualization requires software and some kind of user interface. The
particular interface to be discussed here,
A Vision of Britain through Time
,isjustoneof
the many possible interfaces to the Great Britain Historical GIS, although it is the most
complex that we have actually built. As an interface, it is very different from most of those
discussed in this topic, even those that are web-accessible (www.VisionOfBritain.org.uk). It
was funded by the UK National Lottery, via the Big Lottery Fund, as part of their 'Digitization
of Learning Materials' programme. A positive consequence was that we were, very unusually,
able to obtain large-scale funding for a project centrally concerned with the visualization and
mapping of social statistics, especially census data. However, the funding source imposed
many constraints. One of them was simply that most of the budget had to go on 'digitization',
i.e. the initial computerization of data, and programme rules tended to assume that the 'data'
were scanned images which would be served to the public using an off-the-shelf content
management system. New software development was something that had to be sneaked in,
and one merit of the data architecture already described was that it transferred intelligence
from software to the data structure: it enabled us to use a relatively small amount of code.
More specifically, all our content had to be accessible using a very basic web browser,
perhaps on a mobile phone or gaming box rather than any kind of computer. We were
not allowed to require any of the following: plug-ins like Flash or SVG viewers, Javascript,
Search WWH ::
Custom Search