Image metadata tables are part of the public data products, both Prompt and Data Release.  The tables needed include:

  • an ivoa.ObsCore table/view for an ObsTAP service (and equivalent SIAv2 service),
  • CAOM2-compliant tables/views, and
  • LSST’s “native” visit and image metadata.

All of these need supporting “schema metadata” (e.g., UCDs) in order to be published properly.  It would make sense to use Felis to describe the data models of these tables. It would also, I think, make sense to use the “Data Model Standardization” tooling to generate any transformed tables that are required.

Some (all?) of the “native” image and visit metadata are naturally in the Butler Gen3 database / Registry for the Prompt and DR processing.

The issue requiring design work: how do we make the connection between that information / that database and the image/visit metadata tables in the released data products?

Concerns:

  • Is the BG3 database our "true" image/visit database, or is it just a subset of that data chosen for efficiency?
  • If coadds are really just tiny “cells” and are ultimately not patch-sized tangent planes, what does the public metadata for coadded images look like?  Are all coadded image requests effectively mosaic-building jobs?  Or are there some "default" tangent-plane images?  (There must still be a notion of patches in order for the BG3 / PipelineTask framework to work properly, so we can still expose the patch concept externally.)
  • For DRP, data model standardization is a planned part of the entire process of assembling a data release.  (Modulo some uncertainty about task assignments, perhaps.)  But for Prompt data products, covered by the L1PublicT latency, is there a plan for how to condition the data to be suitable for release via IVOA services?
  • What about Commissioning Cluster "live" data access?  Can we offer a query service there, or are we limited to direct Butler (and perhaps SQLAlchemy) access to the live BG3 Registry?  (Gregory Dubois-Felsmann: "If we could make the ObsCore table be a view on the BG3 database, a query service could be provided fairly straightforwardly.")

See also:


  • No labels