Difference: MOC1RFC (1 vs. 22)

Revision 222014-05-18 - MarkTaylor

 
META TOPICPARENT name="IvoaApplications"

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

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

  • 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"
  • 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.
-- FrancoisBonnarel - 2014-04-25

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.
-- NormanGray - 2014-04-07

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)

<--  
-->

META FILEATTACHMENT attachment="PR-MOC-1.0-20140422.pdf" attr="" comment="Revision following some TCG comments" date="1399376686" name="PR-MOC-1.0-20140422.pdf" path="PR-MOC-1.0-20140422.pdf" size="881853" user="MarkTaylor" version="1"
Changed:
<
<
META FILEATTACHMENT attachment="PR-MOC-1.0-20140512.pdf" attr="" comment="Approved PR for consideration by Exec" date="1400198376" name="PR-MOC-1.0-20140512.pdf" path="PR-MOC-1.0-20140512.pdf" size="881558" user="MarkTaylor" version="1"
>
>
META FILEATTACHMENT attachment="PR-MOC-1.0-20140512.pdf" attr="" comment="Approved PR for consideration by Exec (with adjusted architecture diagram)" date="1400418111" name="PR-MOC-1.0-20140512.pdf" path="PR-MOC-1.0-20140512.pdf" size="1281039" user="MarkTaylor" version="2"
 

Revision 212014-05-17 - SeverinGaudet

 
META TOPICPARENT name="IvoaApplications"

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

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

  • 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"
  • 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 )

Added:
>
>
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.
-- FrancoisBonnarel - 2014-04-25

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.
-- NormanGray - 2014-04-07

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)

<--  
-->

META FILEATTACHMENT attachment="PR-MOC-1.0-20140422.pdf" attr="" comment="Revision following some TCG comments" date="1399376686" name="PR-MOC-1.0-20140422.pdf" path="PR-MOC-1.0-20140422.pdf" size="881853" user="MarkTaylor" version="1"
META FILEATTACHMENT attachment="PR-MOC-1.0-20140512.pdf" attr="" comment="Approved PR for consideration by Exec" date="1400198376" name="PR-MOC-1.0-20140512.pdf" path="PR-MOC-1.0-20140512.pdf" size="881558" user="MarkTaylor" version="1"

Revision 202014-05-16 - MarkTaylor

 
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-1.0-20140422
>
>
This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-1.0-20140512
 
Added:
>
>
    • 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 :

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

  • 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"
  • 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 )

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.
-- FrancoisBonnarel - 2014-04-25

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.
-- NormanGray - 2014-04-07

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)

<--  
-->

META FILEATTACHMENT attachment="PR-MOC-1.0-20140422.pdf" attr="" comment="Revision following some TCG comments" date="1399376686" name="PR-MOC-1.0-20140422.pdf" path="PR-MOC-1.0-20140422.pdf" size="881853" user="MarkTaylor" version="1"
Added:
>
>
META FILEATTACHMENT attachment="PR-MOC-1.0-20140512.pdf" attr="" comment="Approved PR for consideration by Exec" date="1400198376" name="PR-MOC-1.0-20140512.pdf" path="PR-MOC-1.0-20140512.pdf" size="881558" user="MarkTaylor" version="1"
 

Revision 192014-05-14 - MarkTaylor

 
META TOPICPARENT name="IvoaApplications"

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

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

  • 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"
  • 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 )

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.
-- FrancoisBonnarel - 2014-04-25

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

Added:
>
>
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.
-- NormanGray - 2014-04-07

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)

<--  
-->

META FILEATTACHMENT attachment="PR-MOC-1.0-20140422.pdf" attr="" comment="Revision following some TCG comments" date="1399376686" name="PR-MOC-1.0-20140422.pdf" path="PR-MOC-1.0-20140422.pdf" size="881853" user="MarkTaylor" version="1"

Revision 182014-05-13 - GretchenGreene

 
META TOPICPARENT name="IvoaApplications"

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

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

  • 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"
  • 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 )

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.
-- FrancoisBonnarel - 2014-04-25

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 )

Added:
>
>
 The Grid and Web Services WG approves this document.

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )

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

 

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.
-- NormanGray - 2014-04-07

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)

<--  
-->

META FILEATTACHMENT attachment="PR-MOC-1.0-20140422.pdf" attr="" comment="Revision following some TCG comments" date="1399376686" name="PR-MOC-1.0-20140422.pdf" path="PR-MOC-1.0-20140422.pdf" size="881853" user="MarkTaylor" version="1"

Revision 172014-05-12 - AndreSchaaff

 
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
>
>
This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-1.0-20140422
Deleted:
<
<
PR-MOC-1.0-20140422
 
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

  • 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"
  • 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 )

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.
-- FrancoisBonnarel - 2014-04-25

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 )

Added:
>
>
The Grid and Web Services WG approves this document.
 

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )

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.
-- NormanGray - 2014-04-07

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)

<--  
-->

META FILEATTACHMENT attachment="PR-MOC-1.0-20140422.pdf" attr="" comment="Revision following some TCG comments" date="1399376686" name="PR-MOC-1.0-20140422.pdf" path="PR-MOC-1.0-20140422.pdf" size="881853" user="MarkTaylor" version="1"

Revision 162014-05-12 - MarkTaylor

 
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
Added:
>
>
PR-MOC-1.0-20140422
 
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

  • 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"
  • 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 )

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.
-- FrancoisBonnarel - 2014-04-25

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 )

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )

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.
-- NormanGray - 2014-04-07

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)

<--  
-->

META FILEATTACHMENT attachment="PR-MOC-1.0-20140422.pdf" attr="" comment="Revision following some TCG comments" date="1399376686" name="PR-MOC-1.0-20140422.pdf" path="PR-MOC-1.0-20140422.pdf" size="881853" user="MarkTaylor" version="1"

Revision 152014-05-12 - JesusSalgado

 
META TOPICPARENT name="IvoaApplications"

MOC v1.0: Proposed Recommendation: Request for Comments

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

Changed:
<
<
  • Versions under review:
>
>
  • Versions under 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

  • 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"
  • 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 )

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

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

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

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )

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.
-- NormanGray - 2014-04-07
Changed:
<
<
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).
>
>
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
Changed:
<
<
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.
>
>
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)

<--  
-->

META FILEATTACHMENT attachment="PR-MOC-1.0-20140422.pdf" attr="" comment="Revision following some TCG comments" date="1399376686" name="PR-MOC-1.0-20140422.pdf" path="PR-MOC-1.0-20140422.pdf" size="881853" user="MarkTaylor" version="1"

Revision 142014-05-10 - NormanGray

 
META TOPICPARENT name="IvoaApplications"

MOC v1.0: Proposed Recommendation: Request for Comments

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

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

  • 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"
  • 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 )

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.

-- FrancoisBonnarel - 2014-04-25

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

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

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.
-- NormanGray - 2014-04-07

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

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

<--  
-->

META FILEATTACHMENT attachment="PR-MOC-1.0-20140422.pdf" attr="" comment="Revision following some TCG comments" date="1399376686" name="PR-MOC-1.0-20140422.pdf" path="PR-MOC-1.0-20140422.pdf" size="881853" user="MarkTaylor" version="1"

Revision 132014-05-06 - MarkTaylor

 
META TOPICPARENT name="IvoaApplications"

MOC v1.0: Proposed Recommendation: Request for Comments

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

Changed:
<
<
Versions under review
PR-MOC-1.0-20140106 (for RFC), PR-MOC-20140310 (for TCG review)
>
>
  • Versions under review:
Added:
>
>
 
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

  • 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"
  • 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 )

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.

-- FrancoisBonnarel - 2014-04-25

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

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

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.
-- NormanGray - 2014-04-07
Added:
>
>
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

 

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)

<--  
-->
Added:
>
>
META FILEATTACHMENT attachment="PR-MOC-1.0-20140422.pdf" attr="" comment="Revision following some TCG comments" date="1399376686" name="PR-MOC-1.0-20140422.pdf" path="PR-MOC-1.0-20140422.pdf" size="881853" user="MarkTaylor" version="1"
 

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

Revision 112014-04-25 - FrancoisBonnarel

 
META TOPICPARENT name="IvoaApplications"

MOC v1.0: Proposed Recommendation: Request for Comments

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

  • 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"
  • 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 )

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 )

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

-- FrancoisBonnarel - 2014-04-25

 

Data Model Working Group ( _Jesus Salgado, Omar Laurino )

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

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.

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

<--  
-->

Revision 102014-04-07 - NormanGray

 
META TOPICPARENT name="IvoaApplications"

MOC v1.0: Proposed Recommendation: Request for Comments

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

  • 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"
  • 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 )

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 )

Data Model Working Group ( _Jesus Salgado, Omar Laurino )

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

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )

Semantics Working Group ( _Norman Gray, Mireille Louys )

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

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

<--  
-->

Revision 92014-03-10 - MarkTaylor

 
META TOPICPARENT name="IvoaApplications"

MOC v1.0: Proposed Recommendation: Request for Comments

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

  • 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"
  • 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 )

Applications Working Group ( _Mark Taylor, Pierre Fernique )

Added:
>
>
Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10
 

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

Data Model Working Group ( _Jesus Salgado, Omar Laurino )

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

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )

Semantics Working Group ( _Norman Gray, Mireille Louys )

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)

<--  
-->

Revision 82014-03-10 - MarkTaylor

 
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. The RFC is announced on 7 February 2014 and will run until 7 March 2014.
>
>
This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310
 
Changed:
<
<
Latest version of MOC v1.0 can be found at:
>
>
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
Added:
>
>
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

  • 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"
  • Response (by WikiName)


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


Added:
>
>

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 )

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

Data Model Working Group ( _Jesus Salgado, Omar Laurino )

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

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )

Semantics Working Group ( _Norman Gray, Mireille Louys )

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)

 
<--  
-->

Revision 72014-03-10 - MarkTaylor

 
META TOPICPARENT name="IvoaApplications"

MOC v1.0: Proposed Recommendation: Request for Comments

This page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on 7 February 2014 and will run until 7 March 2014.

Latest version of MOC v1.0 can be found at:

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

  • 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"
  • Response (by WikiName)
Added:
>
>

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

 

<--  
-->

Revision 62014-02-10 - MarkTaylor

 
META TOPICPARENT name="IvoaApplications"

MOC v1.0: Proposed Recommendation: Request for Comments

This page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on 7 February 2014 and will run until 7 March 2014.

Latest version of MOC v1.0 can be found at:

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:
<
<
  • Sample comment by EnriqueSolano
>
>
  • 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?
Added:
>
>
      • 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)
Added:
>
>
      • It is just a density map illustrating the density of the sources. -- Pierre
 


<--  
-->

Revision 52014-02-07 - EnriqueSolano

 
META TOPICPARENT name="IvoaApplications"

MOC v1.0: Proposed Recommendation: Request for Comments

This page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on 7 February 2014 and will run until 7 March 2014.

Latest version of MOC v1.0 can be found at:

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:
<
<
>
>
  • Sample 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?
Added:
>
>
 

<--  
-->

Revision 42014-02-07 - MarkTaylor

 
META TOPICPARENT name="IvoaApplications"

MOC v1.0: Proposed Recommendation: Request for Comments

This page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on 7 February 2014 and will run until 7 March 2014.

Latest version of MOC v1.0 can be found at:

Reference Interoperable Implementations

MOC 1.0 has been implemented in the following software items :

-- PierreFernique - 2014-02-06
Changed:
<
<

RFC Review Period: RFC_start_date - RFC_end_date

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

>
>

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


<--  
-->

Revision 32014-02-06 - PierreFernique

 
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. The RFC is announced on XX January 2014 and will run until XX February 2014.
>
>
This page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on 7 February 2014 and will run until 7 March 2014.
  Latest version of MOC v1.0 can be found at:
Changed:
<
<
  • URL link to the document
>
>
 

Reference Interoperable Implementations

MOC 1.0 has been implemented in the following software items :

Changed:
<
<
>
>
-- PierreFernique - 2014-02-06
Deleted:
<
<
-- PierreFernique - 2014-01-14
 

RFC Review Period: RFC_start_date - RFC_end_date

Changed:
<
<

Comments from the IVOA Community during RFC period: RFC_start_date - RFC_end_date

>
>

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


<--  
-->

Revision 22014-01-14 - PierreFernique

 
META TOPICPARENT name="IvoaApplications"
Changed:
<
<

IVOASTANDARD Proposed Recommendation: Request for Comments

>
>

MOC v1.0: Proposed Recommendation: Request for Comments

 
Changed:
<
<
Feel free to include here an introductory paragraph describing the IVOASTANDARD being addressed here
>
>
This page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on XX January 2014 and will run until XX February 2014.
 
Changed:
<
<
Latest version of IVOASTANDARD can be found at:
>
>
Latest version of MOC v1.0 can be found at:
 
  • URL link to the document

Reference Interoperable Implementations

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

Implementations Validators

(If any, indicate here the links to Implementations Validators)

>
>
MOC 1.0 has been implemented in the following software items : -- PierreFernique - 2014-01-14
Deleted:
<
<
 

RFC Review Period: RFC_start_date - RFC_end_date

Deleted:
<
<

TCG Review Period: TCG_start_date - TCG_end_date



 

Comments from the IVOA Community during RFC period: RFC_start_date - RFC_end_date

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


Deleted:
<
<

 
Changed:
<
<

Comments from TCG member during the TCG Review Period: TCG_start_date - TCG_end_date

>
>

Revision 12014-01-14 - AndreSchaaff

 
META TOPICPARENT name="IvoaApplications"

IVOASTANDARD Proposed Recommendation: Request for Comments

Feel free to include here an introductory paragraph describing the IVOASTANDARD being addressed here

Latest version of IVOASTANDARD can be found at:

  • URL link to the document

Reference Interoperable Implementations

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

Implementations Validators

(If any, indicate here the links to Implementations Validators)

RFC Review Period: RFC_start_date - RFC_end_date

TCG Review Period: TCG_start_date - TCG_end_date



Comments from the IVOA Community during RFC period: RFC_start_date - RFC_end_date

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 from TCG member during the TCG Review Period: TCG_start_date - TCG_end_date

!!! SECTION TO BE ADDED ONLY ONCE THE TCG REVIEW PERIOD HAS STARTED !!!

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, althought their inputs are not compulsory.

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

Applications Working Group ( _Mark Taylor, Pierre Fernique )

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

Data Model Working Group ( _Jesus Salgado, Omar Laurino )

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

Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )

Semantics Working Group ( _Norman Gray, Mireille Louys )

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)



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