Hi Dave,
2) As is usual for an astrometrist, I am frightened of IDs based on
the measurement of position. Serge's note shows a sensitivity to
this issue in noting that the IDs need to remain fixed even if
subsequent processing changes the coordinates, but I still worry.
Many clever people have proposed single integers that are useful
indices for the 2-dimensional sky. Chunking of (RA,Dec) is certainly
one way to go, but nets and meshes of funny-shaped things (triangles
for instance) may be more useful.
I am curious: Can you be more specific as to what other 2D->1D mappings
you mean (besides HTM/HEALPIX)? To clarify a little bit, I should say that
in the hypothetical x-match implementation I was talking about, the
purpose of the ID is only to uniquely identify an object, not to serve as
an index of any kind. I proposed constructing it from ra and dec for no
other reason than to save storage space (although almost any position
based scheme could probably be made to compress quite well). I would also
point out that this ID doesn't necessarily have to correlate to an objects
public/official ID at all - it just needs to let us look things up in the
database at the base camp.
I am a bit surprised that one needs to store the whole catalog in
memory no matter how it is organized. The small chunk needed
for a single LSST observation should be a relatively small and quick
read-only access to a database, and I would have thought that this
could be done in milliseconds, not seconds. The subtle issues
raised in (1) above would not preclude finding and matching enough
stars to compute a provisional WCS transformation, for example,
and perhaps this would be a useful thing to do for down-stream
processing.
This doesn't address the update issue, the what-to-do-with-extra-
detections issue, the is-this-interesting issue, and others.
Well, I don't propose to store the whole catalog in memory, just the
spatial index. The point I was trying to make is not "the entire index
absolutely must be in memory, or we are dead" but that we can actually fit
the whole thing into memory and dispense with partitioning the index or
creating the relevant parts of it on the fly altogether. As to estimating
how much time it would take to create a zone table for 10deg2 FOV, I think
Maria would be in a much better position to answer (but milliseconds
sounds very low to me, consider that ~10 million rows must be read to do
this in the worst case).
Regards,
Serge
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
