STC Questions
Arnold Rots
arots at head.cfa.harvard.edu
Mon Jun 20 11:44:27 PDT 2005
Dear Francois,
Here are some responses
1.
Actually, POLAR exists and we shall assume it to imply that the
distance is measured from the north pole.
I can add SOUTHPOLAR.
2.
I assume we have dealt with epoch in a previous message.
3.
- "deg deg m" is consistent with the way XML schema handles lists and
it seems logical to use this to specify the units for a vector when
those units are mixed.
Having said that, I'll grant you that it does look far from elegant,
but I would be reluctant to adopt something that is inconsistent with
XML schema (such as comma-separated lists). Would it help if it were
explicitly type-cast as a list of strings?
- Allowing different units for different components is an option that
was dropped as a result of the discussion in the DM WG. I could bring
it back as an optional attribute.
- The components of the unit sphere are direction cosines, so, yes, they
are dimensionless.
4.
This was an attempt to be economical (though it would have been
clearer if "unit" had been called something like "vel_pos_unit", but
that would have left and orphan "unit" attribute). Since allowable
units are enumerated and there are 13 candidate position units and 6
candidate time units in existing enumerations, defining a specific
velocity unit would have implied an extra list of 78 velocity units.
I don't feel terribly strongly about this and might be able to come up
with a sensible list of 30, or so, but I also wondered whether
separating the units makes life easier for parsers.
5.
One might argue that many (yes, not all) of the time "formats" are
really units, comparable to rad, deg, h, arcmin, arcsec,...
Sexagesimal was also dropped in the DM WG discussion, partly on the
grounds that since we are dealing with documents intended to be
handled by software, it should not really matter - a nice thing for
style sheets to handle. It may be good to point out that FITS does
not know a sexagesimal format, either.
6.
This has been discussed in the DM WG and, from a DM point of view,
the vector approach is the right thing to do.
As you are indicating, the group mechanism can be used to make the
reference in tables that contain separate columns for longitude and
latitude, RA and Dec, or X,Y,Z. Is there anything wrong with that in
principle (assuming that my next comments would adequately address
your other issues)?
As to the case of the meridian data, it is perfectly legal to specify
a SPHERICAL coordinate system with only one axis, but one would be
well advised to provide the name of the axis. By extension, there is
an obvious default order for the coordinates, but one can allow
departures from that, provided the order is documented in the
coordinate name.
Concerning XPath, I'm not sure where XPath 2.0 stands, but it is
supposed to handle elements in lists properly.
Hope this solves at least a few of the issues.
Cheers,
- Arnold
Francois Ochsenbein wrote:
>
> Questions and Comments about STC
> --------------------------------
>
> The comments and questions included here originate mostly in our trials to
> make use of STC in the VOTable context. No special order in the questions,
> they are just numbered for convenience.
>
> 1. The Various Spherical Coordinates (2D and 3D)
>
> In the "CoordFlavor" element concerning spherical and unitsphere:
> different conventions are in use for the 2nd angle (latitude).
> The latitude convention measures this second angle from the equatorial
> plane, but other conventions measure this second angle angle from one
> of the poles (as "north polar distance" or "south polar distance").
> Could CoordFlavor be extended ? Polar distances have some advantages
> (always a positive value)
>
> 2. The Question of Epoch (Question (4) of the RFC page)
>
> The epoch of a coordinate system represents the date to which the
> spherical angles are reduced. After reflexion, it looks more logical
> to attach the Epoch to the AstroCoords structure (section 4.6)
>
> 3. The Question of Units
>
> The STC defines the units as an attribute to the AstroCoords elements.
> When used in the VOTable context, a conflict may (and frequently does)
> arise between the units defined at the STC/AstroCoords and
> the units defined in the VOTable(s). One solution could be that
> STC defines only default (suggested) units.
>
> But other problems with the units exist:
> -- heterogeneous units in 3D spherical coordinates like "deg deg m"
> look ugly, and is a nonsense from a physical point of view
> (see also separation of axes below)
> -- in practice units used to express angles, their error, and angular
> sizes are different. The current schema defines a single unit
> for all these elements. By the way what is meant by
> `The UnitSphere has default units ""' ? unitless angles ???
> radians ?
>
> 4. Question about Velocity Units
>
> The schema contains strange definitions for the units defined for
> velocities:
> -- one attribute "unit" which contains an angular or linear unit
> -- one attribute "vel_time_unit" which contains a time unit.
> A unit of a velocity should refer to a velocity, not a distance.
> Why can't there be a single "unit" attribute taking the values
> "km/s" or "arcsec/yr" or any valid velocity unit ?
>
> 5. Format of the angular/time values
> For time it is possible to use a large variety of formats
> (JD, ISOtime, MJD, decimal year..) but for angle the sexagesimal
> is not allowed ?
>
> 6. Separation of Axes
>
> In the VOTable context, we need to be able to refer to one axis
> of the coordinate frame. Even though VOTable has the notion of
> groups, it seems preferable to keep the possibility of designating
> one component along one of the axes, since some catalogs do
> contain the values on only one axis, e.g. meridian catalogs (RA
> only) or just galactic latitude (when longitude is not important).
>
> The current STC definitions do not allow the possibility of addressing
> a single axis of a reference frame: the XPath mechanism does not
> permit (as far as I know) to address e.g. the 3rd component of
> a multivalued element -- could some XML guru confirm this limitation ?
> The "utype" mechanism, based on the XPath syntax, has the same limitation
> -- unless we decide that the "utype" extends somewhat the XPath mechanism.
>
> The merge of values having different physical natures into a single
> unstructured element is another motivation for separating the axes:
> the association of 2 angles and a distance (spherical coordinates),
> into a set of just 3 numbers is a source of potential misinterpretations
> and of errors (the order in which the components are given may
> differ between applications). This association in a single entity also
> requires a definition of multi-dimensional units like "deg deg m"
> which have no physical meaning.
>
> Separation of the 2 axes may be done in two ways:
>
> Way1: Sequential enumeration of the axes, each axis containing
> its properties (in a way similar to the Quantity model):
> <Position2D>
> <Axis>
> <Name>Longitude</Name>
> <Value unit="deg">234.5678</Value>
> <Error unit="deg">0.0003</Error>
> ...
> </Axis>
> <Axis>
> <Name>Latitude</Name>
> <Value unit="deg">-0.0512</Value>
> <Error unit="deg">0.0003</Error>
> ...
> </Axis>
> </Position2D>
> (Note: it could be possible to use <Axis1> <Axis2> ... instead of a
> repetition of <Axis>)
>
> Way2: closer to the current definitions, each property enumerates the
> values on each axis:
> <Position2D>
> <Name>
> <Axis>Longitude</Axis>
> <Axis>Latitude</Axis>
> </Name>
> <Value2 unit="deg">
> <Axis>234.5678</Axis>
> <Axis>-0.0512</Axis>
> </Value2>
> <Error2 unit="arcsec">
> <Axis>1.1</Axis>
> <Axis>1.1</Axis>
> <Error2>
> <Position2D>
> (Note: it could be possible to use <Axis1> <Axis2> ... instead
> of a repetition of <Axis>)
> However, such a definition means that <Axis> may be composed of a
> String (when sub-tag of <Name>) or a Double (when sub-tag of Value2).
>
> A reference to the longitude component may then be written:
> -- in Way1:
> crd:AstroCoords[@coord_system_id="GALACTIC"]/Position2D/Axis[1]/Value
> -- in Way2:
> crd:AstroCoords[@coord_system_id="GALACTIC"]/Position2D/Value2/Axis[1]
>
> Thanks for any answer or comment to these questions !
> ================================================================================
> Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg
> 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29
> Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 17
> ================================================================================
>
--------------------------------------------------------------------------
Arnold H. Rots Chandra X-ray Science Center
Smithsonian Astrophysical Observatory tel: +1 617 496 7701
60 Garden Street, MS 67 fax: +1 617 495 7356
Cambridge, MA 02138 arots at head.cfa.harvard.edu
USA http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------
More information about the dm
mailing list