MOC 2.0 Proposed Recommendation: Request for Comments


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.

Latest version of MOC 2.0 can be found at:

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

Implementations Validators

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

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".
-- TomDonaldson - 2021-11-02

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?

(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."

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

(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?

(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".

(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.

(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.

-- 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

Applications Working Group

Data Access Layer Working Group

Data Model Working Group

Grid & Web Services Working Group

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:// 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.

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.

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?

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.

-- TheresaDower - 2021-11-17

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?

-- MarkusDemleitner - 2021-11-18

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Radio Astronomy Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Standards and Processes Committee

TCG Vote : 2021-11-01 - 2021-12-31

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.

Group Yes No Abstain Comments
Semantics *      

Topic revision: r6 - 2021-11-18 - MarkusDemleitner
This site is powered by the TWiki collaboration platformCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback