Re: [Flightgear-devel] FlightGear-1.99.5-RC2

[John D. <js...@av...>]

On 12/16/2008 03:05 AM, James Turner wrote:

> The dialog box behaviour, is that it explicitly clears out the current  
> lat/lon before doing the navaid/fix search, so we get the same  
> behaviour from the GUI - at least it's consistent.
> 
> My proposed fix is to add a 'base position' or similar to the  
> properties, and use this as the start point for spatial searches in  
> the position init code. When running from the command line, I'll leave  
> it unset to avoid surprising anyone with new behaviour, but once we're  
> started I'll use the current position, which should make the GUI  
> dialog work as expected.
> 
> However, I'm not sure doing any of this is wise for 1.99.5, better to  
> do it after the release and let it get some testing, since there's so  
> many permutations of position-init command lines.

I reckon JT's previous estimate -- "low hanging fruit" --
is closer to the mark.  (Guess how I know.)

I don't think a "base position" is needed.  A notion of 
"current position" sufficies.  As for the CLI, it is useful
to process the positioning items _in order_ so that going 
to --airport=KJFK and then to --vor=SAV will reliably get 
you to Savannah, GA ... whereas specifying the options in
the reverse order would have a different meaning.

   Other options obviously need to be processed out-of-order,
   notably --help --verbose.

Of course the "locate" dialogs should not clear the current 
position.

I suspect there is little risk of unhappy surprises.  Very
few pilots intend to relocate from KSFO to Savannakhet in 
one step.

This affects not just the CLI and the GUI, but also some
RNAV units.

I wrote the code to do this years ago, and have used it
a gazillion times since.  It works fine.  The concept
is simple:
 -- Start at the lowest level.  Whenever anybody looks
  up an ID, always fetch *all* the matching IDs.
 -- Always sort the list according to distance.
 -- Then, at the next higher level, if somebody wants
  only one match, give 'em the _nearest_ match.

These bugs arose because there were N different pieces
of ID-match code in FGFS.  Recently JT has been fixing
that, so I reckon almost all of the infrastructure is
in place to make this bug go away once and for all,
hardly even as a bug-fix, but as a natural consequence
of a more general clean-up, which is usually the nicest
way for things to happen.

===========

While we're in the neighborhood:  It would be good to
make all ID-matches become case-insensitive.  I wrote
the code to do this years ago.  It's very simple and
very helpful.