OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] surface plots


Hi Andreas,

Another reply from Ingrid.

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

Hi,
> ----- Forwarded message from Andreas J Guelzow <aguelzow@math.concordia.ab.ca> -----
>
> Date: Tue, 28 Jul 2009 23:45:10 -0600
>
> 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. 
>   
I am sorry, I am not a native speaker and have chosen the wrong word. 
Actually I am physicist. As such I am used to work with different 
coordinate systems. It is just a matter of definition.
Some are used here some there.
> 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.
>
>   
>> ----------------------------
>> 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 with horizontal x axis 
>> and vertical y axis (before any 3D scene transformations). The given 
>> values for a series are interpreted as y-coordinates (representing the 
>> 'altitude'). The accessory x-coordinates are generated from the 
>> positions in the altitude-value sequence starting with 1.0. The 
>> categories element can be used to define labels for the x axis. The 
>> first altitude value in each series 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. The series 
>> names are used as labels at the z axis.
>> In case of chart:three-dimensional="false" each altitude value is 
>> located on a 2 dimensional Cartesian coordinate system with horizontal x 
>> axis and vertical y axis. The categories element can be used to define 
>> labels for the x axis. 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. The series names are used as labels at the y axis. A 
>> third axis element with chart:dimension="z" is used to define the range 
>> and separation for the altitude values. In this case the thought 
>> coordinate system should be right-handed.
>> ----------------------------
>>     
>
> I really have a problem with this. If we use the same
> chart:class=chart:surface for contour and surface plots then the common
> axes should carry the same meaning, so we really shouldn't have y be the
> altitude in one and one of the base axes in the other. Moreover the two
> non-altitude variables should really be symmetric, ie. virtually
> interchangeable.
I agree that this asymmetry between 2D and 3D is not nice and my first 
temptation also was to suggest an elegant definition that avoids this 
problem.
But...
there are other places in the ODF specification that define behavior for 
x- and y-axis (e.g. chart:axis-position, chart:reverse-direction, 
chart:vertical). So the coordinates cannot be chosen completely freely.
For the 2D case it is necessary to have the x- and y-axis creating the 
grid. What nicely fits to your implementation.
For the 3D case it is necessary to have the x- and z-axis creating the 
grid. And this is what Microsoft implements. So this does fit for all 
except that it is not elegant.
> Moreover non-ordinal labels should not used in such a
> plot since for the reader of such graphs an ordering is implied.
>   
I disagree. The intention of this chart type has been to allow for 
compatibility with Microsofts surface charts. They do allow for labels here.
Furthermore the example in ODF 1.0 does show labels.
> Not ethat for only 2 visible axes it does not make sense to talk about
> right or left handed coordinate systems.
>   
If you think this sentence is not necessary for the 2D case I am fine 
with skipping it.
>> I hope we can come together somewhere. It really would be good to have 
>> this more detailed as it is within the current spec draft!
>> Let me know your suggestions!
>>
>>     
>
> 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"

See also my former mail.

Ingrid

-- 
Sun Microsystems GmbH
Nagelsweg 55, D-20097 Hamburg
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering

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

PGP signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]