Coordinates model - Working draft.

[CresitelloDittmar, Mark]

Markus.. Thanks for the read and feedback.

On Thu, Dec 20, 2018 at 12:04 PM Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi DM,
>
> [Begin side issue]
> I still believe there's room for substantial simplifications without
> impacting functionality and actually improving robustness; for
> instance, I'd say EclipticCoord, EquatorialCoord, GalacticCoord, and
> LongLatCoord should all just be LongLatCoord; the associated frame is
> enough to tell them apart, and I can't see where having separate
> types for them would help a client (or even a server).
>
>
The plan is to use these in the Measurement model.  I've started reviewing
it, and working the documentation this week.  (FYI: Transform is pretty
much ready to go out to the WG).  It comes down to where to draw the line
for the common Astronomical data which these 'shortcuts' address.  I think
it is important that something like (ra,dec) is easy to spot, and "A
Position whose coordinate is LongLatCoord type referencing a SpaceFrame
with refFrame=[ICRS|FK4|FK5]" doesn't seem that intuitive.
So this specializes the compound coordinate to make it easy.  "A Position
whose coordinate is EquatorialCoord type"
Remember.. Position is the spatial Measure type.

I've been giving is some thought and there is another option.  Whether or
not it is better depends on what one considers (ra,dec) to be.
We COULD:
  + instead of defining specialized compound coordinates,  specify
specialized individual coordinates for each of the Standard Coordinate
Space axes,
       o  CartesianX, CartesianY, CartesianZ, Longitude, Latitude,
SphericalRadius
            something like that, we need to be able to distinguish
coordinates pointing to axes of the same 'name' in different spaces, like
Cartesian vs Cylindrical
  + then the Measurement model could define specialized measurements using
them:
       o EquatorialPosition
             *ra:Longitude
             *dec:Latitude
             *error:Error
       o GalacticPosition
             *l:Longitude
             *b:Latitude
             *error:Error
     In addition to the generic position
      o GenericPosition
         * coord: Coordinate
         * error: Error
         with constraint {coord.frame == SpaceFrame}

The difference is in the interpretation:
   current: (ra,dec) is a coordinate in a spherical coordinate space with a
particular orientation (given by the frame)
   this: (ra,dec) is the measured position of an object represented in a
spherical coordinate space with a particular orientation (given by the
frame).

Pros to this approach:
  + I like that people looking for RA,DEC will find it in Measurement,
which is probably what they want to be using (rather than the Coord).
  + It brings discovery up one level.  (ra,dec) is an EquatorialPosition.
Cons:
   - doing this would mean losing a common 'coord' attribute/vodml-id for
all CoordMeasure-s in the measurement model.



> [Begin main issue]
> Similarly (and this is quite a bit more itchy to me right now), I'm
> strongly advocating to make TimeInstant concrete and remove all its
> derived types (ISOTime, JD, MJD, TimeOffset).  Instead, TimeFrame
> should grow a timeorigin attribute.
>

We've beat around this bush a couple times.

Full disclosure, I haven't read the apps thread re: TIMESYS, but as I
recall, it works only because it requires that timeorigin is expressed in
JD specifically.
This is not OK for general usage, and without the restriction you get a
cyclical problem in the model.
  * The separation of TimeOffset from TimeInstant prevents this and, I
think is pretty non-negotiable.


> The rationale here is that the concrete form of the timestamp is a
> *serialisation* issue, i.e., one of VOTable, FITS, or whatever else.
> If the serialisation provides for having ISO-like dates or a binary
> representation of civil dates or nothing of the sort shouldn't
> determine whether you can serialise STC instances into them.
>

Not sure I would call it a serialization issue, but yes.. its related.  The
thing is, when we have time data, we need to convey how to interpret that
value (which on its face is just a 'real' ).
This modeling makes it easy to convey that info.. you have a Column or
Param which you identify as type "coords:domain.time.JD".  The alternative
is to have a single Type (TimeInstant), and a format enumeration/flag.
Which means you need 2 bits of information to interpet the value instead of
1.  Both of those bits would need to be in the model, and have a vodml-id.
So, there would still be potential conflict between vo-dml annotation vs
other 'serialization specific annotations' (like the xtype).

I do expect that most will *implement* a single object, which can be
initialized from any of the flavors, and provide 'format' interface for
getting it in the different forms, but that is just a more efficient way of
implementing the model.
Bottom line: I'm really pretty convinced that this is the proper modeling
of these bits.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20181221/5dfa2462/attachment.html>