Re: [Atlas-devel] Marking a route feature

[Brian S. <bsc...@us...>]

>>>>> "Geoff" == Geoff McLane  writes:

    Geoff> Unfortunately, in freeglut WIN32, a Ctrl+space does NOT
    Geoff> return a zero (0) key value! It returns a space, ' ' ;=((

Well, it's not clear whether the problem is OS X or Windows.  But it
looks like we'll need to #ifdef some of these things.

    Geoff> The 'j' edit widget, search_interface, is initialized with
    Geoff> the last, which then only shows 1 item in the list, but as
    Geoff> you delete it back to the Y, it presents a list in what looks
    Geoff> like distance ordered? points, which is great.

[...]

Search results are sorted solely by distance, and make no attempt to put
any type of object (airports, VORs, ...) first.  I've never noticed a
slowdown on my machine, and it's a 5-year-old laptop - I figured if it's
responsive on my machine, it should be good everywhere.  Note that if
you want to delete the string in the search field, ctrl-u will delete
everything before the cursor (at least on OS X, and probably all
Unixes).

A few notes about using the jump facility:

- Items in the list can be selected with the mouse (the list remains
  up).

- Down arrow, up arrow, page down, and page up can be used to quickly go
  through the list.  As each item is selected, Atlas jumps to that item.

- Hitting escape will cancel everything, remove the list, and return
  Atlas to where you were *before* the search started.

- Hitting return will jump to the selected item (or the first one if
  none have been selected), and remove the list.  Note that there's no
  requirement for the list to have a single item.  If you type 'KSFO
  <return>', you'll end up at the outer marker of runway 28L ("MKR: OM:
  KSFO 28L").

- The labels attached to different types of objects ("MKR:" for markers,
  "ILS:" for ILSs, "AIR:" for airports, ...) are also searchable.  So,
  if you want to find all nearby VORs, type "VOR:".  Unfortunately,
  results are not guaranteed to be added in order of distance, so you'll
  have to wait for the search to finish to be truly certain that the top
  result is in fact the nearest VOR (of which there are 3688).

    Geoff> And of course, an ADDED feature, if it does not already exist
    Geoff> ;=(), would be to save this 'route' in a fgfs compatible
    Geoff> form, to present to fgfs as a '--flight-plan=file'...

    Geoff> And then Atlas could also have a 'load route file', to put
    Geoff> back the last chosen route...  maybe using the same
    Geoff> --flight-plan=file...

I've thought a lot about flight plans, but so far I haven't come up with
a satisfactory approach.  Here are some of the issues:

(1) What is the FlightGear flight plan file format?  I've seem some
    discussion on the forums:

    http://www.flightgear.org/forums/viewtopic.php?f=17&t=6267

    and also on the wiki:

    http://wiki.flightgear.org/index.php/Route_Manager

    As far as I can tell, there's an old format and a new, XML-based
    format, but I can't see a definition of either, nor do I know if and
    when the new format will be officially made part of FlightGear.

(2) What is the FlightGear internal flight plan structure?  By this I
    mean the representation used internally by a running instance of
    FlightGear.  From what I've seen by observing FlightGear, it has 6
    pieces of information for each waypoint (altitude-ft, altitude-m,
    ID, latitude-deg, longitude-deg, and name).  These are all placed in
    the property tree under /autopilot/route-manager/route.  My notes
    don't show where it stores the departure and arrival airports and
    runways.  Anybody know?  

    I also don't know how FlightGear would react if Atlas starts
    manipulating its property list.  Is there an officially-sanctioned
    way to push a flight plan over to FlightGear?

(3) SIDs, STARs, IAPs

    Ah, what would aviation be without incomprehensible acronyms?  For
    those of you not in the know, these describe "partial flight plans"
    covering officially-defined ways to leave (SID), approach (STAR) and
    approach (IAP) an airport (where STAR gets you close and IAP gets
    you on the ground).

    It would be nice if any Atlas flightplan format could handle
    defining these things.  There are two issues - the actual format
    used to define them, and then a source of data (assuming we don't
    want to create them all ourselves, and I'm pretty sure we don't).

    There is an industry standard, AIRINC, but it is proprietary.
    Here's the website if you don't mind sitting through a ton of
    unnecessary Flash downloading:

    http://airinc.com

    Also, there once was a free public source of SIDs and STARs via
    DAFIF published by the FAA (in fact, a lot of FlightGear's original
    airport and navaid data came from there via Robin Peel at X-Plane),
    but it was removed several years ago.  Now you have to pay.  A
    source used by the MSFS community is here:

    http://ndac.navigraph.com/www/fmsdata.asp

    There is also a standard defined by Eurocontrol, which I think is
    the official air-traffic control service for the European Union.
    Unlike AIRINC, they have made everything public.  It's very well
    documented, but really big - overwhelming really.  An overview can
    be found here.

    http://www.eurocontrol.int/aim/public/standard_page/aixm_overview.html

(4) Routes

    A route (in my terminology here) is basically all the stuff after a
    SID and before a STAR.  It generally doesn't specify altitudes
    (except maybe to differentiate between jet and non-jet routes), or
    speeds.  For example, the US government has a set of preferred
    routes:

    http://www.fly.faa.gov/rmt/data_file/prefroutes_db.csv

    I don't think this is some standard format.  For example, ICAO has a
    standard, although aside from a few examples, I can't see a complete
    definition of it.  Here's one:

    http://www.flysouth.org/icao-rt.htm

    And here's an ICAO flight plan:

    http://www.flysouth.org/icaofp.htm

    Note that a flight plan specifies speeds, altitudes, aircraft, etc.

(5) Flight Tracks

    These are the existing Atlas flight tracks, which basically consists
    of a series of positions, with some extra information, notably radio
    settings.

    Ideally we could merge everything together - flight plans, routes,
    SIDs, STARs, IAPs, and flight tracks.  All basically specify paths
    through 3D space, but each with their own unique contraints (eg, a
    SID can have multiple paths, but a flight track of course only has
    one).  Is it possible to design a generic flight path that could
    somehow subsume all of these?  Even better, is there an existing
    public standard that we could use?  Even more better, are there
    pre-defined SIDs, STARs, IAPs, and routes defined in that standard?

I look forward to hearing your opinions.

Brian