objid not unique?

[kbwestfall]

Hi,

Should the ObjID unwrap to a unique run, rerun, etc? I've run into some examples where it doesn't. I'm specifically working with ObjIDs from DR7. Here's an example where I get the same unwrap result with different objIDs.

from pydl.photoop.photoobj import unwrap_objid
print(unwrap_objid(numpy.array([587722983912112587], dtype=int))[0])
print(unwrap_objid(numpy.array([587722984180548043], dtype=int))[0])

(1, 40, 752, 5, 618, 459) (1, 40, 752, 5, 618, 459)

Thanks, Kyle

[weaverba137]

The ObjID 587722984180548043 has the firstfield bit set, which is 2**28, but is otherwise bitwise identical to 587722983912112587. The firstfield bit was only used in DR7 & prior. In DR8 and later, that bit is always zero. Because most ObjIDs, even in DR7, have this set to zero, the sdss_objid() and unwrap_objid() functions don't consider it.

Could you please let me know where you found those ObjIDs? Since firstfield is a single bit, it is Boolean, so it seems like you have the same object being both flagged firstfield and not firstfield.

[kbwestfall]

I've been trying to get the RA, Dec coordinates for the galaxies in the Simard et al. (2011; http://adsabs.harvard.edu/abs/2011ApJS..196...11S) catalog, and I'm very likely doing it in a stupid way. The example of 587722984180548043 comes directly from the Simard catalog. I convert that to run, rerun, etc using unwrap_objid and then search for the object in the query form here: http://skyserver.sdss.org/dr7/en/tools/crossid/crossid.asp

Because not all ObjIDs returned objects in my DR7 query (for reasons I don't understand; I can provide a list if you want), I have to match the query results back to the input list. So I use pydl.pydlutils.sdss.sdss_objid to convert the returned run, rerun, etc. back to ObjID to do this matching. That's where the inconsistency must have crept in, and where 587722983912112587 comes from in my example.

[weaverba137]

OK, thank you, that makes sense. I'm going to leave this open while I think about how to handle the firstfield bit, since clearly it is needed here. Historically, PyDL was developed with DR8++ data in mind, so this hasn't come up before.