If your time-series view is going to be organized around a spatial area, please remember that coverage of that area will be variable with time. Some visits will only cover part of the area, and the parts that are covered will change. The list of Objects that appear in each visit will thus obviously change, even if they are not variable or transient.
The database team has mostly been thinking of returning the series of Sources or ForcedSources for a given object in order to do light curves, not all Sources or ForcedSources in a given spatial area for a given visit. If the latter is really needed, we should make sure to add it to the list of test queries.
Not captured in the drawing is that we also will want to offer the option of an image stack that follows an object as it moves against the RA-Dec coordinate grid over time, i.e., following proper motion and parallax, or a Solar System orbit.
A "postage stamp" or cutout stack centered on a particular object (including changes in its position over time) is a use case that I have definitely been expecting. Note that even that can have partial coverage of the cutout area.
Yes, we talked about the variability of coverage. One of the "context maps" would be a visualization of the coverage as a function of area.
A good question for the cutout service is to define clearly what it will do when asked for a cutout that crosses a coverage boundary. Will there be a specific mask plane dedicated to "no available data for that pixel"?
It may be necessary to define a subset of mask planes as having explicit significance to the image display, as opposed to others which it just makes available for display (e.g., as optional colored overlays, etc.).
Hi K-T ... just to be clear on what is happening here. We are utilizing a simple set of use cases to help define a set of functions/tools/library that we are identifying as necessary to support the end-users. The idea being that a library of tools usable by the SUI team to build a coherent portal is also a library of tools that can be used by the end-users within their own environments for their own specific science. Towards that end, what you are seeing here is a partial look in the overall design and thought process. So please keep the ideas coming to make sure we don't miss a point/idea but also know that is just a glimpse ...
I highly encourage you to post draft, partial, and otherwise in-progress ideas! I'm very interested to see what we're currently missing (like spatial queries on Source and ForcedSource tables that will have to be implemented, at least in the latter case, via a join with Object). Sometimes I may poke at something just to make sure I understand it completely.
8 Comments
Kian-Tat Lim
If your time-series view is going to be organized around a spatial area, please remember that coverage of that area will be variable with time. Some visits will only cover part of the area, and the parts that are covered will change. The list of Objects that appear in each visit will thus obviously change, even if they are not variable or transient.
The database team has mostly been thinking of returning the series of Sources or ForcedSources for a given object in order to do light curves, not all Sources or ForcedSources in a given spatial area for a given visit. If the latter is really needed, we should make sure to add it to the list of test queries.
Gregory Dubois-Felsmann
Not captured in the drawing is that we also will want to offer the option of an image stack that follows an object as it moves against the RA-Dec coordinate grid over time, i.e., following proper motion and parallax, or a Solar System orbit.
Kian-Tat Lim
A "postage stamp" or cutout stack centered on a particular object (including changes in its position over time) is a use case that I have definitely been expecting. Note that even that can have partial coverage of the cutout area.
Gregory Dubois-Felsmann
Yes, we talked about the variability of coverage. One of the "context maps" would be a visualization of the coverage as a function of area.
A good question for the cutout service is to define clearly what it will do when asked for a cutout that crosses a coverage boundary. Will there be a specific mask plane dedicated to "no available data for that pixel"?
Kian-Tat Lim
Yes, I believe the current code would mark such pixels as EDGE in the mask plane.
Gregory Dubois-Felsmann
It may be necessary to define a subset of mask planes as having explicit significance to the image display, as opposed to others which it just makes available for display (e.g., as optional colored overlays, etc.).
Unknown User (ciardi)
Hi K-T ... just to be clear on what is happening here. We are utilizing a simple set of use cases to help define a set of functions/tools/library that we are identifying as necessary to support the end-users. The idea being that a library of tools usable by the SUI team to build a coherent portal is also a library of tools that can be used by the end-users within their own environments for their own specific science. Towards that end, what you are seeing here is a partial look in the overall design and thought process. So please keep the ideas coming to make sure we don't miss a point/idea but also know that is just a glimpse ...
Kian-Tat Lim
I highly encourage you to post draft, partial, and otherwise in-progress ideas! I'm very interested to see what we're currently missing (like spatial queries on Source and ForcedSource tables that will have to be implemented, at least in the latter case, via a join with Object). Sometimes I may poke at something just to make sure I understand it completely.