Update Mauna Kea coordinates for CFHT, Keck and Subaru - #174

Hi 👋 and thank you for your contribution! 🙏

This pull request is being closed automatically - but don't worry, we may re-open it if you carefully follow these instructions.

Join the astropy slack using this invite link, head over to the #new-contributor-requests channel, and introduce yourself with a post that includes:

1. Background about your current occupation or affiliation.

2. How the bug or missing feature affects your work.

We strongly encourage contributions from people that use astropy or actively develop related scientific Python packages. We look forward to hearing from you and growing the Astropy community!

Notes for maintainers

If you know this is a genuine user and the PR is is compliance with the AI policy, you may re-open this straight away. After two successful merged pull requests, the user will be added to the allowlist and future PRs will no longer be closed automatically.

This user has not made any pull requests to this repository prior to this one.

In addition, here are some statistics on the user's activity on GitHub:

@hamogu should we reopen?

Yes, we should reopen since I specifically requested this PR. Sorry about that @Sting1JP . We're trying to find a balance that avoids maintainer burn out by random drive-by PRs. With LLMs, we're seeing hundreds of PRs by people who have no connections to astronomy, are not coming back, and won't ever become maintainers putting in human time. While their PRs are often technically correct and useful, we've been overwhelmed with review work in the last few months, so we put in this extra step. However, after a few PRs, you should automatically we added a white list so that bot recognizes you and doesn't autoclose your PRs any more.

@hamogu No problem at all, I understand. Thank you!

Fun fact, astropy uses Keck data for its tests... 😅

Sorry for the... surprise 😅

After this I went looking for similar issues, and found a few things.

Two more places still show the old Keck values: the example in the EarthLocation.of_site docstring (astropy, coordinates/earth.py) and two Observer docstrings in astroplan. I can send PRs for those if it helps.

I also compared the other IRAF entries with the MPC observatory codes, since that's where the Keck and CFHT values came from. ekar (Asiago 182 cm) is 940 m too far east: the file has longitude 11.58113, INAF's telescope page gives 11° 34' 08.397" E (11.56900) and MPC code 098 agrees. The latitude is OK. Would a PR for that be welcome? I checked that nothing in astropy, astroplan or astroquery uses ekar, so no test should break this time... hopefully.

spm and mso look wrong too (2.8 km and 1.5 km), but I don't have sources I really trust for those yet.

astropy is already accounted for (astropy/astropy#20819) and I am sure @tepickering won't mind if you patch astroplan. Thanks!

astropy is already accounted for (astropy/astropy#20819) and I am sure @tepickering won't mind if you patch astroplan. Thanks!

i would say file an issue with astroplan. astroplan should use what astropy provides rather than be redundant. having an issue will help me to remember to do that refactor…

I also compared the other IRAF entries with the MPC observatory codes, since that's where the Keck and CFHT values came from. ekar (Asiago 182 cm) is 940 m too far east: the file has longitude 11.58113, INAF's telescope page gives 11° 34' 08.397" E (11.56900) and MPC code 098 agrees. The latitude is OK. Would a PR for that be welcome?

PRs with improvements are always welcome!
I went through the git blame and it looks like the observatories you list are originate from a historic IRAF datafile. Coordinates look rounded, possibly because the precision was limited to single precision float or by the format of the file size.