Coordinates model - Working draft.

[François Bonnarel]

Markus,

Units are fine but they are not the whole story.

Expressing a time shift with unit ="byr" (or year) doesn't mean 
"Besselian (or Julian)  years representation".

Because you simply miss the definition of the timeorigin for the 
representation.

We NEED a clean and consistent model with uniform and ptroper definitions.

I think the current version of Coords goes into good direction.

Cheers

François




Le 18/01/2019 à 13:44, Markus Demleitner a écrit :
> Hi,
>
> I know I had vowed to keep mum for a while, but this one thing hasnt'
> been make explicit so far, so:
>
> On Fri, Jan 18, 2019 at 11:59:42AM +0100, François Bonnarel wrote:
>> Le 15/01/2019 à 13:42, Markus Demleitner a écrit :
>>> The information that something is, say, a floating point number in
>>> Julian years is already in the container format,
>> I don't think we have something in VOTAble or DALI for Julian years.
> Well, sure: <FIELD datatype="float" unit="yr"/>  (or unit="Byr" for
> Besselian years).
>
> It's certainly an important use case for me to properly annotate such
> fields within STC objects.  To get an idea of what kinds of data are
> being represented in this way, try
>
>    select * from tap_schema.columns where unit='yr'
>
> on the TAP service http://dc.g-vo.org/tap.
>
> Right now, that's 112 columns; you can of course try the same on
> VizieR, where you get back 1584 such columns.
>
> You'll find things like epu in ucac5.main, which is the epoch of
> observation and as such a central piece of data for the basic use
> case "bring two catalogs onto the same epoch".  There's the equinoxes
> of coordinates for historical plates (which probably don't need too
> much annotation).  There's coverages, there's dates when two objects
> are closest, and of course there's lots of mean epochs, which would
> become important if we wanted to cover the extended use case "bring
> two catalogs onto the same epoch and give sensible error estimates".
>
>
> Last round of broken record, really: There's absolutely no reason to
> exclude this (or any other) time representation.  JSON or YAML or
> whatever else either have their own ones already (and probably in
> ways incompatible with the current choice of JD, MJD, or ISO), or
> we'll have to define them separately anyway when we say how these
> things are supposed to be used in the VO.  There's simply no way a
> data model could magically bring them to par with VOTable or FITS --
> that's always going to have to be a separate, format-specific
> document.
>
>         -- Markus