MOC v1.0: Proposed Recommendation: Request for Comments

This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-1.0-20140512

• Versions under review:
  • PR-MOC-1.0-20140106 (initial RFC)
  • PR-MOC-20140310 (initial TCG review)
  • PR-MOC-1.0-20140422 (following TCG comments by Norman et al.)
  • PR-MOC-1.0-20140512 (following further minor typographical comments; this version is approved by all WGs and is for consideration by Exec)

RFC Review Period

7 February 2014 - 7 March 2014

TCG Review Period

11 March 2014 - 8 April 2014

Reference Interoperable Implementations

MOC 1.0 has been implemented in the following software items :

• MOC Java API integrated in STIL, TOPCAT [starlink], and Aladin (since v7.5)[CDS]
• Sitools2/MIZAR [CNES]: Javascript implementation of MOC loading function and displaying function (sources).

Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014

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

• Comment by EnriqueSolano
  • Is MOC intersection and/or union possible from Aladin/TOPCAT? If not, are there plans to implement this capability in the near future?
    • Aladin yes in v8 (Coverage menu); TOPCAT/STILTS no, but maybe one day
  • What is the meaning of the coloured figure that appears in the label of the tables? (Appendix B)
    • It is just a density map illustrating the density of the sources. -- Pierre
  • Pag. 14, Sec 3.3 "MOC Examples"
    • Should you want to include examples of data centres (others than VizieR) providing MOCs, you can point at our GTC and Calar Alto archives:
    • http://gtc.sdc.cab.inta-csic.es/gtc/jsp/searchform.jsp
    • http://caha.sdc.cab.inta-csic.es/calto/jsp/searchform.jsp
• Response (by WikiName)

Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310.

-- MarkTaylor - 2014-03-10

Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard.

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

TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )

Approved.

Applications Working Group ( _Mark Taylor, Pierre Fernique )

Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10

Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )

I propose to validate the standard from the DAL WG point of vue. Some remarks below

• MOC doesn't imply any current dependancy to the emerging or past standards. However it could be usefull in the future to add "MOC" has one of the possible descriptions of ROI in SIAV2 or "shape to match" in AccesData POS parameter. This cannot be done before NEXT version of the two standards (SIAV2 1.1 and AccessData 1.1) so next year in the best case. Description of datasets supports in ObsTap , SIAV2 or whatever DAL discovery standard Query responses could also be done using MOCs as an optional format in the future. For next versions also.

• A couple of Norman's remarks could easilly be solved by a clear quotation of HEALPIX references at the right place in the text.

Data Model Working Group ( _Jesus Salgado, Omar Laurino )

MOC is a very clever idea and it can be used on different IVOA contexts (fast querying, overall description, mission coverage description, prevent null queries,... etc). I have tested and used it in different contexts and VO applications and it has been proved as a very useful format.

I also miss, as pointed by Norman, a clear definition of what is a MOC in the text. Is is assumed that MOC is a serialized way (in different formats) of npix HEALPix indexes at different orders that characterize the coverage of a certain dataset (mission, catalogue, etc) and it would be useful to have this defintion in the text written by the experts. Some other clarifications pointed by Norman comments will allow external developers to fully understand the format.

If a new version is going to be created following some of this clarifications, I will wait for it before to provide the official approval.

-- JesusSalgado - 2014-04-25

The new version is a lot more clearer. DM recommend this spec for acceptance.

-- JesusSalgado - 2014-05-12

Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )

The Grid and Web Services WG approves this document.

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )

I appreciate the effort to continue to work with Healpix and to describe the use of Healpix as a coverage map. My main concern is that the IVOA is proposing a standard that is promoting 1 spherical geometric algorithm and implementation and this is not representative of other key large datasets in the community (at least the originating source data provider version, i'm not referring to cloned datasets that have been tesselated to support a MOC infrastructure. The paper has all the correct elements for description of MOC and is nicely structured and could be used a a more general format for standard for other data systems. The most obvious is HTM. The MOC standard could be generically described for more than 1 spherically geometry and perhaps STC providing footprint coverage standardization across more astronomical data providers.

I do not want to prevent the document for moving forward, yet encourage to give some thought to a more generic MOC is multi order coverage standard with Healpix as one form of geometric representation.

I did not see an example how the MOC would be captured in the registry metadata for discovery as we had discussed at the Heidelberg meeting, my understanding as that we could use the existing footprint metadata as initial placement. Naming conventions for MOC?

It is good to express the limitations of MOC, so that i appreciate the explanation included in the document. What i would like to encourage us to do is to define a footprint standard that can provide coverage in more representation that 1 tesselation scheme to represent a region on the sky. Region intersection and union operations should be implementation agnostic.

Registry Working Group approves this document yet requests consideration of the comments in support of generic MOC representations and data discovery in the registry.

GretchenGreene 05/12/2014

Gretchen, thank you for your approval. To respond briefly to your concerns and clarify the intent of this document: the document is simply a definition of the HEALPix-based MOC format. It does not aspire to be the VO's one-size-fits-all response to the question of how to characterise sky coverage. It also deliberately does not address the question of whether or how MOCs might be used in conjunction with the registry. The question of how best to characterise sky coverage in the registry is an important one, and MOC may have a part to play, but that's a matter for future discussion within the Registry WG. -- MarkTaylor - 2014-05-14

Semantics Working Group ( _Norman Gray, Mireille Louys )

MOC notes

The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work.

However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text.

I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done.

Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are.

From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here.

Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"?

Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful.

Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs!

This puzzlement is probably rather easy to fix.

It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward.

Exposition:

• Sect. 1.2, Examples. It's not clear to me what the choice of images is illustrating, nor how the image and the MOC map relate to each other.

• There are no page numbers

• Sect 1.4.1 refers to 'figure 1.2', but the figures in the document are not numbered.

• Sect 2.2.2: the explanation here is, I think, too compact to let the reader understand the 'nested' encoding. It would probably be best to refer the reader to [1, Sect. 4.2] for the explanation.

• Sect. 2.3: the 'nuniq' coding method isn't defined in [1], and the explanation here is too compact to be intelligible. Is the 'single binary table' a single-column table? Given that the document has previously explained the 'nested' and insisted that "MOC must use the NESTED numbering scheme only", it would be useful to explain here why the document is apparently switching to the 'nuniq' numbering scheme. Again, an example would be useful, of the encoded MOC, rather than just of the FITS headers.

• Sect. 2.3 again: this section mentions in passing that "The FITS values must be fully sorted" -- I presume this means that the cell numbers within a MOC should be sorted in order of increasing 'uniq' number, since nowhere else is the sort order defined. If this is indeed the intended order for a MOC list in whatever representation, then this should perhaps be made clear earlier -- in this location it appears to be simply a detail of the storage of a MOC within a FITS file.

• Sect. 1.5.1: 'This choice allows to reduce the size of a MOC “by factorizing adjacent cells”' It is not clear what the quoted phrase means.

Norman, thank you for these useful comments. We have added a new "worked" example section 1.2 and slightly reorganised section 2.3, along with one or two more minor changes. We hope this does a better job of introducing the concepts and explaining what a MOC is early in the document, and reduces confusion about how the different concepts fit together. An intermediate draft incorporating these changes is PR-MOC-1.0-20140422 (also linked at the top of this page).

-- MarkTaylor, PierreFernique - 2014-05-06

This amended version looks great to me -- the result is much clearer, and I believe that if I were trying to implement this, based only on this document, I could do that. I have separately passed to the authors a set of minor typographical fixes. I approve this version (or minor edits thereof) on behalf of the Semantics WG.

-- NormanGray - 2014-05-10

Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )

Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )

Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )

Knowledge Discovery in Databases Interest Group ( George Djorgovski )

Theory Interest Group ( _Franck Le Petit, Rick Wagner )

Standards and Processes Committee ( Françoise Genova)