Re: [office] surface plots

[Eike Rathke <erack@sun.com>]

Hi Andreas,

Again the answer from Ingrid.

  Eike

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

Hi,

>> 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.
>   
Well I have talked about regular surface charts. The class name is 
'surface' not 'contour'. 'Surface' is naturally not understood as a 2D 
thing only. But in ODF there is an attribute chart:three-dimensional to 
define that, so we do not need to speculate.
So lets speak about the 3D case for a moment. And lets assume the multi 
series approach. Then attribute chart:deep="true" makes sense, as then 
the structure is the very same as for deep bar, line or area charts.
>   
>> 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.
>   
But *surface* charts can be 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.
>   
Not simpler than a string replacement.
>   
>> 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.
>   
This becomes clearer below. You say you use the domain elements. That is 
something that is not specified for the surface chart. And it is not 
obvious that you do that and which domain elements you use for what. But 
see below.
>   
>> 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. 
>   
No. The referred sentence is with 'may' and 'similar'.
 From ODF 1.0: "The graph may visualize these using colors for height 
intervals, creating color bands similar to geographical maps." This is 
not 'exactly' and 'only'.
But as said above there is an attribute chart:three-dimensional that can 
be used to define whether the chart type should be used in 2D or 3D.
So lets agree to allow both and work on the more critical things.
> 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.)
>   
The ones to blame for that are not involved here anymore. So lets work 
on making it better.
>>  
>> 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!
>   
I disagree. The description leaves this open.
>   
>>  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)
>   
As physician I can't find anything unusual here.
>> 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. 
>   
This is still unclear. My interpretation of your description now would 
be the following:
For example x values from range A1:A4, y values from range B1:B4 and z 
values from C1:C4:
X1 Y1 Z1
X2 Y2 Z2
X3 Y3 Z3
X4 Y4 Z4
They would form 4 data points:
P1 = (X1, Y1, Z1)
P2 = (X2, Y2, Z2)
P3 = (X3, Y3, Z3)
P4 = (X4, Y4, Z4)
But looking at the Gnumeric application this seems not to be what is 
done there.
Furthermore this would allow for not equidistant points 'on the grid' 
what is not wanted for the surface chart.
>> 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).
>   
The surface image given in ODF 1.1 can be obtained using the multi 
series approach and taking the series names as labels for the axis.
Use this cell values in range A1:C4 :
1    2   3
2    4   6
3    6   9
4    8   12
And 3 series:
series1 with value range A1:A4 (and name R1)
series2 with value range B1:B4 (and name R2)
series3 with value range C1:C4 (and name R3)

You can create it in this way for example in Excel. Furthermore Gnumeric 
does import such an Excel surface chart from xls properly.
> How would you specify the x and z (?) values if they were not simply 1
> through n?
>   
I don't understand this. Your suggestion was not to have values 1 
through n but values from cell ranges, wasn't it?
> Are we even talkning about the same _2_-dimensional charts?
>   
I tried Gnumeric 1.9.10 and found that charts were not saved at all when 
saving to ODF format. So if Gnumeric has not produced files containing 
surface charts I see no reason why the specification should be made 
extra complicated here.

Furthermore I found that in Gnumeric after import of an Excel '2D 
Surface' Chart Gnumeric shows a Pseudo-3D-Axis in the element list in 
the user interface. This Pseudo-Axis can be used to defined the range 
for the height values and the steps for the color bands.
I think this is pretty straight forward and I would like to suggest this 
for the ODF specification, so we can all store the info at the same 
place. All in all I now would like to suggest this definition for 
surface charts:

----------------------------
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 with horizontal x axis 
and vertical y axis (before any 3D scene transformations). 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. In this case the thought 
coordinate system should be right-handed.
----------------------------

I hope we can come together somewhere. It really would be good to have 
this more detailed as it is within the current spec draft!
Let me know your suggestions!

Thanks and have a nice day,
Ingrid

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

-- 
 OpenOffice.org / StarOffice Calc core developer and i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS

PGP signature