Capability extension for describing whole sky maps

[Gretchen Greene]

Hi Pierre,

If you look at the footprint service spec notes,  we are 
proposing for some of the service specifications to use the 
regionID,  which in our reference implementations,  can match 
an internal HTM identifier.  The tesselation 'scheme' 
(healpix, htm, toast, etc.) is independent of the service 
method,  yet would rely on having knowledge of the capability.

What we would like to do for footprint services is to provide 
an extension schema for the registry,  to contain the relevant 
metadata for invoking service methods on a given endpoint.

I guess the point i'm eluding to is that there may be some 
advantage to including the capability elements you are 
proposing in the footprint extension schema.  I can see where 
we could also simply rely on a separate capability instance,  
but for footprints,  i.e. region maps of the sky,  your 
service example could represent an image map use case.

I'm still thinking through the details of how you are 
implementing your service,  with the direction we are heading 
with the footprints.  You may want to consult with Francois 
Bonnarel,  we had a good follow up meeting for how the 
hierachical footprints would implement the provenance model, 
odm.  A sky tesselation is NOT a footprint hierarchy,  but 
would provide a region indexing scheme,  which is part of what 
we have proposed to include as a backend capability to level 2 
footprint service methods.

-Gretchen

---- Original message ----
>Date: Sat, 22 May 2010 18:42:32 -0400
>From: Tom McGlynn <Thomas.A.McGlynn at nasa.gov>  
>Subject: Re: Capability extension for describing whole sky 
maps  
>To: "arnold at rots.net" <arnold at rots.net>,"registry at ivoa.net" 
<registry at ivoa.net>
>
>As I mentioned earlier, I think what's different is the fact 
that a range of
>resolutions are efficiently supported, not just a single 
pixel scale.  I don't
>think the WCS framework captures this.   E.g., if I want an 
image of
>all of Ursa Major, I might have two services which provide 
DSS data, e.g.,
>Aladin and SkyView.  Both cover the whole sky and have a 
resolution of 1.7",
>but only Aladin can (at least now) efficiently handle 
requests where the
>image pixels are going to be, say, 20' on a side.
>
>	Tom
>
>Arnold Rots wrote:
>> Isn't this all really a matter of projections?
>> And isn't that described pretty completely in FITS WCS 
paper 2?
>>
>>    - Arnold
>>
>> On Thu, May 20, 2010 at 5:10 PM, Tom McGlynn 
<Thomas.A.McGlynn at nasa.gov
>> <mailto:Thomas.A.McGlynn at nasa.gov>> wrote:
>>
>>     It seems to me that there are three things being 
combined here:
>>
>>        All-sky data
>>        Hierarchical imaging
>>        HEALPix projection
>>
>>     The first and last don't seem particularly special to 
me: many
>>     surveys have
>>     had all-sky coverage for a long time.  Nor does HEALPix 
seem
>>     particularly different.
>>     It's just another projection, albeit one that a lot of 
software does
>>     not yet
>>     support.  What strikes me as distinctive for the new 
Aladin service
>>     is the
>>     hierarchical imaging, which I don't think is well 
described in our
>>     current framework.
>>
>>     So I think that's the element I'd emphasize rather than 
HEALPix
>>     which I see as a detail
>>     in a particular implementation.  E.g., WWT proides a 
similar service
>>     using the TOAST
>>     projection and I believe GoogleSky does the same using 
a Cartesian
>>     projection (or maybe
>>     even Mercator).
>>
>>             Regards,
>>             Tom
>>
>>
>>     Pierre Fernique wrote:
>>
>>
>>         Dear registry members,
>>
>>         As I presented Tuesday 18 May during the App 
session at Victoria
>>         interop, I was suggesting an extension of the 
"capability"
>>         section for
>>         describing whole sky maps/surveys (for those who do 
not follow this
>>         talk, here the pdf -
>>         
http://www.ivoa.net/internal/IVOA/InterOpMay2010Applications/A
ladindemonstrationInteropVictoria2010.pdf).
>>         Do you think that it is a good idea. And if yes, 
may you help me for
>>         describing it properly in the schema of the 
registry.
>>
>>         Here is my draft :
>>
>>         <capability xsi:type= "SimpleAllSkyAccess">
>>         <interface type="HEALPIXmap">
>>         <accessURL use="base">http://..</accessURL>
>>         <HEALPix>
>>         <frame>Gal</frame>
>>         <tileFormat>FITS</tileFormat>
>>         <treeDepth>12</treeDepth>
>>         </HEALPix>
>>         </interface>
>>         …
>>         </capability>
>>
>>         type : HEALPIXmap, HTMmap,... = sky tessellation 
method
>>         frame : GAL, ECL, EQU = tessellation reference 
frame
>>         titleFormat : FITS, PNG, JPG .... = image format 
for individual tile
>>         treeDepth: number = hierarchical depth (in Healpix 
= Norder, or
>>         log2(NSIDE))
>>
>>         This kind of "SimpleAllSkyAccess" resource may be 
queried just
>>         by tile
>>         ID as parameter. For Healpix it is a couple : 
Norder/npixNumber.
>>         For HTM
>>         it will be the triangle ID...
>>
>>         http://base.adresse..cgi?tile=ID
>>
>>         With this very simple interface, any body should be 
able to build a
>>         client for displaying this kind of resources.
>>
>>         Thanks
>>         Pierre Fernique
>>
>>
>>
>