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