Observatory settings

Azimuth protection

Obs.Control ends Telescope settings with Filter flats. Weather Settings ends with Azimuth protection, shared by the telescopes belonging to that WeatherSentinel.

Each of the three polar maps contains 90 independent 4-degree slices. North is 0 degrees and azimuth increases clockwise through east at 90 degrees. A slice covers every altitude. Select a colour and paint with a click, drag, or keyboard Enter/Space. Fill-map, copy-previous-map, and reset controls edit the draft; Save azimuth protection applies it.

The maps apply from observing begins to time A, from A to B, and from B to observing ends. Defaults are 22:30 and 02:30 in the observatory's civil timezone, including daylight-saving changes. Times after midnight belong to the same observing night. B follows A within the existing local-noon-to-noon night; equal times are allowed and give an empty middle era. No duration or exposure quality threshold is added.

Blue does not impose a minimum queue size or delay: a blue request remains eligible when no green request can run. Existing telescope-scope, funding, Moon, and FIFO ordering apply within each colour tier. All calendar durations can accept orange/blue risk, including long exoplanet events.

Calendar writes assess every defined project/sequence target over the full booking, with moving-target positions evaluated at assessment time. Checks run on creation and modification, including frontend copies, drags, resizes, and night-window correction retries. Risk acceptance is tied to the site, maps, target definitions, and booking times. It is recorded with a server timestamp. Red never offers an override. Automated transit submission reports a refusal when the event would need risk acceptance; users can book it explicitly. Undefined target positions are recorded as unassessed diagnostics rather than inventing a new booking prerequisite. Real-time reservations without a target have no predicted track; OBS applies red checks when pointing is requested.

The track evaluator includes minute anchors, exact era changes, and adaptive refinement across sector boundaries, north wrap, and azimuth turns. Numerical resolution is one millisecond; it is not a fit/quality rejection threshold. OBS also refuses commanded red pointings and reports orange/blue project warnings.

Shared data and deployment

wema_settings.azimuth_protection contains time_a, time_b, and periods (three arrays of 90 colour names). Missing settings are independent green maps. The save command is set_azimuth_protection. Hub owns the saved settings and does not let stale WEMA telemetry overwrite them. WEMA applies the same schema and supports the command through its local console.

Hub includes the maps and azimuth_protection_timezone in existing enclosure snapshots. OBS retains those fields and forwards them in FIFO polling. Arbiter assesses the complete estimated observation, rejects red/orange tracks, and includes diagnostics on rejected candidates and selected blue work. Its exact top-k pruning uses a green lower bound so it cannot discard a later green candidate in favour of an earlier blue one. Active time-dependent maps require a valid observatory timezone to evaluate their eras.

Keep azimuth_protection.py identical in Hub, CodexOBS, CodexWEMA, and Arbiter. Deploy Hub and Arbiter before updated OBS, then WEMA. Hub's enclosure projection provides authoritative maps even before WEMA is updated. Older OBS versions do not forward maps or enforce red pointings, so all affected OBS clients need the update before relying on protection. Local tests and browser fixtures do not establish deployed-worker or hardware behavior.