MOC 2.0 Proposed Recommendation: Request for Comments

Summary

MOC 2.0 describes the Multi-Order Coverage map method (MOC) to specify arbitrary coverages for sky regions and/or time coverages and potentially other dimensions. The goal is to be able to provide a very fast comparison mechanism between coverages. The mechanism is based on a discretization of space and time dimensions. The system is based on the definition of a specific storage of the map coverage using predefined cells hierarchically grouped which makes it easy to produce and use for exploring astronomical collections.

Proposed Recommendations (PRs) for MOC 2.0 can be found at:

• 2022-01-25: Updated PR based on RFC comments
• 2021-11-01: Original PR

Changes since 1.1

MOC 1.1 dealt only with spatial coverage. MOC 2.0 supports specifying either spatial coverage, temporal coverage, or both coverages combined.

Reference Interoperable Implementations

• MOCJava API (WD 2.0 compliant): JavaMoc2.jar, source (v6.2 - July 2021)
• Aladin Desktop: Aladin Desktop beta
• STMOC Fits example: STMOC.fits (XMM STMOC - 10000 Obscore first observations)
• Moc server [CDS] (23832 SMoc + 1212 TMoc + 1045 STMoc)
• MOCpy, available on github, supports MOC 2.0 with the exception of the 't' and 's' prefixes in the JSON serialization.

Implementations Validators

• MOC validator : MocLint.jar (ex: java -jar MocLint.jar STMOC.fits)

Comments from the IVOA Community during RFC/TCG review period: 2021-11-01 - 2021-12-17

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Sample comment by WikiName
  • Response (by WikiName)

Comments transcribed from a github comment from Markus Demleitner:

• \label{table:tmocsizeacs} is defined three times in appendix_perf.tex
• Please don't use fancyvrb, because it won't work properly in HTML. ivoatexDoc has a chapter on code listings, and if that doesn't work for you, let me know and we'll work something out.
• It's "Max Planck", not "Max Plank".

Comments by Markus Demleitner

There are still some typos in the text that I did not bother writing a PR for, expecting that some TCG members will do that. If that doesn't happen, poke me again before you submit to the doc repo, and I'll give it a proper round of proofreading.

(a) p. 29, in rangeList To moc:

Unmap: rangeList To moc
  for order = 0 to maxOrder
    end if rangeList is empty

What's the end doing there?

=> This algorithm in pseudo code has not been modified since the very first version of the document. "end" means the end of the loop. According to the entire algorithm, the elements already processed are removed from the rangeList ("remove from rangeList [m1<<shift .. m2<<shift["). Thus, the loop ends when the rangeList is empty. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-14

(b) p. 23 "If the original data set has been declared in the VO registry..." cites an ADASS poster of mine, which I think is not terribly helpful here; in particular, it is not clear if MOCID really is intended to represent the coverage of a VO resource, or if what you are after are registered MOCs (I'm not sure it these would make a lot of sense, but who knows). Assuming you were thinking of the first usage, I'd suggest to say here: "For MOCs that are coverages of VO resources, in particulary those used in VODataService 1.2 coverage elements \citep{2021ivoa.spec.1102D}, MOCID can contain the IVOA id of the VO resource described."

=> Good point. The suggestion has been adopted in the document . -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-14

(c) also on p. 23, MOCORDER and PIXTYPE are typeset in italics; if this is on purpose, you should explain that purpose.

=> Typeset in italics removed -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-14

(d) I think I don't quite get Fig. 11 on p. 25: Shouldn't A cap B exactly lose the blue observation, as we confidently know it is not within the coverage of B?

=> "Example 2 in the figure illustrates just one of the cases mentioned in paragraph 7.3. If the intersection is calculated at the best resolution (MOC B), the resulting MOC may lose some observations from the MOC of lower resolution (blue observation of MOC A)" -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-14

(e) "The possibilities are then very interesting and could be a very valuable astronomical tool." -- that is certainly true, but since we fortunately don't have to do marketing in IVOA specs, I'd probably just drop the sentence. Or, if you want to keep it, at least replace the lawyer-hedging "could" with a plain "will".

=> "will" adopted -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-14

(f) p. 30, the getMicrosec function: It's missing a closing curly brace, and it's not clear to me what the offset does here (in days? why would anyone want that?) -- and what, if not 8.64e10, DAYMICROSEC should be. I'd either drop the source code (I think the spec is clear on what to do, modulo numerics) or write a bit more about it.

=> This suggested algorithm is important to limit the precision errors that a developer can easily fall into. But indeed, the paragraph was not enough clear. We are rewording this point in this annexe in a more detailed way. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-14

(g) p. 31, caption for table 5: The TMOCs are probably not derived from the central position but rather from t_min and t_max, right? If you fix this, you probably should also fix the caption for the STMOC table.

=> Right! Wrong copy/paste. We have corrected the labels of the table 5,6 and 7 -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-14

-- MarkusDemleitner - 2021-11-18

Comments from TCG member during the RFC/TCG Review Period: 2021-11-01 - 2021-12-17

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

MOC-2.0 is a valuable major release of the Multi-Order Coverage standard that adds the time axis tessellation alongside the already widely used spatial one. Time addition continues to be a priority in IVOA standards. Comments from the community have been taken into account, reference implementations and validation are in place as well. TCG is fine in pushing this version further up the Recommendation path.

-- JanetEvans, MarcoMolinaro - 2022-03-10

Applications Working Group

Having been involved throughout the evolution of this document, the Apps working group is pleased with its current state and approves.

-- TomDonaldson - 2022-03-10

Data Access Layer Working Group

Questions or clarification requests

• §1 Should "IVOA architecture (Arviset and Gaudet et al., 2010)" refer to the v2 architecture document now?

• §3.1 fig 6 - the text in the circle is not visible even on a zoomed in view. The pattern in the zoomed section doesn't appear to match the shape in the image

• §5.2 Fig 10 is not referred to in the text and I am unclear on what it is showing. It needs a more detailed description.

• §7.2 This section is unclear to me. Could you explain under what circumstances reducing resolution is desirable please?

• HTML version:

  • some figure legends (fig. 3, 6, 7, 8, 9, 10) seem to be badly converted (ex: fig. 3 ; center,caption=Intersection of HST ACS observations and Saturn ephemeris Space-Time-MOC,label=fig:stmoc-saturn, nofloat=figure,vspace=)

  • incorrect figures numbering (probably because of the 1st point)

=> The generation of HTML from Latex is a new surprise every time We will try to fix it. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-11

Minor Edits

• §1 "is an extension of a major release of the already" can that be made more succinct?

• §3.2 which -> where in "we need to use a discrete time axis which each unit element of this axis has a constant duration"
• §3.3 performances -> performance
• 3.3 "in which at at given" -> "in which at a given" (also in Fig 8 caption)
• §5.2 "coded in in a list of" remove in
• §7.2 "In order to handle easily MOCs" -> "In order to easily handle MOCs"
• §7.3 "handle efficiently observation coverages" -> "efficiently handle observation coverages"

• §B.2 end bracket after shift is wrong way around [ -> ]
• §B.3 end bracket after shift is wrong way around [ -> ]
• §B.4 All end brackets are wrong way around [ -> ]

• §E tables 4-7 should be referred to in the text

-- JamesDempsey - 2022-02-19

-- GregoryMantelet - 2022-02-19

Data Model Working Group

I appreciated the combination of normative parts and didactic efforts in this document.
I've however a few minor comments:

- P1 front page: Why do some authors have a clickable name and some others not

=> latex2html strange behavior. No more clickable -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-11

- P2 Abstract last word: "Major evolution of the MOC standard" instead of "new standard"

=> Ok. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-11

- P5 section 1: "major release" instead of "extension of a major release"

=> Ok. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-11

- P8 section 2.2: " a reference or a footnote pointing on tools or frameworks implementing SQL by-MOC searches would be very helpful for the new comer in this field.

=> The extension of TAP to support MOC queries is in the very early project stage and the already existing "query-by-MOC" implementations (CDSquerycat, MocServer, others...) do not seem to be sufficiently "standard" to be cited in a IVOA standardisation document. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-22

- P8 section 2.3: A footnot giving the MocPy porject URL would be very helpful as above

=> done. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-11

- P9 section 2.4: I not sure anyone knows whatr ET is: a ref or a URL would be nice as well.

=> The acronym ET for Einstein Telescope is provided in the previous sentence in the paragraph. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-11

- P10 section 3 bullet 2: I had an hesitation to get wheter IVRS:PCB. are mandatory (normative) or whether they are given as example. If they are normative this must be clearly stated: "ICRS and TCB are set as unique referential...."

=> To avoid possible ambiguity, we simply delete the parenthesis. The ICRS and TCB choices are indeed clearly described in the normative part.-- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-11

- P11 section 3.1: References or foot notes on Q3C and HTM would help

=> Already debated among the authors and contributors, and the final decision was not to multiply the bibliographic references -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-11

- P14 section 3.2: The lowset time resolution is 73000 years, which is a very short duration for e.g. stellar phenomema. I understand that this range is consrained by the 63 bits, but a little sentence giving the rationale for a choice definitely focused on short astronomical durations would be appreciated.

=> The convention chosen for the time coding was widely discussed in the WG. In such a standardisation document, the sentence in the paragraph seems sufficient to justify the final decision.

- P19 RANGE packaging: It is said that the ranges are stored "2 64-bits integer" ... " in a single columns" Is that a column with 2D vectors? Not clear to me, can this be clarified?

=> The key phrase in this paragraph has been clarified: this is indeed a table with a single column. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-11

- P21 Example of ASCII STMOC. The example contains the 61/6 item which detailed beneath as 61/3

=> Good point. Fixed -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-11

- P21 Section 5.2: I do not understand how STMOC items are split in table columns. Is there just one columns containing vectors? How are you dealing with the variable length of the rows?

=> See clarification on P19 (same remark) -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-11

-- LaurentMichel - 2022-02-28

Grid & Web Services Working Group

The MOC 2.0, is a very effective and useful update of the standard. I do not have any particular complain from the GWS point of view.

I noticed that in the html version of the document there are no pictures and images.

=> The generation of HTML from Latex is a new surprise every time We will try to fix it. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-03-11

Registry Working Group

With the standard version update to 2.0 and move to GitHub, the registry resource for the standard itself (already in RofR as ivo://ivoa.net/std/MOC) should be updated and included in the ivoa-std repository as a .vor file at the top level. This will be used to update the RofR upon REC. I can make a PR for this myself if there is a branch for it, or would be happy to review others' updates.

=> MOC2.0 ensures full backward compatibility. It does not seem necessary to evolve the associated standardID. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-14

Another registry note: section 2.5 speaks of discovery across services through MOCs. With VODataService 1.2, there is now at least spatial MOC support in registries with an eye toward expanding that to include temporal coverage. A very short note about this new search strategy would fit well here.

=> Good suggestion. We add a reference to VODataService in section 2.5 -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-14

On the whole, this is extremely well explained and illustrated, both in figures and in examples on multiple platforms. My following comments are on the level of copyediting suggestions where I found wording a little difficult, and would not block my approval of the document.

2.3 This approach permits to depict the approximate timeline
..permits us?

=> Ok. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-14

3. Because of current technological possibilities, to operate efficiently, we are limiting to encode any pair (order, index) on 64 bits (a long), (in fact only 62 bits since we are using one bit for distinguishing space from time in binary encoding and one bit for future usage)
...this could use a bit of reworking, no specific suggestion for better.

=> Rephrased as "To work efficiently on existing hardware, we impose the encoding of any pair (order, index) on a long integer (64 bits), the two most significant bits are reserved to encode the type of MOC (spatial, temporal, or even futur type of MOC)" -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-14

-- TheresaDower - 2021-11-17

Thanks for the updates! One remaining issue is still the RofR standard item: http://rofr.ivoa.net/oai?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://ivoa.net/std/MOC still notes the 2014 date and endorsed version and doesn't credit Ada, among others. I don't mind adding the updated standard file in GitHub and coordinating with RofR myself, can we just make this one change for curation / provenance sake? -- TheresaDower - 2022-01-26

This is now resolved per https://github.com/ivoa-std/MOC/pull/19, thank you! -- TheresaDower - 2022-02-01

Semantics Working Group

At least as long as MOCs are fixed to ICRS and TCB, the Semantics WG appears to be unconcerned by this specification. We have an open discussion on whether we should have a UCD identifying columns or params that contain MOCs (probably in addition to having a VOTable xtype MOC). Do the authors have any opinion on this?

=> As mentioned, there is already a suitable xtype, but no really suitable UCD. It would probably make sense to create a new one to describe any "coverage" not only necessary MOC. We have no further suggestions at this stage. -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-14

-- MarkusDemleitner - 2021-11-18

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

MOC2 will be a very useful tool to explore complex datasets and, in particular, will provide an access point to space-time evolution of archival datasets.
I look forward to seeing it widely adopted.

Thanks,

- Raffaele

Operations Interest Group

Basically clear and an important evolution of the MOC standard, but a few minor corrections etc:

• Sec 1: "This document is a Working Draft" - it's not any more.

• Sec 2: "within a given window time" -> "within a given time window"?

• Sec 3.1: Remove sourceforge and JPL URLs from text? They may not be long-lived and are probably easy to discover. But if not, correct "http:healpix.jpl.nasa.gov" to "http://healpix.jpl.nasa.gov/".

• Sec 3.2: The abbreviation "(TCB)" is used for both Barycentric Coordinate Time and Barycentric Dynamic Time. I think it should be "(TDB)" for the latter.

• Sec 4.1.1: "the 4 sub-cells of cells M" -> "the 4 sub-cells of cell M".

• Sec 4.3.1: "For lower orders these UNIQ values can be stored in a 32-bit signed integer (TFORM1='J')" - can you add text here making explicit what range of orders can be stored in 32 bits?

• Sec 4.3.1, 4.3.2: The term "well-formed" is stated as a requirement before it has been defined. Add a reference where the term is first used to sec 7.1?

• Sec 4.3.2 EBNF:
  • There's no reference here to which variant of the EBNF syntax is in use, can one be added?
  • However I can guess what most of the syntax means except for the term "int?" - what does the question mark mean? It doesn't seem like that should be an optional element.
  • A note following the EBNF says that a preceding character "t" or "s" is permitted - I think that should be included in the EBNF moc production itself.

=> Correction of the 6th EBNF rule by removing the erroneous '?' -- Pierre Fernique, Ada Nebot, Daniel Durand - 2022-01-20

• Sec 5.2: The example relating to Figure 10 starts "tmin1 tmax2 smin1 smax1 tmin2 tmax2...". I think that should read "tmin1 tmax1 smin1 smax1 tmin2 tmax2..." (if not I don't understand the example).

• Sec 8: "The SMOC is simply defined as a list of HEALPix indices" ... "The TMOC is simply a list of time interval indices": shouldn't those statements refer to lists of (order,index) pairs rather than just of indices?

• Appendix F: "If the spatial or temporal orders of the last "order":[index,index,...] pair is lower than the respective spatial or temporal MOCORDER...": I think "last" should read "highest" .

-- MarkTaylor - 2021-12-16

Thank you authors for fixes, all my comments have now been addressed -- MarkTaylor - 2022-01-24

Radio Astronomy Interest Group

• VO services for radio data will make use of STMOC. Also needed for evolution of simple DAL services. so full support of the group !
• Page 14 : the so called "reference systems for measuring time" are actually "time scales" as stated at page 17 (in 4.2). They actually define what a "second" is. The reference position or "position of the observer" is something different in general although TCB seems to work only with BARYCENTER. The reference quoted page 14 is actually for TDB, not for TCB. Why not use http://hea-www.cfa.harvard.edu/~arots/TimeWCS/WCSPaper-IV-v1.1A4.pdf which details all these concepts ?

• page 15 : Table 2 is showing some time "accuracies" at a given order

• page 17. 4.2 better speak of Solar System Barycenter.

• page 18 : 4.2.1. Seems to me that the order N-1 cell duration is 2 times MORE than the N Cell duration and not "2 times less".

• same typo "an" instead of "a" . page 6 "an MOC". page 10 "an hierachical". page 24 "an MOC".

• page 9. Figure 4 caption. Is it really a "mock follow up" or a "moc follow up" ? Mock is a word for simulated data. Not sure to understand what you mean here.

Solar System Interest Group

I have no comments to make that have not already been made and addressed by others. I look forward to seeing the applications that arise from the TMOC and STMOC additions...

-- AnneRaugh - 2022-01-25

Theory Interest Group

Time Domain Interest Group

BM: The MOC 2.0 standard is excellent work. I look forward to it being used to unlock more advanced searching and filtering capabilities of astronomical datasets.

While not necessarily relevant for the current document, I wonder whether it may make sense to consider adding/extending support in the future for other queryable quantities.

These could be sourced from obscore or elsewhere.

From a time domain perspective these might include:

* the number of time series observations (t_xel) which could be useful in querying against all sky surveys with complex observation patterns (e.g. ZTF, LSST).

* the time resolution of observations (t_resolution) which could help query against data with a required cadence

* the exposure time (t_exptime) which could be used similarly to t_xel to identify areas with deep enough observations

Perhaps it is sufficient to just filter results after an STMOC match, but for some more commonly used quantities it may be worthwhile considering whether they can be incorporated into the standard or helper functions could be incorporated into existing MOC libraries.

The above may already be supported in the current library, e.g. creating a union of the t_xel all sky map with the spatial component of the STMOC. If this is the case it may be useful to incorporate such time domain use cases in to the reference document or tutorials accompanying MOC libraries.

Standards and Processes Committee

TCG Vote : 2022-01-26 - 2022-02-11

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.