Re: [office] surface plots

[Eike Rathke <erack@sun.com>]

Hi Andreas,

A reply from Ingrid:

---%<---snip---%<---

> ----- Forwarded message from "Andreas J. Guelzow" <aguelzow@pyrshep.ca> -----
> 
> Date: Fri, 31 Jul 2009 11:02:00 -0600
> Subject: Re: [office] surface plots
> Message-id: <1249059720.17646.16.camel@localhost>
> 
> On Fri, 2009-07-31 at 15:02 +0200, Eike Rathke wrote:

Hi,

My answer is delayed because I was on vacation. So back to this topic now.

>> Hi Andreas,
>>
>> Answer from Ingrid:
>>
>> ---%<---snip---%<---
>>
>> Hi,
>>
>>> ----- Forwarded message from "Andreas J. Guelzow" <aguelzow@pyrshep.ca> -----
>>>
>>> Date: Thu, 30 Jul 2009 15:33:02 -0600
>>>
>>> On Thu, 2009-07-30 at 23:03 +0200, Eike Rathke wrote:
>>>
>>>>> Gnumeric has various ways this could be specified. Gnumeric implements
>>>>> chart:surface as a contour plot (not an xyz contour plot), So data would
>>>>> look like:
>>>>>
>>>>>   A  B  C  D  E
>>>>> 1 -- 1  2  3  4
>>>>> 2 1  2  7  5  6
>>>>> 3 2  4  3  3  2
>>>>> 4 3  5  6  5  4
>>>>> 5 4  3  2  3  2
>>>>> 6 5  4  5  5  5
>>>>>
>>>>> The "y"-values would be the range B2:E6, the "x" values would be given
>>>>> by B1:E1 and the "z"-values as A2:A5. So the height at x=3 z=2 would be
>>>>> 6.
>>>>>   
>>>> The ODF 1.0 description says:
>>>> "The data points are interpreted as tabular data, where each value 
>>>> defines a 'height'
>>>> at a specific grid location."
>>>> There is nothing said, that some values are interpreted as x values, 
>>>> some as y and some as height. It says *each value defines a 'height'*. 
>>>> So I don't see how your interpretation could fit into that description.
>>> The series would give a range of B2:E6 so all those data points are in
>>> fact heights. 
>>>
>>>>> The same would be true for gnumeric's surface plots.
>>>>>
>>>>> THe description you gave above is gnumeric's xyz contour and xyz surface
>>>>> plots.
>>>>>   
>>>> Well nice! Come up with a proposal for a new value for attribute 
>>>> chart:class to describe your xyz-surfaces and contours!
>>>>>   
>>>>>> Furthermore this would allow for not equidistant points 'on the grid' 
>>>>>> what is not wanted for the surface chart.
>>>>>>     
>>>>> Why not? 
>>>>>   
>>>> Because this was not specified.
>>> Perhaps I missed it but where were the equidistant points specified ?
>>>
>> The specification says that the heights should be located at a grid. 
>> That is naturally understood as something equidistant. As nothing 
>> further is said about the grid it must be assumed
> 
> Sorry, but there is no reason that this"must be assumed". 
> 
>>  that this grid is 
>> formed by the indexes of the height values within the so called 'tabular 
>> data'.
>>
>> Your adding of additional values for the grid locations is in conflict 
>> with this specification and is therefor wrong.
> 
> I see no conflict. Your interpretation is assumed. Apparently we are
> assuming different things.
> 
> You seems to ignore the primary difference between our interpretations:
> A single series with tabular data versus a sequence of series (so no
> tabular data) in your interpretation.
> 
> ODF 1.1 talks about multiple series for a few chart types: scatter (this
> seems to be changed for 1.2 to use chart:domain), stock, bubble (again
> this was changed for 1.2 to use chart domain). By default all others use
> a single series. Location in scatter and bubble in the current 1.2 draft
> uses chart:domain. SO it is reasonable to assume that the same is true
> for "surface".
> 

No. The point is, that *no* additional location values should be used at 
all for the surface chart type. Always if additional values should be 
chosen for any chart type it was described in the specification, not so 
for surface charts.

I have talked to the original author and it is like I have said already: 
The height should be located on an equidistant grid. No additional 
values should be used for the locations on the grid. The surface chart 
type was introduced to allow for Microsofts surface chart type.

I am sorry that the specification text was misinterpreted. The more the 
description should be changed to avoid further misinterpretations in the 
future:

----------------------------
surface – The values of multiple <chart:series> (marked as being of type 
chart:surface) are interpreted as an '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 with horizontal x axis 
and vertical y axis (before any 3D scene transformations). 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'). 
The accessory x-coordinates are generated from the positions in the 
altitude-value sequence starting with 1.0. The categories element can be 
used to define labels for the x axis. The first altitude value in each 
series 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. The first series has 
an associated z coordinate of 1.0. The second series has a z-coordinate 
2.0 and so forth. The series names are used as labels at the z axis.
In case of chart:three-dimensional="false" each altitude value is 
located on a 2 dimensional Cartesian coordinate system with horizontal x 
axis and vertical y axis. The categories element can be used to define 
labels for the x axis. 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. The series names are used as labels at the y axis. A 
third axis element with chart:dimension="z" is used to define the range 
and separation for the altitude values.
----------------------------

This is compatible with Microsofts surface chart and reflects the 
original authors will.


Kind regards,
Ingrid

---%<---snap---%<---

PGP signature