diff options
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.tex | 203 |
1 files changed, 96 insertions, 107 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 index b480f2ed589..cd48bd5d675 100644 --- 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 @@ -10,125 +10,113 @@ \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. +\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. +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 +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. +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. +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. +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: +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] @@ -138,6 +126,7 @@ visualization pipeline that is appropriate for this kind of plot: }; \end{tikzpicture} \end{codeexample} +% \begin{codeexample}[] \begin{tikzpicture}[scale=.7] \datavisualization [scientific axes, visualize as smooth line] @@ -147,10 +136,10 @@ visualization pipeline that is appropriate for this kind of plot: }; \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. - +% +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: |