New ATC client: ATC-pie

[CaptB]

I'd probably look at existing VATSIM/IVAO data (freely available) and write import/conversion routines for those formats to gather a sufficiently large set of routes (or even just ATC sectors).
Equally, such data could be imported into some kind of database (think postgis) and be provided via a central web service for all ATC-pie/OpenRadar clients

Not sure what you mean here as routes are not stored in any local files on the VATSIM clients. These are sent from pilots to the server and the ATC client pulls that from there to populate the strips. Some clients ( Euroscope ) do some checks on those routes, such as checking for a valid SID/STAR and any directional errors on the airways but that's it.

[Hooray]

it's been a while (years ...) since I looked at VATSIM, but back then, they had various data formats, including custom files for ATC sector data and airway routing - the kind of info no longer easily available due to DAFIFT having been pulled years ago.

[CaptB]

it's been a while (years ...) since I looked at VATSIM, but back then, they had various data formats, including custom files for ATC sector data and airway routing - the kind of info no longer easily available due to DAFIFT having been pulled years ago.

What you mention is not FSD network specific, it's just implemented into the client for your comfort. In Euroscope, the de facto king ( especially in Europe ) you have:

AIRWAY.txt - Basically contains a free and very outdated version of the payware NAVIGARPH published AIRAC for another payware product - FS-Navigator ( which you can update if you pay ) This includes airways and can be used to make sure the route is valid.

ICAO_Airports.txt - A list of airports according to ICAO designators with their full names.

ICAO_Airlines.txt - A list of airlines ICAO designators with their full names.

.SCT - A legacy file that comes from the older and simpler VRC. Most of it's content just tells the software HOW to draw static data, such as the sectors, waypoints, navaids, airways, SID/STAR descriptions, and anything else drawn on the screen ( like the aprons, taxi routes ) Used also to be able to give direct routing and other things.

.ESE An expansion to the SCT file to incorporate the advanced Euroscope functionality ( not how to draw static data ) such as radar coverage ( radar holes ) position frequencies, squawk number assignement per sector/position, sector definitions, vertical/lateral limits of sectors , how neighboring sectors act in relation to eachother when they are active/inactive, COPX points....

None of this is actually cared about by the FSD server.

[Hooray]

what is the most lazy-user-friendly way to integrate the most routes, including those who have no route files ready

most people who are serious about VAs and MP, will use airliners and the built-in route manager, which does support exporting to a custom PropertyList-encoded XML format: http://wiki.flightgear.org/Route_Manager



Equally, there are a few free web services that people tend to use to create flight plans easily.

And then there are FG specific application like the "kelpie flight planner": http://sourceforge.net/projects/fgflightplanner/


So I guess it would make sense to conduct a poll among MP/VA users to see what kind of tools they're using for creating flight plans to see how to support those.
Such an effort could certainly involve OpenRadar, especially by being web-based (think AJAX/JSON API with a mySQL back-end).

[Johan G]

I would not be entirely surprised if there is some support for following airways under the hood in in the route manager (though I would not bet on it).

[CaptB]

You can just pull valid routes from vroute ( a vatsim service ) just like qutescoop ( open source on sourcforge ) does, or create own database.

[legoboyvdlp]

I would definitely support that, especially since many route generators give you airways, and so does flightaware/vataware.

[Hooray]

I would not be entirely surprised if there is some support for following airways under the hood in in the route manager (though I would not bet on it).

last time I checked, airway support in FG was not particularly developed/integrated - so it might be worth checking again, as far as I remember, NasalPositioned didn' even provide APIs for the awy.dat stuff back then, even though it's available in FGPositioned: https://gitorious.org/fg/flightgear/sou ... e.cxx#L563

EDIT: ok, seems I was wrong: https://gitorious.org/fg/flightgear/sou ... .cxx#L1928
So, the API is available from Nasal via positioned.airwaysRoute()

Not sure if this is documented anywhere ATM, or if it's even integrated with the route manager dialog (or being used at all) - guess we need to do some reverse engineering then

Also, the C++ code does contain a hard-coded LevelD parser.

[sanhozay]

Is routing via airways important for an ATC client?

Most controllers don't take on a center controller role and generally only control pilots from one of their last waypoints on arrival and up to their first on departure. Most of the time pilots on airways are uncontrolled or merely under radar surveillance. Clearance delivery is supposed to check the route but I think it's more useful for an ATC to import a filed flightplan rather than generate one.

Pilots can generate routes for filing using the route manager (they usually need checking and tweaking) or extenal websites. Import from the ATC website is a great idea. A way of filing a flightplan from the pilot's route manager to an ATC client would also be really useful. This could be as simple as generating a route summary from the route manager (dead easy with Nasal) and dumping it to chat for copy and paste into the flight strip.

[Hooray]

This could be as simple as generating a route summary from the route manager (dead easy with Nasal) and dumping it to chat for copy and paste into the flight strip.

Agreed, I once did that by converting route manager flight plans into FGScript (JSBSim) files for testing purposes (this way, JSBSim standalone could be used without requiring any FG connectivitiy for flying an actual approach):

http://wiki.flightgear.org/Implementing ... st_profile

[Johan G]

I would not be entirely surprised if there is some support for following airways under the hood in in the route manager...

So, the API is available from Nasal via positioned.airwaysRoute()

Not sure if this is documented anywhere ATM, or if it's even integrated with the route manager dialog (or being used at all) - guess we need to do some reverse engineering then

If I know zakalawe/James right, his idea was to at some point have the route manager being able to parse a route as given by the rather well defined format used in real life flight plans (see Field type 15 in my WIP doc on ATS messages).

I vaguely remember this coming up in a forum discussion years back, but unfortunately I have not been able to find it.

If it would be able to do that it would be way more succinct than the current two flight plan xml formats. (Due to different needs the AI subsystem and the route manager uses different formats.) In addition some of us undoubtedly would enjoy being able to use the real life format within FlightGear (me included).

[elgaton]

So I guess it would make sense to conduct a poll among MP/VA users to see what kind of tools they're using for creating flight plans to see how to support those.
Such an effort could certainly involve OpenRadar, especially by being web-based (think AJAX/JSON API with a mySQL back-end).

The most popular flight planning tools I've seen around are:

• RouteFinder (free access area) - free, limited version of RouteFinder. It's easy to use but there is limited control over SIDs/STARs and the route itself (the software outputs the shortest one, just like what the Route Manager currently does). There is no API but the output should be easily parsable.
• SkyVector - has got nice charts and capabilities but access to their API must be paid for.
• RocketRoute - their free version is quite limited, but they offer an intuitive interface and I like the ability to generate a complete flight package (including weather charts, surface winds, probability of icing and NOTAMs). No API though (as far as I know of).
• Professional Flight Planner X - offline, Windows-only software. Judging from the screenshots, the interface is extremely detailed.

Also, mpserver15 offers a planner module.

I'd say to solve the old "navdata database" problem first by reaching out to the X-Plane people and asking if they're willing to expand the Airport Gateway to include navigational data (I asked a couple of months ago if they had any plans to do so, they told me not, I guess because of available time constraints, but if they're willing to open the Gateway source code and it's written in a language I know/I can learn, I'm willing to work on it). Failing that, I can write it from scratch. (I have already looked around for open navigation data sources, however there is none that is GPLv2 compatible).

Once that problem is solved, I can look into adding an UI/API to Lenny's website.

Due to personal reasons (family matters and a Master's thesis on its way) I won't be able to begin coding until late March, but I'm willing to work on this after that date.

[mickybadia]

Thank you all for the ideas, and for sharing your general knowledge about the related tools, much of which I was not aware of. All my flying experience goes irl, and my virtual aviation time I rather spend controlling (or now programming this!) so I am not much familiar with the pilot p.o.v. in FlightGear.

After reading you all:

Most controllers don't take on a center controller role and generally only control pilots from one of their last waypoints on arrival and up to their first on departure.

Agreed, but this lack of enroute controllers is arguably both the reason for and the consequence of our lacking enroute ATC facilities. Moreover, I think it makes little long-term sense to work towards disseminating hand-offs (which are fun) and still think ATCs will be releasing pilots uncontrolled out of their airports most of the time. So I would think it a good idea to make a step towards route management and enroute flight control, at least to the extent that is already in reach.

most people who are serious about VAs and MP, will use airliners and the built-in route manager, which does support exporting to a custom PropertyList-encoded XML format: http://wiki.flightgear.org/Route_Manager

This type of waypoint list is probably the first thing to go for. It is already there in FlightGear, and can be achieved easily enough on the ATC side. From what I understand, this will still leave the more subtle SID and STAR paths for the controller to draw, à la OpenRadar, with only the format to decide on. In any case I do not want to rely on any pay-for resource.

Import from the ATC website is a great idea.

Already in place and integrated in ATC-pie: FPL download, creation and modification on lenny64's flight plan data base. It is popular among ATCs posting events, pilots filing FPLs and I think already used by a couple of VAs. OpenRadar retrieves data from it as well, and dev status is active with Thibaut regularly working on it. As far as I'm concerned, the de facto service to use for FPLs.

A way of filing a flightplan from the pilot's route manager to an ATC client would also be really useful. This could be as simple as generating a route summary from the route manager (dead easy with Nasal) and dumping it to chat for copy and paste into the flight strip.

Rather sending it to lenny's DB! It only takes a one-shot TCP connection, and they'll be immediately visible to all controllers.

If I know zakalawe/James right, his idea was to at some point have the route manager being able to parse a route as given by the rather well defined format used in real life flight plans (see Field type 15 in my WIP doc on ATS messages). ... If it would be able to do that it would be way more succinct than the current two flight plan xml formats. ... In addition some of us undoubtedly would enjoy being able to use the real life format within FlightGear (me included).

To be honest I don't think one can claim an actual standard format for route description, but my preference would also go to a well-specified string format incl. sequence of waypoints, possibly filled with unambiguous FL and/or AWY specs. Any decent language will allow easy splitting, and all three OpenRadar, ATC-pie and lenny64 already have a string-typed field for routes. I have seen code in OpenRadar adding commas in between when exchanging, but nothing is really done so far other than exchanging strings. So there is stuff to discuss, but imho dev-related stuff should go to a different place?

[Hooray]

[I'd say to solve the old "navdata database" problem first by reaching out to the X-Plane people and asking if they're willing to expand the Airport Gateway to include navigational data (I asked a couple of months ago if they had any plans to do so, they told me not, I guess because of available time constraints, but if they're willing to open the Gateway source code and it's written in a language I know/I can learn, I'm willing to work on it). Failing that, I can write it from scratch. (I have already looked around for open navigation data sources, however there is none that is GPLv2 compatible).

Also see: viewtopic.php?f=5&t=15665&p=207549&#p207549
and: viewtopic.php?f=5&t=23562&p=230269#p222122

[elgaton]

Turning back on topic, I've tested the client - I think it might be useful to port some features from OpenRadar:

• the callsign change feature - right now, the client connects to the multiplayer network with the callsign ICAOobs, so it's impossible to have multiple controllers (ground+tower+center) manning the same airport;
• displaying the localizer "cone" (as done in OR and on the FlightGear Map dialog) instead of just the extended runway centerline - this would help ATCs to know if the aircraft can catch the localizer when a plane is not performing a straight-in approach;
• the airport selection dialog - I had to read the source code to know I needed to pass the ICAO code on the command line, and I believe a graphical interface for that would be more helpful, especially towards non-savvy users.

As for the rest, keep up the good work!