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

Unclear how to perform searches on "wrapped" regions in Qserv

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: To Do
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: Qserv
    • Labels:
      None
    • Team:
      Data Access and Database

      Description

      I have been having some difficulty figuring out how to perform searches on large sky regions with the qserv_areaspec_poly function.

      It appears that the system always tries to find the smaller of the two possible interpretations of the polygon, so it's impossible to use this function to perform searches larger than half the sky.

      A tangible use case for this in LSST might be to exclude the Galactic center from a search.

      (Yes, this can be done with a non- qserv_areaspec_ WHERE clause in a full sky table scan, and probably without a great loss in performance.  But why not provide a way to do it with the Qserv optimizations?)

      It's not clear whether there's a way to define a region with a restriction only on one of ra or dec, either.  It might be possible to do this with the right arguments to qserv_areaspec_box, but it's not documented that I can see.

      It's also not clear to me how one might define a search that, say, excluded the entire Galactic plane but, again, still preserved Qserv shard-selection optimizations.  Could we have Qserv functions that respect Galactic or ecliptic coordinates?  

      This is relevant to the implementation of the corresponding ADQL functions in dbserv.

        Attachments

          Issue Links

            Activity

            Hide
            fritzm Fritz Mueller added a comment -

            Hmm, I had thought that sphgeom (and therefore Qserv) followed the standard convention of taking the interior of a polygon to the left of each edge in a counter-clockwise traversal...  Will check..

            Show
            fritzm Fritz Mueller added a comment - Hmm, I had thought that sphgeom (and therefore Qserv) followed the standard convention of taking the interior of a polygon to the left of each edge in a counter-clockwise traversal...  Will check..
            Hide
            fritzm Fritz Mueller added a comment -

            Ah, I see this is not the case, because of convexity concerns in sphgeom.  Lunes and bands are also not directly supported in sphgeom.

            Theoretically, qserv could be taught to "notice" these and either invert predicates of chunk and aggregation filters or decompose to unions of expressible/convex regions.  This would not be a trivial undertaking...

            Show
            fritzm Fritz Mueller added a comment - Ah, I see this is not the case, because of convexity concerns in sphgeom .  Lunes and bands are also not directly supported in sphgeom . Theoretically, qserv could be taught to "notice" these and either invert predicates of chunk and aggregation filters or decompose to unions of expressible/convex regions.  This would not be a trivial undertaking...
            Hide
            gpdf Gregory Dubois-Felsmann added a comment -

            Noting, in response to the old-ticket ping from the CCB, that I still consider this a valid-but-not-urgent ticket.

            Show
            gpdf Gregory Dubois-Felsmann added a comment - Noting, in response to the old-ticket ping from the CCB, that I still consider this a valid-but-not-urgent ticket.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              gpdf Gregory Dubois-Felsmann
              Watchers:
              Fritz Mueller, Gregory Dubois-Felsmann
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:

                  Jenkins

                  No builds found.