Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-16475

Recognize ObsCore, recognize some UCDs, do normal catalog overlay

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: Firefly
    • Labels:
    • Story Points:
      14
    • Sprint:
      SUIT Sprint 2018-11, SUIT Sprint 2018-12
    • Team:
      Science User Interface

      Description

      Recognize ObsCore, Recognize UCD, do normal catalog overlay.

      The ticket is just 1.1 of DM-15783 but lays the foundation for more.  Using upload, when a table is sent to the client. If it is a VO like table,  determine if it is ObsCore or if there is ra/dec information based on UCD and do the normal catalog overlay.

      The source of the table does not have to be a VO table we just want to be able to recognize VO type meta-data.

        Attachments

          Issue Links

            Activity

            Hide
            gpdf Gregory Dubois-Felsmann added a comment - - edited

            For the minimal goal Trey has articulated, a VO-ish way to express the logic is:

            Look at the UCDs for the table columns. Limit the scope of consideration to ones with UCDs beginning with "pos.eq.". If columns with UCDs including "pos.eq.ra" and "pos.eq.dec" are present, determine how many such pairs are present. Associate pairs by comparing their column names. If there is only one, use it for catalog overlays on images. If there are multiple pairs, look for one where the UCDs include "meta.main" (e.g., "pos.eq.ra;meta.main") and use that. If there is no "meta.main" pair (or if multiple pairs include "meta.main") use the leftmost such pair in the table.

            Optionally (as a later upgrade which should be a separate ticket), in the layer dialog, if there are multiple "pos.eq.ra/dec" column pairs, allow users to select a non-default pair of columns to be used for the overlay for a catalog.

            Show
            gpdf Gregory Dubois-Felsmann added a comment - - edited For the minimal goal Trey has articulated, a VO-ish way to express the logic is: Look at the UCDs for the table columns. Limit the scope of consideration to ones with UCDs beginning with "pos.eq.". If columns with UCDs including "pos.eq.ra" and "pos.eq.dec" are present, determine how many such pairs are present. Associate pairs by comparing their column names. If there is only one, use it for catalog overlays on images. If there are multiple pairs, look for one where the UCDs include "meta.main" (e.g., "pos.eq.ra;meta.main") and use that. If there is no "meta.main" pair (or if multiple pairs include "meta.main") use the leftmost such pair in the table. Optionally (as a later upgrade which should be a separate ticket), in the layer dialog, if there are multiple "pos.eq.ra/dec" column pairs, allow users to select a non-default pair of columns to be used for the overlay for a catalog.
            Hide
            gpdf Gregory Dubois-Felsmann added a comment -

            Emmanuel Joliet this is also just the first piece of DM-15783, all of which must be completed before LSST new-features funding ends. We need to get started on that work ASAP in order to finish all of it in time.

            Show
            gpdf Gregory Dubois-Felsmann added a comment - Emmanuel Joliet this is also just the first piece of DM-15783 , all of which must be completed before LSST new-features funding ends. We need to get started on that work ASAP in order to finish all of it in time.
            Hide
            gpdf Gregory Dubois-Felsmann added a comment -

            The suggestion I made two comments up applies to all tables that we ingest and should be used as a predecessor to whatever our current logic is for finding the ra/dec columns to use for overlays.

            In thinking of this as the first step toward implementing DM-15783, though, we are going to have to define the logic for when we recognize a table as an image metadata table and so enable a mode of the application in which we start actually retrieving and displaying the referenced images.

            I'll comment on that on the parent ticket.

            Show
            gpdf Gregory Dubois-Felsmann added a comment - The suggestion I made two comments up applies to all tables that we ingest and should be used as a predecessor to whatever our current logic is for finding the ra/dec columns to use for overlays. In thinking of this as the first step toward implementing DM-15783 , though, we are going to have to define the logic for when we recognize a table as an image metadata table and so enable a mode of the application in which we start actually retrieving and displaying the referenced images. I'll comment on that on the parent ticket.
            Hide
            roby Trey Roby added a comment - - edited

            DM-16476 is there partially to give us more fine grain control as to how the recognized tables. We need to run all the tables though some master table recognition task that can be configured for different applications.

            Show
            roby Trey Roby added a comment - - edited DM-16476 is there partially to give us more fine grain control as to how the recognized tables. We need to run all the tables though some master table recognition task that can be configured for different applications.
            Hide
            cwang Cindy Wang [X] (Inactive) added a comment -

            If ra/dec columns finding for normal catalog overlay is made at client side, some table search processors at Firefly server already having the functions to identify the center columns and set the relevant metadata into the table may need to be reviewed. The review work includes,

            • checking if the center column search is necessary.
            • checking if center column search method is consistent with the one done at client side.

            The following search processors (files) are found with implementation to search the center columns and may need some review,

            • QueryVOTABLE.java and VOTableReader.java
            • UserCatalogQuery
            • IpacTableFromSource
            Show
            cwang Cindy Wang [X] (Inactive) added a comment - If ra/dec columns finding for normal catalog overlay is made at client side, some table search processors at Firefly server already having the functions to identify the center columns and set the relevant metadata into the table may need to be reviewed. The review work includes, checking if the center column search is necessary. checking if center column search method is consistent with the one done at client side. The following search processors (files) are found with implementation to search the center columns and may need some review, QueryVOTABLE.java and VOTableReader.java UserCatalogQuery IpacTableFromSource

              People

              • Assignee:
                cwang Cindy Wang [X] (Inactive)
                Reporter:
                roby Trey Roby
                Reviewers:
                Tatiana Goldina, Trey Roby
                Watchers:
                Cindy Wang [X] (Inactive), Emmanuel Joliet, Gregory Dubois-Felsmann, Loi Ly, Tatiana Goldina, Trey Roby, Vandana Desai, Xiuqin Wu [X] (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel