Expressing 2- and 3-D coordinates
seaman at noao.edu
Wed Dec 14 08:46:10 PST 2005
Note that I am NOT copying the VOEvent list at the moment - no need
to make waves. However...
> As you may be aware, there have been complaints about this, not
> only from people in VOEvent but also in VOTable, who want to
> separate the coordinates.
I hadn't previously heard that there were concerns other than from
the raging pragmatists of VOEvent.
> The impetus for this is a desire to appease VOEvent articipants
(I presume an "articipant" is an "anticipant participant".)
"Appease" is a loaded word. VOEvent is on the front lines for
forming a VO-wide consensus on STC. The best solution in the world
is pointless if it goes unused. VOEvent proposes to use STC - big
time and for mission critical purposes. Would be a shame if it
didn't turn out that way.
Alberto Micol writes:
> In the VO, we have to handle physical quantities, which are
> typically of vectorial nature. It seems hence very trivial to me
> that any effort in trying to serialise the physical universe should
> consider the Vector as a prime atomic constituent, and should not
> try to bend it, squeeze it, or split it into something very unnatural.
My daughter is a HS freshman taking pre-calc and I've been helping
her with matrices. I am reminded therefore that there are a variety
of representations for matrix arithmetic in math and physics.
Einstein himself took time away from looking at the big picture to
come up with his summation convention: "I have made a great
discovery in mathematics; I have suppressed the summation sign every
time that the summation must be made over an index which occurs
I think VO requirements are broad enough to allow for more than one
way of representing matrices, especially two element coordinate
vectors. If it was good enough for Albert...
Ed Shaya states:
> It makes little difference for Value2. Either way is fine with me.
And so a consensus is formed!
> The chemists realized that arrays are so important that standard
> XML parsers needed to be enhanced to include them. Now this is no
> longer necessary.
...or maybe not.
We're looking at two extremes of requirement space. The
specification of long lists (or tables) of values clearly can benefit
from a "power" notation. But this should not place an undue burden
on the more frequent need to specify simple coordinate pairs.
Roy and Matthew and Martin Hill assert:
> [A bunch of stuff I pretty much agree with.]
Francois Ochsenbein opines:
> There are two main problems:
> -- it happens that only 1 component of the position is present
> (e.g. meridian
> catalogs measure the RA, not the Dec).
> -- an array is not just a set of numbers -- in VOTable it's required
> that all elements are expressed with the same data type (e.g.
> and expressed with the same unit (this makes physical sense, too).
> It's obviously a problem for the spherical 3D coordinates
> (2 angles and a distance); errors ellipses are also problematic
> One way of resolving this dilemna in VOTable was proposed at the
> IVOA meeting in last October, [...]
> FIELD name="pos" type="double" arraysize="2" ucd="pos.eq" unit="rad"
> Position2D" >
> [...] This proposal was not accepted at the last IVOA meeting --
> but I feel it's
> really worth to consider this possibility of bridging the existing
> data models
> with large data sets expressed as VOTables. Any comments ?
Sorry I missed that discussion in Spain. My comment is that adopting
a complicated solution (as the only option) to a recurring
fundamental problem will drive users away from the VO. Many
discussions in the VO pit computer scientists against astronomers.
This one appears to be pitting computer scientists against each other.
The bottom line is that the VOEvent community is rather feisty and is
driven not only by VO concerns but also by requirements external to
the VO. This could be taken as a description of most users that the
VO is likely to attract in the future. Fundamental VO standards like
STC should be kept as simple and interoperable as practical if
growing the VO community is a goal.
In particular, the alternative to the adoption of a simple, agile STC
by VOEvent is the explicit representation of space-time coordinates
within the VOEvent schema itself. Such has already been prototyped
by two groups. In that case, my own proposal would be to revive the
STCLite schema as part of VOEvent. Not my first choice, but might be
my last choice.
XSLT can hide a multitude of sins.
More information about the votable