solve: prefer the estate's own Astrometry.net over nova for blind solves #2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "astrometry-net-fallback"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The estate now runs Astrometry.net itself (ankh-morpork-infra
astrometry/, PRs #168-170): solve-field against ~5 GB of local index files, sized from this repo's own TELESCOPES.md so the whole iTelescope fleet's fields of view are covered (21.5' on T26 up to 10.4 deg on T68).blind.pynow tries it before nova.Why, in the order that matters
nova stays as the fallback, so an estate outage costs speed and privacy, not the ability to solve. It is also the right fallback for fields narrower than the local index set reaches (below ~5.6' quads), which is a deliberate gap: covering it would have cost 32 GB more index data for scopes the fleet does not have.
What deliberately did not change
astrometry_net.pyis a client and nothing more - it does not decide whether to trust a solution, because two gates that can disagree is worse than one that is trusted.estate/nova) is threaded through the log lines, the returnedmethod, and the ASTRSOLV card - a year from now that card is the only way to tell whether a frame was solved in-house or uploaded.Also fixed
astrometry.py's "cannot solve without a blind solver" message, which has been untrue sincerun.pystarted falling through toblind.py.Tested against the live service
.wcsround-trips through astropy (pixel_to_worldon the centre matches)Decision recorded in
state/DECISIONS.md.The estate now runs Astrometry.net itself (ankh-morpork-infra astrometry/): solve-field against ~5 GB of local index files, sized from this repo's TELESCOPES.md so the whole iTelescope fleet's fields of view are covered. blind.py now tries it before nova.astrometry.net. Speed is the least of the reasons - a blind solve of a real DSS field returns in 0.7s where nova queues for minutes. The reasons that matter are that nova requires UPLOADING the master to a third party and holding an API key, and neither is necessary any more for the ordinary case. nova remains the fallback, so an estate outage costs speed and privacy rather than the ability to solve. pipeline/astrometry_net.py is the client and nothing more: stdlib-only POST, parses the returned .wcs so the full TAN solution is used rather than a re-derivation from the summary numbers. It deliberately does NOT decide whether to trust a solution - blind.py already verifies every blind solve against Gaia and applies a star-count and residual gate, and two gates that can disagree is worse than one that is trusted. The source ('estate' or 'nova') is threaded through the log lines, the returned method, and the ASTRSOLV card, because a year from now that card is the only way to tell whether a frame was solved in-house or uploaded. Also corrected astrometry.py's 'cannot solve without a blind solver' message, which has been untrue since run.py started falling through to blind.py. Tested against the live service: blind solve of a DSS2 field with a known centre returned within ~4 arcsec in 0.7s; the WCS round-trips through astropy; and an unreachable service falls through to nova instead of raising.