s_region problem

[Arnold Rots]

Thomas pretty much said what I was going t say.
MOC images are handy to look at, but if you want to look at coverage
superimposed on, e.g., DSS, you want to see the outline of the footprint.
Besides, if you get beyond order 13 (a far cry from 29), the files get very
bulky and the response very sluggish.

The issue of small circle sectors (as opposed to great circle sectors) is a
bit of a pain. STC can handle it, but I don't think anyone (with the
possible exception of SDSS) has ever used it, much less implemented. Great
circles are nice ad they transform to straight lines in tangent
projections, but they are not helpful for drift scan surveys or RA,Dec
boxes.

Polygons are traversed CCW (i.e., the inside is always on your left) when
looking at the celestial sphere from the origin.

Cheers,

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------


On Mon, Dec 4, 2017 at 4:57 AM, Thomas Boch <thomas.boch at astro.unistra.fr>
wrote:

> Markus, Felix,
>
> To me, STC-S footprints and MOCs are two different, complementary objects,
> and we need both.
>
> STC-S footprints are useful when a client wants to draw the (mostly)
> accurate outline of an observation.
> MOCs provide a discretization of the coverage. They are great for fast
> coverage comparison/intersection/union and to query efficiently a database
> for a given coverage on the sky.
>
> Yes, you can algorithmically compute the outline of a MOC (Aladin Desktop
> does it). But that will only be an approximation. Plus, the size (in bytes)
> of the MOC will be 1 or 2 orders of magnitude greater than the initial
> STC-S description.
>
> --
> Thomas
>
>
> Le 01/12/2017 à 09:48, Markus Demleitner a écrit :
>
>> Felix,
>>
>> On Wed, Nov 29, 2017 at 10:27:32AM +0100, Felix Stoehr wrote:
>>
>>> Question 2: Assuming some tool support (i.e., "STC-S-to-MOC
>>>> converter", and MOC support in their backen databases), how would
>>>> current STC-S providers feel about migrating to MOCs on a time frame
>>>> of a few years?
>>>>
>>>> [...]
>>
>>> ALMA can certainly compute MOCs and has actually been planning to do so.
>>> My personal impression is that however the MOCs serve a different
>>> purpose than our STC-S footprints. MOCs: fast x-match, high-order
>>> display in AladinLite. STC-S footprints: exact outline and precise
>>> display in AladinLite.
>>>
>> I don't think precision is a major issue here -- at level 29, the
>> typcial extent of a healpix cell is of the order 0.5 mas.  Even in
>> the Gaia age, that, I believe, should go a long way.
>>
>> It is true, though, that MOCs hide some physics; it is, I suspect,
>> virtually impossible to reconstruct that a certain coverage, for
>> instance, has been produced as a union of n distinct circles, and...
>>
>> This seems also to be what ESA sky or ESO are doing with the new
>>> interface. We also want that users can select individual footprints by
>>> clicking on the boundary, which is a use-case that I am not sure how it
>>> could be supported by MOC.
>>>
>> ...finding the outline of a MOC is probably non-trivial (though it
>> sounds like something that's algorithmically feasible).
>>
>> Then again, I'm not convinced if letting people go for outlines
>> actually is a good solution for the UI problem of letting people
>> select one of several overlapping shapes; after all, it's perfectly
>> possible that several of these shapes have the same outline, at least
>> at a given resolution, and then you're back at having to be explicit
>> about the stack again.
>>
>> So, for this particular problem I'd say going for, for instance,
>> popups that let people select which of the set of shapes below the
>> pixel in question they'd like to use would be preferable, and that's
>> at least as straightforward with MOCs as with explicit geometry
>> (whether written in STC-S on in some sanitation of it).
>>
>> That doesn't mean there aren't (other) use cases for explicit
>> geometries.  But it'd be great to understand them before going for a
>> sanitation/standardisation of the TAP 1.0 appendix.
>>
>>           -- Markus
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20171204/6263fbfe/attachment.html>