Skip to end of metadata
Go to start of metadata

Some candidate decisions to evaluate:

See also  RFC-441 - Getting issue details... STATUS .

1) Adopt the HiPS (Hierarchical Progressive Survey) IVOA Recommendation ( as the basis for the generation of multi-resolution all-sky image data products;

2) Agree to produce, at least, (2a) per-band monochrome HiPS maps based on our existing Level 2 / DRP deep coadd data products, in addition to (2b) a single precomputed project-determined RGB HiPS map (with the details of the colorization perhaps to be agreed between DM and EPO);

3) Consider producing ancillary image-formatted data such as depth maps in HiPS format as well;

4) Establish the generation of these HiPS maps as a part of the annual Data Release Production process;

5) Include the provision of a HiPS-standards-compliant, registered data service as part of the network interface of LSST to the community (subject to further policy and technical consideration of data rights control issues);

6) Explicitly include the ability to visualize HiPS-format image data as a requirement on the LSP Portal;

7) Produce IVOA MOC-format ( coverage maps for the LSST survey coverage (per-DR and possibly also updated daily);

8) Provide HEALPix utilities within the LSST/DM stack software context.


The adoption of HiPS and MOC will explicitly establish HEALPix as an all-sky pixelization scheme within LSST.

The initial set of decisions above do not extend to the immediate, still less exclusive, adoption of HEALPix for other purposes in DM or LSST more widely. For instance, it does not address the use of HEALPix in the generation of Object table contents or indexing (where HTM is currently being used), or in the generation of all-sky summary data quality information (such as the binning of the sky for performing stellar locus photometry QA). It may well be useful and appropriate to migrate to HEALPix for these purposes, but these are questions for a later round of decision-making.

Items for discussion and research

1) The maximum resolution to be provided in the HiPS image maps;

2) Data access rights to the HiPS image maps (This may / will likely be coupled to the decision on the maximum resolution provided; perhaps, technology permitting, we might consider providing world access to data up to a certain resolution, and data-rights-holder access to data finer than that level.);

3) How best to provide a HiPS data service that provides for authentication (if data rights are to be enforced on any or all of the LSST HiPS data);

4) Explore how to provide additional, user-selectable options for multi-band color representations of the LSST image data (taking note of the existing Firefly ability to generate color images on the fly from multiple image sources, and the Aladin group's recent prototype of a demand-driven, server-side ability to synthesize color HiPS maps from multiple monochrome ones);

5) Whether to generate the HiPS image maps by applying the (Java) hipsgen software to our tract/patch-level coadded image data products, or to develop a DM-stack-based (or even Astropy-based) procedure for generating HiPS maps (potentially yielding improved and more quantitatively useful results);

  • Gregory Dubois-Felsmann is experimenting with using hipsgen to build maps from the LSST coadds of the public HSC data release.

6) Whether using hipsgen or our own software, what algorithm to use for the aggregation of pixel data up the HiPS hierarchy;

7) Whether there is a role in DM or EPO for HiPS-format, hierarchically organized LSST catalog data;

8) Whether to generate HEALPix coordinates for Object and other catalog entries;

9) Whether to support spatial indexing of the catalog data in HEALPix space;

10) Whether the above have any implications for the continued generation and indexing of HTM coordinates;

+ ... ?

  • No labels