taxelrod
commented
9 years ago A few comments, not well organized as yet:
- Thinking strictly of the patch-of-sky application for the moment, our lives would probably be simpler if we used different projections for your cases 1 and 2. The all-sky projection could be any of the common ones (Aitoff, Mollweide, etc), but with the "pole" not being the celestial S pole, but rather chosen to be some place that moves the distortion to an area of the sky that we don't care about much. As an extension, it would probably be possible to move the pole of the projection interactively, since we're just talking about a coverage map, not terapixels of data.
- For the actual display of a patch's data, we certainly need to be able to zoom in all the way to native LSST pixel level, but don't need to zoom out beyond a patch size. The patch is small enough that distortion issues are then negligible, even zoomed out fully. Note, though, that in this model each patch would have it's own local projection: they couldn't be fit together into a larger area.
- I agree with your point about wanting to have a general all sky projection that lets us display data from other surveys. I've never been able to convince Suzanne of this, though. At least in the past, she's thought this is too much pro-astronomer stuff. Maybe WWT has changed her mind.
There have been several recent discussions about projections and it's looking increasingly likely that we may need to use more than one projection to cover different use cases. I believe it's important that we describe our projection model(s) and internal formats rigorously such that there is no ambiguity in how to transform data from any projection / pixel scale for EPO usage. This issue is intended to start articulating use cases as a first step towards deriving requirements.
I believe we have identified three use cases (and there are likely others):
\1, \2, & \3 possibly could in theory use the same projection but there are significantly different use cases.
1
Needs to be able to handle the entire southern sky as visible from Cerro Pachon on a typical computer display device (eg, on a webpage without horizontal/vertical scrolling). I think we should take a step further and require that the project be able to display both poles simultaneously so that non-LSST data can be handled with the same model. Such a projection impossible without heavy distortion. I believe that Aitoff (or similar) is already in usage within the project and the science collaborations. It would be convenient if we could normalize on a single all sky projection between EPO and the rest of the project.
2
Essentially this is the Google sky use case but must allow display of the poles. To my eye, the level of visible distortion present in a Mercator projector is unacceptable for this use case. (TBD: quantify acceptable distortion) The distortion issue is a compelling reason to consider different projections for \1 & \2.
In terms of display implementation, ideally we would like to ship rectangles of raster data to the client that can be displayed directly abutted without requiring pixel (or even worse, sub-pixel) display gaps to be handled or client side transformation. Simple quadrilateral transformations might have low computation impact on client devices (unknown) but there is reasonable concern about the computation and implementation complexity of requiring data to be warped to curved plane (likely using 3D graphics).
Unlike with \1, I don't believe there are any known requirements on the field of view at any given time. Placing a zoom-level constraint may help "hide" curvature from a display client. TBD: is there a required minimum FoV / zoomed out level?
3
\3 Would ideally be the same projection as \2 but we should consider how to handle "imported" data sets already using a different projection. There is also the possibility that the DM internal and/or data release projection may be different than what EPO selects for client display.
Per KT, DM baseline is HTM.