7
edits
Stand Alone ATC Control Development: Difference between revisions
Jump to navigation
Jump to search
Stand Alone ATC Control Development (view source)
Revision as of 16:54, 2 December 2010
, 2 December 2010Added section about ideal ATC client, based on my experience with IvAc
mNo edit summary |
(Added section about ideal ATC client, based on my experience with IvAc) |
||
| Line 208: | Line 208: | ||
Why the project has stopped? Because I was unable to send a correctly formatted UDP packet: the position message is different from C++... this was until I discover [http://www.swig.org/ swig] ([http://pigeond.net/git/?p=flightgear/fgmap.git;a=blob;f=sg_perl/README which is used on FGMap]). Swig can be the solution to allow a revival of autoATC, which is next on my TODO list. | Why the project has stopped? Because I was unable to send a correctly formatted UDP packet: the position message is different from C++... this was until I discover [http://www.swig.org/ swig] ([http://pigeond.net/git/?p=flightgear/fgmap.git;a=blob;f=sg_perl/README which is used on FGMap]). Swig can be the solution to allow a revival of autoATC, which is next on my TODO list. | ||
=The ideal ATC client= | |||
An ideal ATC client should provide: | |||
'''Graphics:''' radar-like appearance, so that distraction due to visual elements is kept minimal. With respect to that, it should be customisable what types of elements should be shown and hidden, or even show/hid subsets of those (by name, by altitude,...). This is due to personal preferences or position types (ground doesn't need fixes, or approach doesn't need taxiways). Amongst those elements (some are really optional): | |||
*Navaids | |||
*Fixes | |||
*Runways | |||
*Taxiways | |||
*Extended runway centerlines | |||
*Geographic elements: water, coastlines | |||
*Range rings | |||
*Aiplanes | |||
**Label | |||
**Speed vector | |||
**Recent path | |||
**Flight plan route | |||
*FIR/UIR boundaries; CTR/ATZ boundaries; etc. | |||
*Departure/Arrival standard procedures. | |||
All this in a non-distracting way for the controller. | |||
All those elements should be read from the FlightGear Scenery, so that pilots and controllers share the same data. | |||
'''Voice:''' FGCom as external application is OK. | |||
'''Chat messages''' to/from other pilots and controllers. | |||
I don't think the radar client should connect as a fake pilot. In my opinion, the MP protocol should be extended so that controllers could login as such. | |||
Labels should keep the minimal information needed. That means that traffic under the ATC's control should display more info that traffic out of his control. | |||
==Atlas as a starting point== | |||
The way I see it, the only thing that Atlas can offer is the code that reads the scenery files. Personally I don't see an ATC client coming from an Atlas fork, or a highly customisable Atlas. In the beginning it can make things easier, but in the long run, I personally think that the structure of one project is different from the other, with different objectives. However, pieces of source code might be reused from Atlas, of course. | |||
There is another application in IVAO, called IvAe, which consists of a "Google Earthish" interface that shows all the pilots and controllers connected to the network, and you can retrieve much of their info (flight plans for pilots, ATIS for controllers, etc.). In this case, Atlas would be a good starting point for that. | |||
==IvAc== | |||
IvAc is the ATC client of the IVAO network. It has all those elements and many many more. This piece of software was developed mainly by Kenny Moens and Filip Jonckers, two guys from the IVAO Software Development department (of which I was member some time ago). Filip is a real-life Air Traffic Controller. I've emailed them asking if they would be willing to give a hand. No reply yet. | |||
=Related= | =Related= | ||