I'm not sure what the full scope is for these tables, but it may also be useful to have the merge_measurement_band flags as well. These tell you which band was used for the "forced" measurements.

While someone is in there, I also noticed that calib_psf_used appears in two places (I can't say for sure if that was oversight or deliberate...if it comes from ref I think it'll only be appropriate for the "reference" band, but it looks like all bands get an entry in the objectTable_tract tables...paging Yusra AlSayyad ):
https://github.com/lsst/obs_subaru/blob/master/policy/Object.yaml#L321
https://github.com/lsst/obs_subaru/blob/master/policy/Object.yaml#L354

Fred, changes are required in obs_lsst, sdm_schemas too.
And must pass a ci_hsc Jenkins run to merge.

Changes have been made. I tested ci_hsc locally, so now I'm waiting on the Jenkins build.

Hi Jeff,
Would you mind reviewing this ticket to propagate the flags to Object tables?

Thanks,
-Fred

Lauren MacArthur I can't find `merge_measurement_band` in the lsst github search. Which task generates it? I need to know the datatype.

I don't have an Object table at hand, but I think that this should be `merge_measurement`, and the band is appended during table creation?

They get set here:
https://github.com/lsst/pipe_tasks/blob/master/python/lsst/pipe/tasks/mergeMeasurements.py#L247-L252

Question for Lauren MacArthur or Lee Kelvin – is `merge_peak_sky` the recommended way to select sky sources/objects? I recall something more explicit ("sky_source"?) in the past.

I think that `sky_source` is for single visits and when they are merged then `merge_peak_sky` is used on the coadd catalogs. If this creates a conflict then we should probably create a new `isSky` flag and set that for both single visits and coadds.

Ah, thanks. I feel like `isSky` would be more intuitive, but it's not absolutely necessary...

PRs have been reviewed. We decided that `merge_measurement` flags will be left for a later ticket, since it's unclear how to handle them.

The PR for `sdm_schemas` may need clarification from Yusra AlSayyad.

Jeffrey Carlin, yes, Fred Moolekamp's reply above is correct: sky_source for visit level sky source identification, and merge_peak_sky for coadd/object level sky object identification. I'd certainly be in favor of a unified isSky flag however.

Created DM-30353 and DM-20354 for creating the `isSky` column and adding `merge_measurement` column respectively.

Jenkins build is successful on centos-7 but I'm still waiting on mac-os (https://ci.lsst.codes/blue/organizations/jenkins/stack-os-matrix/detail/stack-os-matrix/34306/pipeline/56/). Jeffrey Carlin is it ok to merge when the Jenkins build passes? If not, what still needs to be done?

Jenkins build passed. Waiting on reviewer approval to merge.

If you merge this, I'm just going to change Merge_peak_sky back to merge_peak_sky behind you. Users aren't going to remember that there's one column that starts with a capital.

Since I'm on the west coast, I'm happy to fix it on this ticket, re-Jenkins and merge it before midnight.