Re: [office] surface plots

[Andreas J Guelzow <aguelzow@math.concordia.ab.ca>]

On Fri, 2009-07-24 at 18:54 +0200, Eike Rathke wrote:
> It is not OpenOffice.org that has implemented the surface chart 
> differently. OpenOffice.org does not at all implement the surface chart 
> type so far. But Mircosoft does for example. They do create ods surface 
> charts like I have described for the 3D case - where in addition they 
> set the attribute chart:deep="true" (what is a good thing to do here I 
> think).

So we already having two implementations (Microsoft Excel and Gnumeric)
that implement this in different ways.

I don't understand how chart:deep="true" is related to this. A contour
chart (we are not talking about regular surface charts as they are
usually understood) is by definition 2-dimensional and so chart:deep
does not apply.

> 
> Having multiple series forming one surface has the advantage that the 
> data structure is the same as for other deep 3D charts.

Again, contour plots are _not_ 3-dimensional.

>  That makes it 
> easy to switch between those types. Applications that do not implement a 
> surface chart can easily use a bar chart instead ( I am on a jump to 
> implement that  for OpenOffice.org  ).

It would probably be as easy to implement a contour plot as to implement
some conversion from contour to barchart.

> 
> I think the multiple series approach has furthermore the advantage that 
> the accessory grid locations are defined more precisely.
> With the single series approach the grid locations are quite unclear so 
> far. This must be specified further if we allow for it.

I don't understand this.

> 
> Regarding the 2D case:
> Microsoft does not create real 2D surface charts. Instead they create 3D 
> surfaces with a perspective looking from the top.
> At least for performance reasons I think it would be good to allow and 
> to define real 2D case for surface charts (contour chart). What do 
> others think about this?

My reading of chart:surface is that this is in fact a 2-dimensional
contour chart. I think that the reference to geographical maps makes
this abundantly clear. 

Gnumeric also exports/imports other charts to ODF that are
three-dimensional using its own namespace. Those exports have a similar
structure as those currently used by Gnumeric for chart:surface.
> 
> If there are already different implementation out there, one thing that 
> could be done is to allow for both interpretations in the specification.

Well, apparently there already are. (I guess this is another proof that
these chart descriptions are not sufficiently clear and unique.)

>  
> But this puts an extra burden on all applications, so I would not prefer 
> that way. It would be interesting what others do think about this issue.
> In case we anyhow allow for multiple interpretations I need your help to 
> give a complete suggestion for the specification. Could you fill in the 
> missing parts for the Gnumeric interpretation, please?
> 
> This is a suggestion for a definition that allows for both known 
> interpretations of the surface chart (missing parts to be completed):
> ----------------------
> surface – The values of multiple <chart:series> (marked as being of type 
> chart:surface) are interpreted as a 'altitude' at a specific grid 
> location. The graph may visualize these using colors for height 
> intervals, creating color bands.
> 
> In case of chart:three-dimensional="true" a left handed three 
> dimensional cartesian coordinate system is used.

These are contour charts, form ODF 1.1: "the data points are interpreted
as tabular data, where each value defines a 'height' at a specific grid
location. The graph may visualize these using colors for height
intervals, creating color bands similar to geographical maps."

So chart:three-dimensional="true" can never happen!! There are only two
axes, not three!

>  The attribute 
> chart:deep has to be set to true in this case. The given values for a 
> series are interpreted as y-coordinates (representing the 'altitude').
(As mathematician, I find it quite unusually to call the height y rather
than z)
> In case multiple series with type surface are given the accessory x and 
> z coordinates are determined as follows. The accessory x-coordinates are 
> generated from the positions in the altitude-value sequence starting 
> with 1.0.

unless they are given by the first chart:domain

>  The first altitude value gets an x value 1.0. The second 
> altitude value is associated with an x value of 2.0 and so forth. The 
> z-coordinates are generated from the positions  of the series elements 
> starting with 1.0.

unless they are given by the second chart:domain

>  The first series has an associated z coordinate of 
> 1.0. The second series has a z-coordinate 2.0 and so forth.
> In case only one series with type surface is given x and z coordinates 
> are determined as follows.
> ... please enter a suggestion to describe how the x and z values are 
> determined in this case ...

They are given by the two chart:domain series. 
> 
> In case of chart:three-dimensional="false" each altitude value is 
> located on a Cartesian x-/y-grid.
> In case multiple series with type surface are given the accessory x and 
> y coordinates are determined as follows.
> The x-coordinates are generated from the positions in the altitude-value 
> sequence starting with 1.0. The
> y-coordinates are generated from the positions of the series elements 
> starting with 1.0.
> In case only one series with type surface is given the accessory x and y 
> coordinates are determined as follows.
> ... please enter a suggestion to describe how the x and y values are 
> determined in this case ...
> ----------------------

Considering your description, how could you ever obtain the
chart:surface image given in ODF 1.1 (note that the vertical axis does
not have numerical values).

How would you specify the x and z (?) values if they were not simply 1
through n?

Are we even talkning about the same _2_-dimensional charts?

Andreas

-- 
Andreas J. Guelzow
Concordia University College of Alberta