s_region problem

[Felix Stoehr]

Hi Markus,

this is why I think I am not really the right and most relevant person
to discuss here.

Sure, if someone comes up with an efficient method of doing STC-S -> MOC
-> STC-S then the representations are equivalent (maybe except for the
size in the VO table where our circles only will need 3 floating point
values, rather than e.g. cells for order 29).

So I think it is the right moment for me to hand this back to the
experts = you folks.

Best regards,

Felix

And, yes, if there are 50 overlapping footprints and three of those are
exactly overlapping and the user happens to click on the footprint of
one of these three, then the corresponding three rows in the table must
be highlighted.

On 01.12.2017 09:48, Markus Demleitner wrote:
> 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
> 

-- 
Dr. Felix Stoehr      ESO/ALMA
Tel +49 89 3200 6283  Fax 6358
www.eso.org/~fstoehr/felix.asc