Difference: MOC1RFC (11 vs. 12)

Revision 122014-04-25 - JesusSalgado

 
META TOPICPARENT name="IvoaApplications"

MOC v1.0: Proposed Recommendation: Request for Comments

Changed:
<
<		This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310
>
>		This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310
 
Versions under review
PR-MOC-1.0-20140106 (for RFC), PR-MOC-20140310 (for TCG review)
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 :

-- PierreFernique - 2014-02-06

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

Changed:
<
<
  • 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?
>
>
  • 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
Changed:
<
<
    • What is the meaning of the coloured figure that appears in the label of the tables? (Appendix B)
>
>
    • 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
Changed:
<
<
    • Pag. 14, Sec 3.3 "MOC Examples"
>
>
    • Pag. 14, Sec 3.3 "MOC Examples"
 

Changed:
<
<		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.
>
>		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 )

Applications Working Group ( _Mark Taylor, Pierre Fernique )

Changed:
<
<		Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10
>
>		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

Changed:
<
<
  • 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.
>
>
  • 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.
Deleted:
<
<
 -- FrancoisBonnarel - 2014-04-25

Data Model Working Group ( _Jesus Salgado, Omar Laurino )

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

 

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

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )

Semantics Working Group ( _Norman Gray, Mireille Louys )

MOC notes

Changed:
<
<		The idea of a MOC is clearly a useful one, and there is no intersection that I
>
>		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.
Deleted:
<
<		can see between the Proposed Recommendation and current Semantics WG work.
 
Changed:
<
<		However I think this document may need a little work. It doesn't needs
>
>		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.
Deleted:
<
<		rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text.
 
Changed:
<
<		I'm reasonably confident I understand what MOC is, after reading the
>
>		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.
Deleted:
<
<		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.
 
Changed:
<
<		Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any
>
>		Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are.
Deleted:
<
<		explanation of what they are.
 
Changed:
<
<		From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the
>
>		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.
Deleted:
<
<		cells are numbered in some way yet to be explained; an example would be useful here.
 
Changed:
<
<		Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to
>
>		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"?
Deleted:
<
<		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"?
 
Changed:
<
<		Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea
>
>		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.
Deleted:
<
<		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.

Changed:
<
<		It might be useful to say explicitly, in Sect. 1.1, that a MOC is
>
>		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.
Deleted:
<
<		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:
Changed:
<
<
  • Sect. 1.2, Examples. It's not clear to me what the choice of images is
>
>
  • 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.
Deleted:
<
<		 illustrating, nor how the image and the MOC map relate to each other.
 
  • There are no page numbers
Changed:
<
<
>
>
 
  • Sect 1.4.1 refers to 'figure 1.2', but the figures in the document are not numbered.
Changed:
<
<
  • Sect 2.2.2: the explanation here is, I think, too compact to let the reader
>
>
  • 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.
Deleted:
<
<		 understand the 'nested' encoding. It would probably be best to refer the reader to [1, Sect. 4.2] for the explanation.
 
Changed:
<
<
  • Sect. 2.3: the 'nuniq' coding method isn't defined in [1], and the
>
>
  • 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.
Deleted:
<
<		 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.
 
Changed:
<
<
  • Sect. 2.3 again: this section mentions in passing that "The FITS
>
>
  • 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.
Deleted:
<
<		 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.
 
Changed:
<
<
  • Sect. 1.5.1: 'This choice allows to reduce the size of a MOC “by factorizing
>
>
  • 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.
Deleted:
<
<		 adjacent cells”' It is not clear what the quoted phrase means.
 -- NormanGray - 2014-04-07

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)

Deleted:
<
<
  
<--  
-->
View topic | History: r22 < r21 < r20 < r19 | More topic actions...
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback