Agreed... with one addition. The "old-school" flying basically uses the chart
to filter this information. Looking at the chart that you presumably have folded open
to where you are limits the scope of things you can look up to things nearby. I'm not
sure there's a good answer to it.... typically problem finding a good way to filter
through of too much information with a minimum amount of interraction.

-Cory
Teacherjh wrote:
:
: I don't want to have to poke the GPS dozens of times to find out
: where I am relative to something else
: (poke-poke-twist/twist-'K'-twist/twist-'P'
: -twist/twist-'S'-twist/twist-'K'-twist/twist-enter). I like the simplicity of
: dialing
: '116.8' and seeing a DME.
:

: This has less to do with the GPS than it has to do with the idea of putting as
: many functions as possible into as few buttons as possible. With all that
: computing power, it's got to be fairly simple to have a dedicated knob that
: just cycles through the "nearest" identefiers. Chances are whatever you are
: looking for is contextually near something you just did, and cycling
: alphabetically through the fifteen choices would be much quicker.

: For example, in a flight plan, it would cycle through the nearest identifiers
: to the previous entry. The knob would pull out to include (or omit)
: intersections. The Apollo unit in our aircraft does something like this
: already, but with less smarts.

: I tend to use the #2 nav/comm because the knobs always do the same thing. On
: the Garmin, I have to be sure I'm in the right mode and have selected NAV or
: COMM before twisting. I'd rather just have another knob. In the cockpit that
: is more important than geeky button efficiency.

: Jose

: --
: (for Email, make the obvious changes in my address)

--
************************************************** ***********************
* The prime directive of Linux: *
* - learn what you don't know, *
* - teach what you do. *
* (Just my 20 USm$) *
************************************************** ***********************