OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
Expand all | Collapse all

surface plots

  • 1.  surface plots

    Posted 07-15-2009 16:40
    Regarding chart:class specified plots:
    
    surface – The values of multiple 


  • 2.  Re: [office] surface plots

    Posted 07-22-2009 19:45
    Hi Andreas,
    
    On Wednesday, 2009-07-15 10:39:57 -0600, Andreas J. Guelzow wrote:
    
    > Regarding chart:class specified plots:
    > 
    > surface – The values of multiple 


  • 3.  Re: [office] surface plots

    Posted 07-22-2009 20:22
    Hi Eike,
    
    On Wed, 2009-07-22 at 21:37 +0200, Eike Rathke wrote:
    > Hi Andreas,
    > 
    > On Wednesday, 2009-07-15 10:39:57 -0600, Andreas J. Guelzow wrote:
    > 
    > > Regarding chart:class specified plots:
    > > 
    > > surface – The values of multiple 


  • 4.  Re: [office] surface plots

    Posted 07-24-2009 17:02
    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:
    > > 
    > > 


  • 5.  [office] Leave of Absence

    Posted 07-24-2009 17:45
    I will be on vacation for the next 2 weeks missing calls on 27-Jul and 3-Aug.  I will begin participating again on 10-Aug.
    
    Thanks,
    Eric Patterson
    


  • 6.  Re: [office] Leave of Absence

    Posted 07-24-2009 18:04
    Hi everyone,
    
       Just a reminder that 7 days' notice is required for a Leave of  
    Absence request.
    
    Regards,
    
    Mary
    
    Mary P McRae
    Director, Standards Development
    Technical Committee Administrator
    OASIS: Advancing open standards for the information society
    email: mary.mcrae@oasis-open.org
    web: www.oasis-open.org
    twitter: fiberartisan  #oasisopen
    phone: 1.603.232.9090
    
    Standards are like parachutes: they work best when they're open.
    
    
    
    
    
    
    
    
    On Jul 24, 2009, at 1:42 PM, Eric Patterson wrote:
    
    > I will be on vacation for the next 2 weeks missing calls on 27-Jul  
    > and 3-Aug.  I will begin participating again on 10-Aug.
    >
    > Thanks,
    > Eric Patterson
    
    


  • 7.  RE: [office] Leave of Absence

    Posted 07-24-2009 20:02
    With this clarification, I would like to request a leave of absence for the period 1-Aug to 9-Aug.
    
    Thanks,
    Eric Patterson
    
    


  • 8.  Re: [office] surface plots

    Posted 07-24-2009 23:37
    On Fri, 2009-07-24 at 18:54 +0200, Eike Rathke 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.
    
    > 
    > 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.
    
    >  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.
    
    > 
    > 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.
    
    > 
    > 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. 
    
    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.)
    
    >  
    > 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 


  • 9.  Re: [office] surface plots

    Posted 07-28-2009 15:17
    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 


  • 10.  Re: [office] surface plots

    Posted 07-28-2009 18:22
    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 


  • 11.  Re: [office] surface plots

    Posted 07-30-2009 21:11
    Hi Andreas,
    
    Again the answer from Ingrid:
    
    ---%<---snip---%<---
    
    Hi,
    > ----- Forwarded message from "Andreas J. Guelzow" 


  • 12.  Re: [office] surface plots

    Posted 07-30-2009 21:33
    On Thu, 2009-07-30 at 23:03 +0200, Eike Rathke wrote:
    
    > >
    > > 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 series would give a range of B2:E6 so all those data points are in
    fact heights. 
    
    > > 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.
    
    Perhaps I missed it but where were the equidistant points 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.
    
    Users have public access to our development code and lots of users are
    in fact using it. (In fact 1.9.10 will export those charts too. I assume
    you used the misnumbered Windows Version on The Gnumeric web site.) And
    I doubt that ODF 1.2 will be approved before the next releases of
    Gnumeric. 
    
    I did send a proposed clarification for chart:surface to the list.
    
    Andreas
    
    
    -- 
    Andreas J. Guelzow 


  • 13.  Re: [office] surface plots

    Posted 07-31-2009 13:10
    Hi Andreas,
    
    Answer from Ingrid:
    
    ---%<---snip---%<---
    
    Hi,
    
    > ----- Forwarded message from "Andreas J. Guelzow" 


  • 14.  Re: [office] surface plots

    Posted 07-31-2009 17:02
    On Fri, 2009-07-31 at 15:02 +0200, Eike Rathke wrote:
    > Hi Andreas,
    > 
    > Answer from Ingrid:
    > 
    > ---%<---snip---%<---
    > 
    > Hi,
    > 
    > > ----- Forwarded message from "Andreas J. Guelzow" 


  • 15.  Re: [office] surface plots

    Posted 08-28-2009 11:06
    Hi Andreas,
    
    A reply from Ingrid:
    
    ---%<---snip---%<---
    
    > ----- Forwarded message from "Andreas J. Guelzow" 


  • 16.  Re: [office] surface plots

    Posted 07-29-2009 05:46
    On Tue, 2009-07-28 at 17:09 +0200, Ingrid via Eike Rathke wrote:
    
    > >>  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.
    
    I not intending to offend but I think this issue falls more within
    Mathematics than Medicine. 
    
    In any case, at least in North America (and I am pretty sure also in
    Germany 25 years ago) the z-axis would usually be used for height with x
    and y for the base. See for example
    http://reference.wolfram.com/mathematica/tutorial/ThreeDimensionalSurfacePlots.html
    http://www.omatrix.com/manual/mesh.htm
    http://homepages.see.leeds.ac.uk/~lecjm/Teaching/IDL_course/Notes/notes/node27.html
    
    
    
    > ----------------------------
    > surface – The values of multiple 


  • 17.  Re: [office] surface plots

    Posted 07-30-2009 14:51
    Hi Andreas,
    
    On Tuesday, 2009-07-28 23:45:10 -0600, Andreas J. Guelzow wrote:
    
    > > > (As mathematician, I find it quite unusually to call the height y rather
    > > > than z)
    > > >   
    > > As physician I can't find anything unusual here.
    > 
    > I not intending to offend but I think this issue falls more within
    > Mathematics than Medicine. 
    
    That's a translation error, Ingrid actually is a physicist. Anyway,
    I forwarded your replies again.
    
      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
    


  • 18.  Re: [office] surface plots

    Posted 07-31-2009 10:57
    Hi Andreas,
    
    Another reply from Ingrid.
    
    ---%<---snip---%<---
    
    Hi,
    > ----- Forwarded message from Andreas J Guelzow 


  • 19.  Re: [office] surface plots

    Posted 07-31-2009 16:53
    On Fri, 2009-07-31 at 12:49 +0200, Ingrid via Eike Rathke wrote:
    > > In any case, at least in North America (and I am pretty sure also in
    > > Germany 25 years ago) the z-axis would usually be used for height with x
    > > and y for the base. See for example
    > > http://reference.wolfram.com/mathematica/tutorial/ThreeDimensionalSurfacePlots.html
    > > http://www.omatrix.com/manual/mesh.htm
    > > http://homepages.see.leeds.ac.uk/~lecjm/Teaching/IDL_course/Notes/notes/node27.html
    > >   
    > Two already existing implementations of ODF use a left handed coordinate 
    > system with horizontal x axis and vertical y axis.
    
    Well, there are lots of other places where ODF has chosen to use unusual
    definition. I guess one can always trnaslate from ODF's coordinate
    naming to a more reasoanble one.
    > >
    > >   
    (...)
    > >
    > > I would think along the following line:
    > >
    > > surface -- this class of charts is used for surface and contour charts.
    > > A single series specifies a rectangular table cell area. Each column of
    > > this area corresponds to a specific x-value while each row corresponds
    > > to a specific y-value. The cell at the intersection of the column and
    > > row gives the altitude (z-value) at the specific location.
    > >
    > > The x-values are specified as the first chart:domain. If no chart:domain
    > > is given they default to 1 for the first column, 2 for the second
    > > column, etc.
    > >
    > > The y-values are specified as the second chart:domain. If no or only one
    > > chart:domain is given they default to 1 for the first row, 2 for the
    > > second row, etc.
    > >
    > > In case of chart:three-dimensional="false" a contour map is shown. Each
    > > altitude value is located on a 2 dimensional Cartesian coordinate system
    > > with horizontal x axis and vertical y axis.  Axis elements with
    > > dimension 'x' and 'y' are used to desribe the visible axes. A third axis
    > > element with chart:dimension="z" is used to define the range and
    > > separation for the colours representing the altitude ranges.
    > >
    > > In case of chart:three-dimensional="true" a 3-dimensional surface plot
    > > is shown in a right handed coordinate system with 3 axes of dimensions
    > > 'x', 'y' and 'z'. (In this case we would need some specification method
    > > for the view point and view direction.)
    > >   
    > No, this is completely not what was intended with the surface chart 
    > definition in ODF. And it stands in conflict with the former definition:
    > "the data points are interpreted as tabular data, where *each value 
    > defines a 'height'* at a specific grid location"
    
    I really don't understand how this conflicts. In my sugestion the
    datapoints of the series define heights as a specific grid location. In
    fact my suggestion use tabular data (ie. a table) to define the heights
    (while yours seems to use a collection of vectors, clearly not tabular
    data).
    
    For virtually all chart types ODF allows to specify several plots in the
    same chart in fact it allows several plot types). I fail to see how your
    interpretation would allow to specify 2 surface plots i teh same
    coordinate system.
    
    Andreas
    > 
    
    > 
    -- 
    Andreas J. Guelzow