Re: [office] surface plots

[Eike Rathke <erack@sun.com>]

Hi Andreas,

On Wednesday, 2009-07-22 14:22:19 -0600, Andreas J. Guelzow wrote:

> > Hm, I think this needs to be specified more precisely. 
> 
> I think this is important to do, especially since if this is what
> OpenOffice implements then it differs from other implementations.
> 
> > It should be understood as:
> > 
> > <chart:series chart:values-cell-range-address="S1.$A$1:S1.$A$16" />
> > <chart:series chart:values-cell-range-address="S1.$B$1:S1.$B$16" />
> > <chart:series chart:values-cell-range-address="S1.$C$1:S1.$C$16" />
> > <chart:series chart:values-cell-range-address="S1.$D$1:S1.$D$16" />
> 
> This seems to be unnecessarily complicated. Since these series all
> belong together wouldn't it make more sense to record them as
> <chart:series chart:values-cell-range-address="S1.$A$1:S1.$D$16" />
> Otherwise we introduce and artificial dissymmetry between the base
> coordinates.
> 
> > 
> > where A1 gives the altitude (y coordinate) at x=1, z=1
> > and A2 gives the altitude at x=2, z=1
> > and B1 gives the altitude at x=1, z=2
> > and B2 gives the altitude at x=2, z=2
> > and D3 gives the altitude at x=3, z=4
> > ...
> > 
> > Let me try to give a more precise description for the specification:
> 
> This specification may describe OpenOffice's implementation but differs
> from Gnumeric's implementation. I don't know how other implementors have
> chosen to understand the description.

Again, here the answer from Ingrid:

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

Hi Andreas, all,

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).

Having multiple series forming one surface has the advantage that the 
data structure is the same as for other deep 3D charts. 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  ).

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.

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?

If there are already different implementation out there, one thing that 
could be done is to allow for both interpretations in the specification. 
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. 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'). 
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. 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. 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 ...

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 ...
----------------------

Kind regards,
Ingrid

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


  Eike

-- 
 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