Proposed new Features | ||||||||
Changed: | ||||||||
< < | None yet | |||||||
> > | Define a way to discover s_region usability | |||||||
Added: | ||||||||
> > | A major pain when doing "blind" obscore queries is that it would be nice to query against s_region (because it is so much more flexible and reliable than s_ra, s_dec, and s_fov), but support for s_region is not universal. Probably the easiest way to fix this would be to say "if you give s_ra and s_dec, you MUST give s_region". That would be my preferred solution, actually. Alternatively, there should be a way for data providers to say "you will not get extra false negatives if you use s_region over s_ra and s_dec on this table". Ideally, this would not require Registry interaction; and actually, the Registry does not have an out-of-the-box mechanism for something like this either. We would have to define an Obscore registry extension for such a flag, and that seems overkill to me at this point. I wonder if we should'nt just have a hack and say "if your s_region column is fine, add the literal string 'safe-for-queries' to s_region's description". Yes, this may seem to radiate a bit of bad karma, but it works nicely with both TAP_SCHEMA and VOSI, which is nice and seems hard to attain with just about anything else. Another alternative that has this property would be to change the s_region's UCD or utype for query-safe (or non-query-safe?) s_region columns... hm. | |||||||
Proposed modificationsImprove Sample QueriesThe example queries in the appendix should not show people | ||||||||
Changed: | ||||||||
< < | split-coordinate spatial constraints (s_dec<20 and friends) and rather | |||||||
> > | split-coordinate spatial constraints (s_dec<20 and friends) and rather | |||||||
use proper geometry constraints (circles or polygons). Coordinate
queries are often not covered by indexes and are rarely a good idea
physically.
Also, it would be good if we could include at least one or two examples
which show how to just retrieve a subset of columns; "select *" may be
appropriate for certain use cases, but just pulling the data one needs
for a certain use case is better use of resources. This may in general
not be dramatic in your average obscore query, but when people to
statistics on millions of matches, it does matter.
-- MarkusDemleitner 2023-01-16
<--
|