MOC 1.1 Proposed Recommendation: Request for Comments

Summary

Latest Draft: MOC 1.1 (Proposed Recommendation)

The substantive differences between version 1.1 of MOC and the preceding version 1.0 are:

Reference Interoperable Implementations

(Indicate here the links to at least two Reference Interoperable Implementations)

• MOCPy >=0.5.6
• Aladin (>v10.126): read/write ASCII MOC (select ASCII format when exporting MOC - see snapshot below) + new script command dedicated to ASCII MOC (ex: draw MOC 3/1,2,3 4/56-67)
• The relational registry at http://dc.g-vo.org/tap parses the ASCII MOCs in Registry records into the rr.stc_spatial table (consumer)
• DaCHS since version 1.1 produces ASCII MOCs when serialising MOC-values database columns.
• The Moc class within the AST/PyAST WCS library now supports reading and writing ASCII and JSON MOCs in addition to FITS.

select top 100 * from rr.stc_spatial
where 1=contains(point(10, 10), coverage)
and 0=contains(point(20, 20), coverage)

on http://dc.g-vo.org/tap.

Implementations Validators

• This validator is written in Python. It check for valid ASCII MOC syntax and that pixel numbers are in the legal range for thier order: https://volute.g-vo.org/svn/trunk/projects/apps/MOC/

Comments Prior to Official RFC Period

As I was considering semantic validation cases, I noticed this sentence in section 2.3.2:

"Warning: In this basic simple ASCII string format the values may be not sorted, and the MOC may be not well-formed."

which seems to contradict section 2.2.3:

" An encoded MOC must also be “well-formed”. To keep the canonical property of MOC, the redundant cells are not allowed and the hierarchical encoding principle must be respected. Thus it is not allowed to encode 4 sibling cells instead of their parent (only at level 0 for the 12 first diamonds). Using this simple constraint, there is one and only one way to describe a specific region and this makes the interoperability principle easy to implement."

Maybe the former was just a legacy from MOC 1.0 where ASCII MOC was less formal, perhaps intended for hand-crafted MOCs not intended for serious use. With ASCII MOC now being formalized, can we remove that sentence and require that ASCII MOCs must be just as well-formed as their FITS counterparts?

-- TomDonaldson - 2019-06-14

Comments from the IVOA Community during RFC/TCG review period: 2019-06-14 - 2019-07-29

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

• Comment from Carlo Zwölf (CarloMariaZwoelf) : It is not clear for me in this proposed recommendation what comes natively from the Healpix definition and what is the IVOA-specific layer. Is there a way for highlighting this difference in the text?

• Sample comment by WikiName
  • Response (by WikiName)

Comments from TCG member during the RFC/TCG Review Period: 2019-06-14 - 2019-07-29

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

MOC specification changes to bring String serialization to the normative part looks a good addition to this standard. The document itself is fine in general. I have two small things I'd like to point out.

• letting [space,CR,LF,comma], multiples/mixes of them, as the elements separator has a human readability effect (see email), not so alerting, but also requires some code in MOC usage. Isn't it really possible to force a bit this serialization to be more smooth with, at least, single and homogeneous separators throughout a single ASCII MOC? Could it be at least warmly suggested?
• MOCORDER is a MUST and clearly described in the FITS serialization, while in the String (and JSON) one(s) it is less clear how to grab that piece of information. This because it is only said to be a must "If the best HEALPix resolution of the MOC (MOCORDER) is greater than the greatest stored order" (in which case it would be the last token of the String, followed by a slash and no npix). I agree that if it's not so it's implicit the MOCORDER is the last/highest order available, but I'd prefer it to be explicit.

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

The Semantics WG doesn't see anything concerning us in the proposed changes (that otherwise sound reasonable and useful to us). The spurious indent of the rule for moc in the EBNF grammar could be removed, though.

-- MarkusDemleitner - 2019-07-16

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Operations

Mostly OK, but some comments:

• Table of contents: the page numbers are mostly wrong.
• Sec 1.4: The existence of a FITS HEALPix serialization format on which the MOC serialization format is based is claimed, but no reference is given. Since this text (written by Eric Hivon) does now just about exist in a public form https://healpix.sourceforge.io/data/examples/healpix_fits_specs.pdf, can it be referenced here?
• Sec 2.3.1: The HEALPix FITS encoding standard is mentioned here as well: "As the FITS MOC is derived from a more generic standard dedicated to HEALPix maps, the FITS header must contain the following keywords/value." That's a bit misleading, since the MOC serialization is not a special case of the HEALPix encoding (it doesn't contain some of the keywords required by that standard, such as INDEXSCHM and NSIDE) and some of the keywords have values which are not allowed in the HEALPix encoding (ORDERING='NUNIQ'). Given the difference between the two encodings, I'm not sure there's much point making the comparison here, but if so I'd suggest something more like "The following keywords are mandatory and derive from the HEALPix MOC encoding [with a document reference]."
• Sec 2.3.1: The MOCID and ORIGIN keys both "suggest using IVOA identification like ..." where the examples are of the form ivo://... . If these are intended to be IVOA Identifiers, it should say something more like "suggest using an IVOA Identifier ..." with a reference to the IVOA Identifiers document, and the examples given should be valid IVOIDs (i.e. should resolve in the registry - I don't think that "CADC" is an authority in the IVOID sense). If not, the ivo:// prefix seems a bit misleading. Reg WG may want to comment on this.
• Sec 2.3.2: "hightnpix" -> "highnpix" ?
• Sec 2.3.2: I'm inclined to agree with Tom's and Marco's comments about the form of the ASCII MOC serialization - it's not clear to me why FITS MOCs have to be well-formed and ASCII ones don't, and why so many separator choices are allowed. Also, the BNF doesn't constrain where the optional MOCORDER marker has to go, or how many of these appear. Consider constraining this format a bit further, e.g. require the MOCORDER marker to be present and/or at the end (or start?) of the string?
• Appendix B: most of the decimal separators are "." characters, but one is a "," ("1,17").

Standards and Processes Committee

TCG Vote: 2019-06-14 - 2019-07-29

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.

<--
 
 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup 
 
 
-->

• MOC_ASCII_in_Aladin.png: