Hi Tim, We should probably reflect this in the domain model by making Astronomical Object to be an aggregate of 2 classes: "Object Summary" and "Object Measurements" (or something to that effect).
Jeff > From: Tim Axelrod <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED], LSST Data Management <[email protected]> > Date: Fri, 17 Mar 2006 08:49:32 -0700 > To: Jacek Becla <[EMAIL PROTECTED]>, LSST Data Management > <[email protected]> > Subject: [LSST-data] Re: size of Objects > > Hi Jacek, > > I think of the object catalog having two logically distinct pieces. > The first is the time-independent information about an object, which > I've sometimes referred to as summary information. This contains best > estimates on object position, shape, colors, classification, proper > motion/parallax, etc, and is updated relatively infrequently at the > archive. The second piece is all the individual measurements over time > that are associated with the object. The summary information is roughly > equivalent to the SDSS catalog. I agree with Jim: we need a lot more > than the 200 bytes I quoted for this. We're likely to be larger than > SDSS simply because we will likely have a more ambitious shape > description scheme for extended objects. This should all drop out of > the LSST schema definition - we need to devote more attention to it!. > We should be able to estimate the size of the second, time-dependent > piece much more easily - my 50 byte number is probably not too far off. > > BTW, I think all this email traffic should go out to LSST Data - it is > useful for others to see and possibly comment. > > Tim > > Jacek Becla wrote: > >> Tim/Kem >> >> I exchanged some emails with Jim Gray and he pointed out >> that the SDSS objects are about 2KB each (while ours are >> 124 bytes, at least in the precursor schema, and you (Tim) >> mentioned ~250 bytes. >> >> He then said that: >> >> Jim Gray wrote: >> >>> All I can say is that the SDSS is in 5 bands and every number has an >>> error associate with it And then there is a summary value. So every >>> value is 12 values. That is how things are 12x what I would have >>> guessed. >>> >>> In addition the pipeline gereates LOTs of flags. But there are about >>> 70 "popular" fields out of the 400. So we have a 8x smaller "tag" >>> table that is only about 300 bytes/object. >>> >>> >>> Hard for me to say if LSST will be different. You might ask them. >> >> >> So here I am checking... >> >> thanks, >> Jacek > > > _______________________________________________ > LSST-data mailing list > [email protected] > http://www.lsstmail.org/mailman/listinfo/lsst-data > _______________________________________________ LSST-data mailing list [email protected] http://www.lsstmail.org/mailman/listinfo/lsst-data
