s_region problem

[Thomas Boch]

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