Tim Jenness, obs_test has a couple of images from old lsstSim, per the readme. I am not aware of any requirement that data be from a real instrument.

Yes, I know that obs_test has a couple of old sims images. What I'm confused by is that ap_verify_testdata depends on obs_test.

All looks good; I didn't have much to say, but there are a few comments on the _templates PR.

I did not look at the collection structure in the converted repos - I think the code you're using to create them probably guarantees that they're close enough to what we're envisioning that it's not worth holding anything up right now. As a heads up I think we'll want to have another pass at defining those conventions more clearly in the future (RFC-663 is clearly proving to be at least insufficient, and in some cases maybe made poor choices), so these probably shouldn't be considered set in stone (and hopefully the code you delegate to will continue to make changes there propagate through to here automatically - though that may not be the case for code that uses the datasets created here.

It's a bit unfortunate that daf_butler and ap_verify use "dataset" to mean very specific and quite different things, but I'm sure this is now too baked in to both to change, and it's not completely surprising given that the meaning of the word outside our codebase is somewhat ambiguous.

Re. ap_verify_testdata depending on obs_test, I believe we did that because we needed some manner of "real" image data to run tests on and wanted to keep the testdata package from being any larger than it needed to be. Since perfectly acceptable test images already exist, and we didn't want to tie ap_verify_testdata to any particular obs_ package, we went with "generic" image data in obs_test. This could be pretty easily circumvented by putting a copy of the data that's currently loaded from obs_test directly in the ap_verify_testdata repo.