...
(We are accumulating debt the longer we don't have this.)
RHL: the transformation from object ID to e.g. visit ccd objId or tract patch filter objId as appropriate needs to work on numpy arrays. Having written these things, I think the best return type is a dict of numpy arrays. Presumably the current butler's dislike for numpy integer types (actually mysql's dislike) will have been fixed by then.
Unknown User (npease): Jira server JIRA serverId 9da94fb6-5771-303d-a785-1b6c5ab0f2d2 key DM-4182
...
Most cameras (the only exception I can think of is SDSS) have a focal plane layout in which each raw data unit can be completely identified merely by specifying an integer for the visit and an integer for the sensor number, and the visit number fully specifies the filter (via registry lookup). This may not be the preferred way of referring to a particular data unit for that camera (e.g. LSST may use rafts, and for some data products also has snaps; other cameras may prefer "ccd" over "sensor"), but if these standard keys were also available for all cameras that could support them it'd be much easier to write camera-independent code. This may require a hierarchy of mapper base classes, with most cameras inheriting from a common base class one level below the top of the hierarchy; algorithms that assume a visit/sensor layout would only be valid on mappers that inherit from that intermediate base class.
RHL: We decided long ago not to require a pre-defined set of names for the items of the data Id (ccd, ccdnum, sensor) and I hope that we're not moving away from this. I understand the desire to make "raft" optional, and I support this. One useful facility would be for a mapper to define an alias e.g. from ccdnum to ccd (an example that the DecamMapper would use).
(Likely a requirement for camera-generic relative astrometry; UW to set schedule?)
...