ObsCore calib_level values

Patrick Dowler pdowler.cadc at gmail.com
Tue Aug 2 21:56:49 CEST 2016


There was some discussion at some point about whether calib_level
values greater than those defined in ObsCore (currently 3) are allowed
or not. I had always assumed that because it was an integer that I
could use higher values and that only 0-3 were well defined.... 4
would just mean "more processed".

Laurent has already convince me that my use of "catalog" (information
extraction) doesn't require a higher calib_level. One can think of
dataproduct_type and calib_level as orthogonal and then have a
"catalog" with calib_levels from 1-3 pretty easily (not going into
details here) and I agree that orthogonal is a better way to think
about it.

However, calib_level is not orthogonal to the "provenance"... it seems
to be a highly compact short-hand way to say that more processing has
been applied and to separate products into groups. If a project has
products which they assign calib_level=3 to, and then they start to
handle some more highly processed products, they may naturally want to
distinguish these via a higher calib_level. The question is: is that
or should that be allowed in ObsCore? Can a project leverage
calib_level or are they forced to introduce a non-standard column to
distinguish this new product?

In the use case I have in mind, the tension is between distinguishing
two kinds of products with different processing and wanting to
leverage calib_level rather than add ad-hoc or non-standard
provenance-y columns to the ObsCore table. I would not go so far as to
call this a proposal to change the spec, but certainly to clarify it
as the numeric type implies extensibility. I feel extensibility is ok.



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


More information about the dm mailing list