summaryrefslogtreecommitdiff
path: root/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-introduction.tex
diff options
context:
space:
mode:
Diffstat (limited to 'Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-introduction.tex')
-rw-r--r--Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-introduction.tex159
1 files changed, 159 insertions, 0 deletions
diff --git a/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-introduction.tex b/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-introduction.tex
new file mode 100644
index 00000000000..b480f2ed589
--- /dev/null
+++ b/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-introduction.tex
@@ -0,0 +1,159 @@
+% Copyright 2008 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}[]
+\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}[]
+\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: