XMLWordPrintable

    Details

    • Type: Task
    • Status: Done (View Workflow)
    • Priority: Normal
    • Resolution: Done
    • Component/s: None
    • Labels:

      Description

      Currently, the primary key of the input_catalog table, input_catalog_id , is hard-coded like

        catId | description
       -------|--------------------------------------------------
            0 | Simulated catalog
            1 | Gaia Data Release 1
            2 | Gaia Data Release 2
            3 | Gaia Early Data Release 3
            4 | Gaia Data Release 3
            5 | HSC-SSP Public Data Release 1 (Wide)
            6 | HSC-SSP Public Data Release 1 (Deep+UltraDeep)
            7 | HSC-SSP Public Data Release 2 (Wide)
            8 | HSC-SSP Public Data Release 2 (Deep+UltraDeep)
            9 | HSC-SSP Public Data Release 3 (Wide)
           10 | HSC-SSP Public Data Release 3 (Deep+UltraDeep)
           11 | HSC-SSP Public Data Release 4 (Wide)
           12 | HSC-SSP Public Data Release 4 (Deep+UltraDeep)
         1001 | Sky positions from S21A HSC-SSP (Wide)
         1002 | Sky positions from PS1
         1003 | Sky positions from Gaia
         1004 | Sky positions for regions without PS1 data
        90001 | Messier 15 stars for the engineering observation
        90002 | NGC1904 for the engineering run in November 2022
        90003 | NGC2419 for the engineering run in November 2022
        90004 | NGC5272 for the engineering run in February 2023
        90005 | NGC5904 for the engineering run in February 2023
        90006 | NGC7078 for the engineering run in July 2023
        90007 | NGC7089 for the engineering run in July 2023
        90008 | NGC7099 for the engineering run in July 2023

      This implementation would work when the number of entries is small. For the openuse operation, we need to think about how to handle input catalogs provided by the user. It is highly likely that users want to use catalogs from their own observations, reductions, etc., not listed above or not covered by the large surveys with their own source ID scheme.

      My proposal here is the following.

      • Assign an entry in the input_catalog table for each submission via the target uploader. Therefore, if one program submits two lists, two input_catalog_id are assigned.
        *Make the input_catalog_id auto-increment primary key with the starting ID of, say, 100001.
      • (optional) If we need to add catalogs from major surveys not necessarily associated with openuse programs, we can force to use younger numbers.
      • (optional) We may allow users to indicate parent catalogs if they are in our pre-defined list and host this information in a column in the target table (something like parent_catalog_id?).

      Any comments?

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                monodera monodera
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: