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