New section 4.2.6 describing the shear measurement approach that was presented last week.
Proposing a separate ShearObject table, no matches to the Object table.
Naming conventions, acronyms, camelcase .... can we do better?
CTS/JB: this is one column for g,r,i bands same as the Object table
JB: Could see table growth if we want quantities per-band as well as averaged across bands.
JC: Are we presuming a cell table that this can be joined to?
JB: In the same boat as ccdVisit, tract, patch table. Provenance table is probably the most important. Not sure if this is in the DB or in the Butler provenance system
LPG/CTS: Looking like this table will be ~1/4 number of columns as the Object table.
JB: We can bitpack flags but this is not well supported by SQL nor Parquet. Flags dp not come for free.
JC: Table name - does this only imply that it is only useful to a specific science? Can we come up with a different name that implies broader use?
JB: It really is only useful to WL and is not useful for the physical sizes or ellipticities of galaxies. Table goal is to present the sky as a background field that gets distorted by a foreground field, not as a table of individual astrophysical objects.
LPG: Need to make sure that the ShearObject table is not mistakenly used by the community - there are columns with similar names as in the Object table. Take the same approach as for SSO tables. ShearObjects focused on a specific science case, just as SSObject tables do.
CTS: Joins to a cell table are not really a worry. Concerned about provenance tables for the images that go into cells. Would like to see a physical schema for that sooner than later.
CTS: Has informed DAX team about this - no one is freaked out.
JB: Cell provenance table does not necessarily need to be in the DB, it could be in Butler.
CTS: Some people might wonder why they cannot get the all the relevant data from Qserv and have to go to Butler to get some data. Could result in a bad UX.
JB: If DAX say it is OK to put into Qserv then OK
CTS: This can go ahead without a cell table - will want an example later but not urgent
CTS: Rollout might be a good topic for a PST science collab chairs talk . Together with the removal of Object extra (MCMC samples) .
LPG: Make any talk to the PST / SC Chairs general to cover all recent updates to the DPDD. e.g
Astrometry - DR1 goals are different to the final goals
We store deblending outputs better now
Cell-based coadds - discuss this more - what does this mean for firefly
MLG: Cell based coadds - are these a new image data products?
JB: Only called out in the ShearObject table - implementation detail of how we build the coadds. This might affect how the file for cell-based coadds will look. All Object quantities will come from the cell-based coadds.
MLG: Why not issue cell-based templates
JB: Not clear we will get any benefit and don't want to rock the boat at this stage. Possibly post DR1 but
Jim Bosch Create an RFC the proposed ShearObject table (once ES has had a chance to comment)
Leanne Guy talk to Steve R about presenting plans for the ShearObject table to PST and SciCollab chairs
Jim Bosch Provide a physical example of that a up on cell table would look like fo the Colin Slater / DAX team to review
Jim Bosch Provide an example of a file containing a cell-based coadd for Gregory Dubois-Felsmann to examine to assess implications for firefly
DM-12676 : Obs package refactor has been lingering for a long time at low priority. I propose to try to get a software developer from the in-kin general pool to assist with completing this work