Hi,
only my point of view :-)
Mark Taylor wrote:
> Francois and others,
>
> On Fri, 21 Apr 2006, Francois Ochsenbein wrote:
>
>
>>Thanks for all the comments -- the IVOA meeting is coming soon and
>>this point of time/angle representations in VOTable could be one of
>>the subjects if wished.
>
>
> Although this suggestion has met with considerable resistance on the
> list, I would still like to discuss it at Victoria.
Perhaps only con have express themselve!
I am a pro ;-)
>
> Even if one takes the position that the correct answer in the case of
> angles is to require data providers to use decimal degrees and simply
> to ignore tables which don't do so, I think (having heard representations
> from solar physicists at least) that this doesn't solve the problem of
> times, since unlike unlike angles there is no obvious zero point.
> MJD is one convention, but there are others (e.g. JD), and there is
> currently no way within VOTable to specify which of these conventions
> you're using. The correct answer to this may be STC, but we don't
> currently have that within VOTable either. People know what is meant
> by ISO-8601 time strings. I'm not a time expert so it may be that
> this format carries subtle ambiguities as well, but from a pragmatic
> point of view it's clear that it would satisfy a need of a large
> number of potential users of the format without a major change.
I totally agree concerning time string.
Oftenly used even outside astronomy (an either outside "science" in courant life)
frequently seen even in XML file, and already existing in some programmtic
langage API (like in Java).
It would be very nice to be able to use this in VOTable!
>
>>As Clive mentioned, the VizieR output can display the coordinates in
>>sexagesimal, e.g. from
>>http://vizier.u-strasbg.fr/viz-bin/votable?-source=USNO-B1&-c=0-90&-oc.form=sexa&-out.add=_RAJ,_DEJ
>>
>>The conventions that are used there correspond to Mark's P2 suggestion:
>>
>>
>>> P2. Modify the definition of the "units" attribute so that it is
>>> permitted to contain either a catstd-format unit string as at
>>> present, or a special representation string as in P1.
>>> We could possibly say that for numeric-valued columns it works
>>> as at present, but for string-valued columns it has the new sense.
>>> However one could conceive of a case where you want both
>>> representation and units (though I can't think of any actual
>>> examples), which would be problematic for this scheme.
>>
>>and such units are "quoted" as "h:m:s" or "d:m:s", i.e. the FIELD definition
>>contains unit=""h:m:s"" . In fact the "quoted" units were
>>originally introduced to accept any non-standard unit.
>
>
> This seems like as good a convention as any; it's clear that similar
> solutions are being used by different projects to address this problem.
> But without standardisation, these solutions are not going to be
> interoperable. I would be perfectly happy to standardise on this
> "quoted unit" convention.
I found this nice too.
--
Pierre
------------------------------------------------------------------
DIDELON :@: pdidelon_at_cea.fr Phone : 33 (0)1 69 08 58 89
CEA SACLAY - Service d'Astrophysique 91191 Gif-Sur-Yvette Cedex
------------------------------------------------------------------
Received on 2006-04-28Z14:52:31