Coordinates model - Working draft.

Thu Jan 24 21:21:50 CET 2019

All,

Got some additional feedback from Ada off-line which should be folded into
the next iteration of the document.. see below:

On Thu, Jan 24, 2019 at 3:08 PM CresitelloDittmar, Mark <
mdittmar at cfa.harvard.edu> wrote:

> Ada,
>
> Thank you for this input.. I'll address your points here, but also send a
> follow-up to the mail list on items which should go into the next iteration
> of the WD.
>
>
> On Wed, Jan 23, 2019 at 11:42 AM AdaNebot <ada.nebot at astro.unistra.fr>
> wrote:
>
>> Hi Mark,
>>
>> Thanks for your work putting all this together. Great job!
>>
>> Since this model does concern time domain, I feel I should give some
>> feedback… I could send some of my questions to the DM list but I would like
>> to have an outside discussion with you too. Of course you are free to
>> forward this email to anyone you consider necessary. Even reply in the DM
>> list if you think that would bring something positive. I’ve put Arnold in
>> CC.
>>
>> First, I’m extremely sorry for my huge email, but I do want to get to
>> understand some details.
>>
>> So here are some comments in particular on section 6, package
>> domain.time:
>> All the information written in section 6 package domain.time, page 26 was
>> already shared by Arnold, back in 2017 during the Shanghai meeting:
>> http://mail.ivoa.net/pipermail/voevent/2017-May/003097.html and
>> supported by the TDIG as stated in the TDIG twiki page:
>> https://wiki.ivoa.net/twiki/bin/view/IVOA/DAL_DM_TDIG
>> so +1 from my side.
>>
>> Point 6 end of the paragraph: “I assume we will be sticking with TT and
>> TDB…” —> Remove that sentence from the text. I understand this is not a
>> final version, but still no point in leaving it there.
>>
>
> You are the second to mention that this.
>   ACTION:  I'll remove the assumption sentence, and leave this bullet
> with the TCG,TCB,TDB text and "More in the cited A&A paper"
>
>
>>
>> *Section 6.1.1. TimeFrame.refPosition *
>> type: coords.domain.space.RefLocation “The spatial location at which the
>> coordinate is considered to have been take from”.
>> Shouldn't there be a pointer to a vocabulary here as it is done for the
>> timescale? I’m thinking here GEOCENTER, BARYCENTER,… and what has already
>> been discussed in other emails.
>> Also, a name can be a location but indicating (long,lat,height) is also a
>> location but with a completely different format. I would expect this to be
>> more specific and mention the kind of format this should have. If this is
>> meant to be free for interpretation, then I think it should be stated like
>> that.
>>
>
> The RefLocation type is abstract, and has both StdRefLocation (vocabulary)
> and CustomRefLocation subtypes.  I tend to not re-state the options at
> places where abstract types are used, unless there is something specific
> about that usage worth stating.  Since RefLocation is used both here and in
> refDirection, it might be useful to elaborate here.
>    ACTION: add text to description..
>    "In this model, RefLocation supports locations provided as either a
> standard reference position (GEOCENTER) or a coordinate specifying a custom
> location (eg: long, lat, height)."
>
>
>>
>> *Section 6.1.2. TimeFrame.timescale*
>> https://ivoa.net/vocabularies/coords/TimeScale
>> I couldn’t find the link, but I guess this will be existing soon?
>>
>
> This is a work in progress.  I've sent the lists to Markus/Mireille and he
> installed them in volute back in mid-Dec.
> He had some comments on the content of some of them (the space reference
> frames had some hierarchy issue).  The action is on me to get back to that
> and correct the lists and 'build' them(?) to some location which that URL
> would point to.
>
> excerpt from my last mail with Markus/Mireille on this:
> "  * once these are established vocabularies, the content becomes a
> separate topic (IMO), so
>      am happy to have things cut which are not immediately useful to the
> community
>     o with these in place, the next step would be to point SSIG and TDIG
> at them to make recommendations/additions"
>
>
>>
>> *Section 6.1.3. TimeFrame.refDirection*
>> So here you mean the coordinates of the observed object(s)? This is
>> needed for light travel corrections between two different observing points
>> (refPosition) and also for combining observations taken at two different
>> moments where the Earth (or observatory position) was at a different
>> location and therefore the solar system ephemerides is needed. I think it
>> cannot harm having things clearly defined and explained to some level.
>> Maybe this is not the best phrasing but in those lines.
>>
>
> ACTION: I'll see about clarifying the text for how/when this is used.
> Arnold.. any suggestions?
>
>
>> *Section 6.2.* *TimeStamp*
>> As I understand the UML —> Section 6.2 defining the TimeStamp should be
>> made clearer, indicating that a TimeStamps can be either a TimeInstant or a
>> TimeOffset (real quantity with respect to a TimeInstant) and that
>> TimeInstants have to be given in JD, MJD or ISO-8601. This is very clear to
>> me when looking at the UML, but not so in the text. Is there a reason why
>> there’s a check-box on Fig.6 on CoordFrame ?
>>
>
> * again, this is an efficiency thing.. not stating the current extensions
> as part of the parent description, which makes more text which can get out
> of sync.  In my other model docs, I've had more pictures (small snippets of
> families such as this).  That would show the group at the point of
> description.  With this ivoatex doc, I've limited it to 1 diagram per
> section, and in this particular case, that diagram would be about 80% of
> what is in Fig. 6, just 2 pages earlier.. so I'm kind-of on the fence here
> about changing this.
>
> * There is no check-box in Fig 6... I think sometimes different PDF
> readers do funky things.
>
>
>>
>> *Section 6.4. ISOTime:*
>> “ISO-8601 standard within the *restrictions imposed by the IVOA”* What
>> are those? Removing the time-zone? I would suggest to add the restriction
>> and properly reference it.
>>
>> Ah.. That is described in the appendices (E.1.2).  That is a bit of a
> loose end.. I transferred that text from the cube model, but this should be
> consistent with what is in the DALI Rec.  DALI goes into more detail than
> what is here (which is appropriate for a Data Access standard vs a model),
> but are consistent.  The DALI Rec states that it follows the conventions
> used by FITS (2001) and STC (2007).
>
> ACTION:  I think the thing to do here is bring the text from E.1.2. into
> Section 6.4, and review the details w.r.t. DALI Section 3.3.3.
>
>
>
>> *Section 6.6. MJD:*
>> Typo in page 28: T(MJD) = T(JD) - 2440000.5 —>  T(MJD) = T(JD) -
>> 2400000.5
>>
>>
> ACTION: correct this.
>
>

There are additional questions regarding representing a particular scenario
which will feed into the other actions on describing the supported cases,
corresponding derived requirements, and example files.
Will follow-up as that solidifies.

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