33
edits
Talk:Stand Alone ATC Control Development: Difference between revisions
Jump to navigation
Jump to search
Talk:Stand Alone ATC Control Development (view source)
Revision as of 06:33, 23 September 2010
, 23 September 2010no edit summary
(responses) |
No edit summary |
||
| Line 7: | Line 7: | ||
"A core requirement for a serious ATC system is the ability to handle pilot flightplans. Visually, the ATC client can display a 'flightstrip' (like the paper strips of olden days) or an electronic equivalent. The stack of flightstrips represents the controller's workload. Upon handoff of traffic to another controller, the flightstrip follows." (reeed) | "A core requirement for a serious ATC system is the ability to handle pilot flightplans. Visually, the ATC client can display a 'flightstrip' (like the paper strips of olden days) or an electronic equivalent. The stack of flightstrips represents the controller's workload. Upon handoff of traffic to another controller, the flightstrip follows." (reeed) | ||
: I think, we could use one of the flight planning tools to create flight plans. Internally, Atlas is based on PUI (PLIB GUI), so one could create a custom dialog that resembles a flight strip, that should be easy to do. And creating a stack of flight strips would then show a stack of these dialogs --[[User:Hooray|Hooray]] 15:15, 22 September 2010 (UTC) | : I think, we could use one of the flight planning tools to create flight plans. Internally, Atlas is based on PUI (PLIB GUI), so one could create a custom dialog that resembles a flight strip, that should be easy to do. And creating a stack of flight strips would then show a stack of these dialogs --[[User:Hooray|Hooray]] 15:15, 22 September 2010 (UTC) | ||
:: I was thinking more about the data structure representing an ATC flightplan (of which the flight routing is but a mere ASCII string eg "DCT VTK - A464 - VPG - WMKP"), not the GUI. This data structure requires 1. ownership (eg this acft is currently 'owned' by KSFO_TWR), 2. transferability (this acft is now handed off to KSFO_GND). Where should all this state info reside: on fgms? on the standalone ATC client? inside every individual UDP packet (10 Hz)?? | |||