Mission planning

A client job says what was agreed. A mission plan says how one flight is going to happen: the area drawn on the ground, the ceiling, where it launches, where it lands, and where it lands if that goes wrong. It lives on the job's Mission tab, and there is one plan per job.

Anyone in the organization can read a plan. Managers write it.

What a plan holds

• Operating area — a polygon you draw on the map
• Max altitude and planned duration
• Launch, land, and emergency landing points, dragged into place
• Assigned pilots and aircraft, with a free-text role ("lead", "spotter", "survey")
• Links to the job's JHA and its airspace authorization
• Notes for anything that is not on the map

The emergency landing point cannot sit on the launch point. That is the field's whole purpose, so the database refuses the combination rather than storing a plan nobody thought about.

Preflight from the plan

Preflight from plan opens the normal preflight checklist with the plan in view — the ceiling, the planned duration, and the launch and emergency landing coordinates — and records the plan's reference in the flight log's notes.

It is a briefing, not a shortcut. The checklist is still answered by the person flying, and the plan is only what was intended. The logged session remains the record of what actually happened; the two are deliberately different records and the product does not pretend the plan is the flight.

What this is not

• No waypoints or autopilot export. A drawn polygon describes an area a human flies. A waypoint list is an instruction handed to a machine, and BeaconUAV does not fly aircraft — recording a track the product then cannot honour would be worse than not recording it.
• No airspace lookup. The polygon is your drawing of where you intend to fly. Resolving it against an airspace dataset would imply a certainty nobody has, and would need a data provider and a bill.
• No geocoding, no live traffic, no terrain. The map is a drawing surface.