From e0c6872cf40896c7be36b11dcc744620f10adf1d Mon Sep 17 00:00:00 2001
From: Norbert Preining <norbert@preining.info>
Date: Mon, 2 Sep 2019 13:46:59 +0900
Subject: Initial commit

---
 .../doc/text-en/pgfmanual-en-dv-introduction.tex   | 148 +++++++++++++++++++++
 1 file changed, 148 insertions(+)
 create mode 100644 graphics/pgf/base/doc/text-en/pgfmanual-en-dv-introduction.tex

(limited to 'graphics/pgf/base/doc/text-en/pgfmanual-en-dv-introduction.tex')

diff --git a/graphics/pgf/base/doc/text-en/pgfmanual-en-dv-introduction.tex b/graphics/pgf/base/doc/text-en/pgfmanual-en-dv-introduction.tex
new file mode 100644
index 0000000000..cd48bd5d67
--- /dev/null
+++ b/graphics/pgf/base/doc/text-en/pgfmanual-en-dv-introduction.tex
@@ -0,0 +1,148 @@
+% 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:
-- 
cgit v1.2.3

