# Add support for polygon-based searches

XMLWordPrintable

#### Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
None
• Team:
Data Access and Database

#### Description

Qserv should support the following type of queries:

 -- Create a binary representation of the search polygon SET @poly = scisql_s2CPolyToBin(359.9601, 2.5952,  0.0398, 2.5952,  0.0398, 2.6748,  359.9601, 2.6748);   -- Compute HTM ID ranges for the level 20 triangles overlapping -- @poly. They will be stored in a temp table called scisql.Region -- with two columns, htmMin and htmMax CALL scisql.scisql_s2CPolyRegion(@poly, 20);   -- Select reference objects inside the polygon. The join against -- the HTM ID range table populated above cuts down on the number of -- SimRefObject rows that need to be tested against the polygon SELECT refObjectId, isStar, ra, decl, rMag FROM SimRefObject AS sro INNER JOIN  scisql.Region AS r ON (sro.htmId20 BETWEEN r.htmMin AND r.htmMax) WHERE scisql_s2PtInCPoly(ra, decl, @poly) = 1; 

This 3-step process can be hidden inside qserv, without exposing it to user. Ideally, we should be able to run it behind the scene, and avoid changing/extending the existing API between user and the proxy

This story has been transfered from https://dev.lsstcorp.org/trac/ticket/2056

#### Activity

Hide
Jacek Becla added a comment -

Comment by Daniel made in 2013:

It should be a lot easier to expose a syntax like this to the user:

 SELECT refObjectId, isStar, ra, decl, rMag FROM SimRefObject  WHERE qserv_areaspec_poly(359.9601, 2.5952,  0.0398, 2.5952,  0.0398, 2.6748,  359.9601, 2.6748) = 1; 

Note: Since the scheme relies on an htmId20 column, there is no choice for ra/decl columns anyway--htmId20 is always used.

This is preferable since it's much harder to support all of the syntax required to make the original 3-step approach work from the user. Those 3 steps can be generated programatically, but implementing new language syntax is much harder, especially if you want it to work in a distributed context.

Hiding it is probably a week's work (or less), once the scisql workings are understood. It could take a bit more time to discover the failure modes and to make those happen reasonably.

Show
Jacek Becla added a comment - Comment by Daniel made in 2013: It should be a lot easier to expose a syntax like this to the user: SELECT refObjectId, isStar, ra, decl, rMag FROM SimRefObject WHERE qserv_areaspec_poly(359.9601, 2.5952, 0.0398, 2.5952, 0.0398, 2.6748, 359.9601, 2.6748) = 1; Note: Since the scheme relies on an htmId20 column, there is no choice for ra/decl columns anyway--htmId20 is always used. This is preferable since it's much harder to support all of the syntax required to make the original 3-step approach work from the user. Those 3 steps can be generated programatically, but implementing new language syntax is much harder, especially if you want it to work in a distributed context. Hiding it is probably a week's work (or less), once the scisql workings are understood. It could take a bit more time to discover the failure modes and to make those happen reasonably.
Hide
Gregory Dubois-Felsmann added a comment -

Ping. I think this is supposed to be done already, right?

Show
Gregory Dubois-Felsmann added a comment - Ping. I think this is supposed to be done already, right?
Hide
Fritz Mueller added a comment -

This has been supported for a good while now.

Show
Fritz Mueller added a comment - This has been supported for a good while now.

#### People

Assignee:
Unassigned
Reporter:
Fritz Mueller
Watchers:
Fritz Mueller, Gregory Dubois-Felsmann, Serge Monkewitz