Mark Showalter - 2003-08-26

Tyler and Steve,

FYI, these are the values we have used so far for PRODUCT_TYPE.  Our approach
seems to be similar to but not identical to Steve's SCR.

Within our catalog, we group associated data files by assigning them a common
"RING_OBSERVATION_ID" and then distinguish them by giving them an informative
PRODUCT_TYPE.  So if you want all of the geometry models associated with a
particular ring occultation, you can find them.

PRODUCT_TYPE                    = CALIBRATED_IMAGE
PRODUCT_TYPE                    = CALIBRATED_QUALITY_MASK
PRODUCT_TYPE                    = CALIBRATION_MODEL
PRODUCT_TYPE                    = DOCUMENTATION
PRODUCT_TYPE                    = EDITED_DATA
PRODUCT_TYPE                    = EDITED_SPECTRUM
PRODUCT_TYPE                    = ENGINEERING_DATA
PRODUCT_TYPE                    = ENGINEERING_QUALITY_MASK
PRODUCT_TYPE                    = FILTER_RESPONSE
PRODUCT_TYPE                    = FOV_MAP
PRODUCT_TYPE                    = GEOMETRY_MODEL
PRODUCT_TYPE                    = GIF_BROWSE_IMAGE
PRODUCT_TYPE                    = JITTER
PRODUCT_TYPE                    = NOISE_DATA
PRODUCT_TYPE                    = OBSERVATION_HEADER
PRODUCT_TYPE                    = PROFILE
PRODUCT_TYPE                    = RAW_DATA
PRODUCT_TYPE                    = RAW_IMAGE
PRODUCT_TYPE                    = RAW_QUALITY_MASK
PRODUCT_TYPE                    = RING_PROFILE
PRODUCT_TYPE                    = SIMULATED_DATA
PRODUCT_TYPE                    = SOLAR_FLUX_DENSITY
PRODUCT_TYPE                    = SOURCE_DATA
PRODUCT_TYPE                    = SOURCE_JITTER_DATA
PRODUCT_TYPE                    = SPICE_SP_KERNEL
PRODUCT_TYPE                    = SUPPORT_IMAGE
PRODUCT_TYPE                    = TRAJECTORY

--Mark
--------------------------------------------------------------------
Betty Sword - 2004-03-22

Hi, Guys,

The ugly issue of what to do with the multitude of values that have
been used for PRODUCT_TYPE needs to be resolved.

Here are the particulars:

The list of standard values in the current on-line Data Dictionary is:

        EDR, REDR, REFDR, and UDR

The keyword STANDARD_VALUE_TYPE is "STATIC", meaning it's a big hoo-ha
to add values, right?  We have had many products in the past with
un-listed PRODUCT_TYPE values that we have approved but not added to
the list in the DD, because they were not considered generic enough
for others to want to use (that was my understanding of why they
weren't added).  I'm familiar with a long list Dick Simpson has
generated as part of his archiving.  Values like TDF, ATDF, ODF, TNF,
SCK.

GRS has added a whole slew of values for this keyword.  Some of which
are more generic than others:

        MORE generic examples:
                AVERAGED_NEUTRON_DATA
                COMMAND_LIST
                E_KERNEL
                GAMMA_SPECTRA
                MESSAGE_LOG
                et.al.

        LESS generic examples (mostly names of channels):
                CHAN_GRS_AD_EN_ST
                B_170K_TEMP
                GAMMA_DAC_0
                et.al.

I think I suggested at the time that they make a new keyword like
CHANNEL_ID for the second set, but no one took me up on it.
Unfortunately, since they're not going to change anything now, doe
anyone have a suggestion on how to handle the specific case of ODY
GRS, and the general case with this keyword.  Do we add some values,
or change the STD_VALUE_TYPE for this from STATIC to SUGGESTED and
change STD_VALUE_OUTPUT_FLAG to "N"?

Betty

--------------------------------------------------------------------