[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] surface plots
Hi Andreas, Again the answer from Ingrid: ---%<---snip---%<--- Hi, > ----- Forwarded message from "Andreas J. Guelzow" <aguelzow@math.concordia.ab.ca> ----- > > Date: Tue, 28 Jul 2009 12:21:34 -0600 > Subject: Re: [office] surface plots > To: office@lists.oasis-open.org > Message-id: <1248805294.13111.26.camel@localhost> > > 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. > All examples are 2D. Nevertheless from the beginning there have been also 3D charts. And the accessory attributes were in the specification from the beginning! > 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? > It should not differ. And to remove one uncertainty, we could simply define that attribute chart:deep has to be true for three dimensional surface charts. But this point is really not important enough to invest more time into. > 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.) > In ODF 1.0 you can find it in chapter 10.5.1 '3D Plot Area'. In ODF 1.2 cd02 rev03 you can find it in 10.4.1. > >>> >>> >>>> 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? > All examples are 2D. Nevertheless since the beginning there has been also the 3D case. > >>> >>> >>>> 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. > You can define a viewpoint. Your argument does not work. > >> 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 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 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. > >>>> 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. > That version is not offered for download at the Gnumeric side, so there is no problem with created files. Ingrid ---%<---snap---%<---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]