META TOPICPARENT |
name="MocInfo" |
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:
- The String MOC serialization was moved from an informative section (suggested syntax) to the normative section.
- A MOCORDER convention for String MOC and JSON MOC was added.
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.
To see non-trivial examples for ASCII MOCs coming out of a database, run something like
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
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 |