We can definitely do that.
Do you really need the date/seeing/snr in a list, or is what you’re actually interested in some final value X at that point? Either way, I think sims_maf could be useful.
If you have an algorithm to calculate your value X, you could write a simple ‘metric’ (see https://github.com/LSST-nonproject/sims_maf_contrib/blob/master/tutorials/Writing%20A%20New%20Metric.ipynb)
and then combine it with our framework so that you can calculate X at either a few points on the sky or all over the sky. Like most of LSST, we’re still working on the docs, but a basic intro is https://github.com/LSST-nonproject/sims_maf_contrib/blob/master/tutorials/Introduction%20Notebook.ipynb.
What you gain by using sims_maf is that you won’t have to grab the exposures which overlap your points by hand (note that opsim pointings overlap slightly) and you can experiment with different dither patterns if you’d like, without modifying anything but the configuration.
We have a function that will turn m5 for a pointing (recorded in opsim output) + magnitude of a star into a pretty close value of SNR, and there are some methods in sims_photUtils that will more precisely calculate SNR (because they actually calculate ‘gamma’ for each visit)
https://github.com/lsst/sims_maf/blob/master/python/lsst/sims/maf/utils/astrometryUtils.py - m52snr
https://github.com/lsst/sims_photUtils/blob/master/python/lsst/sims/photUtils/SignalToNoise.py - calcSNR_m5
Note that opsim provides two values related to seeing - FWHMgeom and FWHMeff. For calculating SNR, you want FWHMeff (there is some more explanation of the difference of these in http://smtn-002.lsst.io/en/latest/
