Capability extension for describing whole sky maps

Tom McGlynn Thomas.A.McGlynn at nasa.gov
Sat May 22 15:42:32 PDT 2010


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/AladindemonstrationInteropVictoria2010.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
>
>
>



More information about the registry mailing list