Re: [office] surface plots

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

On Tue, 2009-07-28 at 17:09 +0200, Eike Rathke/Ingrid 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.
> >   
> 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. 

When I am looking at ODF 1.1, I see a description of chart:surface that
says:
 "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."
and an example image that shows a contour graph. There iws no indication
at all that this could be a three-dimensional graph.

The description of chart:three-dimensional really doesn't say anything
useful (and due to the description of chart:deep seems to refer to
three-dimensional versions of two-dimensional bar and circle charts).

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

Once again there is not enough information given with respect to
chart:deep. 

In your opinion, how would a chart:surface with
chart:three-dimensional=true and chart:deep=true differ from a
chart:surface with chart:three-dimensional=true and chart:deep=false?

If we have really three-dimensional surface charts how would the
viewpoint be specified? (The absence of such a specification would tell
me that three-dimensional surface charts are not intended.)

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

Other deep 3d charts don't show truly 3 dimensional data but just a
collection of two dimensional data.

> >>     
> >
> > Again, contour plots are _not_ 3-dimensional.
> >   
> But *surface* charts can be 3-dimensional.

If this were true, wouldn't ODF 1.1 have shown a 3-dimensional example
rather than the specific contour example?

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

and the example image shown is clearly a contour chart, not a general
surface chart. Clearly surface charts are not considered since otherwise
a viewpoint could be specified.

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

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 same would be true for gnumeric's surface plots.

THe description you gave above is gnumeric's xyz contour and xyz surface
plots.


> Furthermore this would allow for not equidistant points 'on the grid' 
> what is not wanted for the surface chart.

Why not? 

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

These plots are implemented in Gnumeric 1.9.11.

Andreas
-- 
Andreas J. Guelzow, PhD, FTICA
Coordinator, Mathematical & Computing Sciences
Concordia University College of Alberta