On 1/3/07, John Denker <[EMAIL PROTECTED]> wrote:
First, some background information. Suppose we are up in the air,
10 nm west of KXYZ airfield (which is colocated with the XYZ vortac).
[snip]
To summarize: With rare exceptions, locations are specified using the
bearing /from/ the reference.
Also note that in all cases these are /magnetic/ bearings.
So ... I recently used the location-in-air popup menu for the first time.
I selected a distance of 25 nm and an "azimuth" of 270. I had no doubt
that this would put me 25 miles west of the station.
Imagine my astonishment when it put me 25 miles east of the station!
Yes, that does sound confusing ...
An additional nuisance was that this location was /true/ east not
magnetic east.
Just to add to the excitement, this put me below ground level, in
the mountains east of the station. But that is only tangential
to the present discussion.
Computers just do what you tell them to do. :-)
One final remark: Pilots talk about radials, courses, and bearings.
The word "azimuth" is not used much. It's a perfectly fine word,
and certainly has its place in the /internals/ of a flight simulator.
OTOH there are lots of users (including me) who want the user interface
(i.e. pilot interface) to be as realistic as possible.
The existing location-in-air popup is shockingly unrealistic from a
pilot's point of view. This needs fixing. The tricky part is fixing
it in a way that doesn't break legacy usages.
I suggest we start by making the following distinctions explicit:
--true-bearing-to
--true-bearing-from
--mag-bearing-to
--mag-bearing-from
Currently, the command-line interface implements --azimuth, which is
documented to be "to" the reference, and is apparently equivalent to
--true-bearing-to. That's OK with me as far as it goes.
1) I suggest that the command-line interface be extended to support
the four explicit bearings itemized above. We can continue to support
--azimuth as a fifth option, synonymous with --true-bearing-to, but
it should be mildly deprecated on the grounds of ambiguity.
I think that --azimuth itself is a rarely used option so I would be a little
hesitant to split that into 5 options, none of which will probably be used
by more than one or two people. I think it makes a lot more sense to focus
on the gui dialog box.
2) I suggest that the location-in-air popup be revised so that it
uses the equivalent of --mag-bearing-from, not --azimuth.
As part of this, I suggest changing the wording on the popup from:
Azimuth (deg): ___
to
Bearing: ___° mag from
I don't think this will break any of the documentation, because
AFAICT the location-in-air popup isn't documented in any detail
anywhere.
I'd be happy to try implementing this myself, but I would appreciate
some help or at least hints.
*) I've already changed the appearance of the popup. Easy.
*) I spelled out "deg". I tried putting the ° symbol in the
xml file, but it complained of a parse error. Using °
didn't work, either. Any suggestions on how to encode symbols?
Our font has a very limited number of characters available so I don't think
this symbol is available.
*) I tried putting <offset>180</offset> and
<offset>/environment/magnetic-variation-deg</offset> commands
in the location-in-air.xml file, but the system appeared to just
shrug them off. No effect. What's the trick?
I think there will need to be some support in the code for this. It's easy
to compute the local magnetic variation for some lon/lat, but the dialog
boxes just set property values and trigger internal function calls (and
maybe a bit of nasal here or there.)
The reposition dialog box doesn't do any nasal, it just sets a bunch of
property values and calls the reset function.
So in this case I think what needs to be done is to modify the reset
function (in a backwards compatible way) to understand the property values
that are set from the dialog box and do the right thing with them.
Has this issue come up before? I didn't see any sign of it.
I'm not aware of this issue being brought to light in the past. I suspect
that most people don't do a lot of complicated initial positions, but we do
want this to work intuitively so I would welcome any changes to improve the
in-air reposition dialog box.
Regards,
Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
