1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
% Copyright 2019 by Till Tantau
%
% This file may be distributed and/or modified
%
% 1. under the LaTeX Project Public License and/or
% 2. under the GNU Free Documentation License.
%
% See the file doc/generic/pgf/licenses/LICENSE for more details.
\section{Introduction to Data Visualization}
\emph{Data visualization} is the process of converting \emph{data points,}
which typically consist of multiple numerical values, into a graphical
representation. Examples include the well-known function plots, but pie charts,
bar diagrams, box plots, or vector fields are also examples of data
visualizations.
The data visualization subsystem of \pgfname\ takes a general, open approach to
data visualization. Like everything else in \pgfname, there is a powerful, but
not-so-easy-to-use basic layer in the data visualization system and a less
flexible, but much simpler-to-use frontend layer. The present section gives an
overview of the basic ideas behind the data visualization system.
\subsection{Concept: Data Points}
\label{section-dv-intro-data-points}
The most important input for a data visualization is always raw data. This data
is typically present in different formats and the data visualization subsystem
provides methods for reading such formats and also for defining new input
formats. However, independently of the input format, we may ask what kind of
data the data visualization subsystem should be able to process. For
two-dimensional plots we need lists of pairs of real numbers. For a bar plot we
usually need a list of numbers, possibly together with some colors and labels.
For a surface plot we need a matrix of triples of real numbers. For a vector
field we need even more complex data.
The data visualization subsystem makes no assumption concerning which kind of
data is being processed. Instead, the whole ``rendering pipeline'' is centered
around a concept called the \emph{data point}. Conceptually, a data point is an
arbitrarily complex record that represents one piece of data that should be
visualized. Data points are \emph{not} just coordinates in the plane or the
numerical values that need to be visualized. Rather, they represent the basic
units of the data that needs to be visualized.
Consider the following example: In an experiment we drive a car along a road
and have different measurement instruments installed. We measure the position
of the car, the time, the speed, the direction the car is heading, the
acceleration, and perhaps some further values. A data point would consist of a
record consisting of a timestamp together with the current position of the car
(presumably two or three numbers), the speed vector (another two or three
numbers), the acceleration (another two or three numbers), and perhaps the
label text of the current experiment.
Data points should be ``information rich''. They might even contain more
information than what will actually be visualized. It is the job of the
rendering pipeline to pick out the information relevant to one particular data
visualization -- another visualization of the same data might pick different
aspects of the data points, thereby hopefully allowing new insights into the
data.
Technically, there is no special data structure for data points. Rather, when a
special macro called |\pgfdatapoint| is called, the ``totality'' of all
currently set keys with the |/data point/| prefix in the current scope forms
the data point. This is both a very general approach and quite fast since no
extra data structures need to be created.
\subsection{Concept: Visualization Pipeline}
The \emph{visualization pipeline} is a series of actions that are performed on
the to-be-visualized data. The data is presented to the visualization pipeline
in the form of a long stream of complex data points. The visualization
pipeline makes several passes over this stream of data points. During the first
pass(es), called the \emph{survey phase(s)}, information is gathered about the
data points such as minimal and maximal values, which can be useful for
automatic fitting of the data into a given area. In the main pass over the
data, called the \emph{visualization phase}, the data points are actually
visualized, for instance in the form of lines or points.
Like as for data points, the visualized pipeline makes no assumptions
concerning what kind of visualization is desired. Indeed, one could even use it
to produce a plain-text table. This flexibility is achieved by extensive use of
objects and signals: When a data visualization starts, a number of signals (see
Section~\ref{section-signals} for an introduction to signals) are initialized.
Then, numerous ``visualization objects'' are created that listen to these
signals. These objects are all involved in processing the data points. For
instance, the job of an |interval mapper| object is to map one attribute of a
data point, such as a car's velocity, to another, such as the $y$-axis of a
plot. For each data point the different signals are raised in a certain order
and the different visualization objects now have a chance of preparing the data
point for the actual visualization. Continuing the above example, there might
be a second |interval mapper| that takes the computed $y$-position and applies
a logarithm to it, because a log-plot was requested. Then another mapper, this
time a |polar mapper| might be used to map everything to polar coordinates.
Following this, a |plot mark visualizer| might actually draw something at the
computed position.
The whole idea behind the rendering pipeline is that new kinds of data
visualizations can be implemented, ideally, just by adding one or two new
objects to the visualization pipeline. Furthermore, different kinds of plots
can be combined in novel ways in this manner, which is usually very hard to do.
For instance, the visualization pipeline makes it easy to create, say,
polar-semilog-box-plots. At first sight, such new kinds of plots may seem
frivolous, but data visualization is all about gaining insights into the data
from as many different angles as possible.
Naturally, creating new classes and objects for the rendering pipeline is not
trivial, so most users will just use the existing classes, which should, thus,
be as flexible as possible. But even when one only intends to use existing
classes, it is still tricky to setup the pipeline correctly since the ordering
is obviously important and since things like axes and ticks need to be
configured and taken care of. For this reason, the frontend libraries provide
preconfigured rendering pipelines so that one can simply say that a data
visualization should look like a |line plot| with |school book axes| or with
|scientific axes|, which selects a certain visualization pipeline that is
appropriate for this kind of plot:
%
\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
\begin{tikzpicture}[scale=.7]
\datavisualization [school book axes, visualize as smooth line]
data [format=function] {
var x : interval [-2:2];
func y = \value x*\value x + 1;
};
\end{tikzpicture}
\end{codeexample}
%
\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
\begin{tikzpicture}[scale=.7]
\datavisualization [scientific axes, visualize as smooth line]
data [format=function] {
var x : interval [-2:2];
func y = \value x*\value x + 1;
};
\end{tikzpicture}
\end{codeexample}
%
One must still configure such a plot (choose styles and themes and also specify
which attributes of a data point should be used), but on the whole the plot is
quite simple to specify.
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "pgfmanual"
%%% End:
|
