-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
io.load_tiles defaults to old tile list $DESIMODEL/data/footprint/desi-tiles.fits #167
Comments
I'm fine with something like that as the default if present; feel free to submit a PR. |
@ashleyjross: You can assign me to this task, if you'd like. I'm a little busy today but could get to it later in the week. |
@geordie666 that would be great, thanks! |
just a comment, in case, about
of course, such operations are never done on validated tiles; but the list of "potential tiles to be observed in the future" could in theory slightly change with time. |
I agree about all of these caveats. The most important, thing, though, is that if used in default mode it won't somehow yield a smaller footprint than what has already been observed (like it does now.) |
Addressed in #168. |
Can we make it point to the main survey tile list instead (/global/cfs/cdirs/desi/survey/ops/surveyops/trunk/ops/tiles-main.ecsv) or something equivalent? (This would include all of the backup tiles, but we want to be inclusive here, I think.)
This has caused problems with people making mocks and assuming
tiles = desimodel.io.load_tiles()
point = foot.is_point_in_desi(tiles, ra, dec)
would cut to anything that could possibly be observed in Y1. (The actual tiles are different around the edges.)
We will of course work around (explicitly using correct tile lists), but it would be very good to not have this issue happen again for anyone in the future.
@schlafly (let me know anyone else to tag)
The text was updated successfully, but these errors were encountered: