Menu
▾
▴
#1778 incorrect HUD values
the HUD gives the location as
35.000000N -26.000000W
i don't know about you but to me a Negative West longitude is east of the Zulu meridian... -26.000000W should be either one of "26.000000W" or just plain old "-26.000000"...
shouldn't it??
this same type of flaw is also seen when south of the equator...
FWIW: the location above is a couple of hundred miles south of Ponta Delgada, Azores...
There is no bug here. The poster has confused the parenthetical form of the lat lons with a math equation.
That is, we don't subtract -lons from West to get an East. This is not a math problem and once someone is trained to recognizance what they are looking at then they immediatly notice that this is not a math equation but a string, a sentence.
What we have here is a parenthetical form where +(ommited) equals North lats and East lons, and -(minus) equals South lats and West lons.
Just as I can put the minus sign on either side of a number:
Example
-10
10-
I can replace the second minus with W or S in the case of lons and lats.
So -10W and 10E are proper forms.
So is -10S and 10N.
Its similar to saying W10- and E10+ and S10- and N10+, but we don't do that.
--Ray
Using the minus sign AND West or South is not a standard. I could not find a single use of this type of notation: GPS data, maps, charts, etc., all use EITHER the minus sign or the letter.
And by the way, this is also the case in the HUD when it concerns the south latitude: they are displayed as, for instance, -23.000000S.
One thing the HUD format does well currently is relieve the confusion between what the Initial position start up uses as a format, and what custom groundnet parking uses as a format.
Initial positions use the Signs alone. That is they either omit the + or include the - but what they don't use is the alphabet characters and they use the Decimal Degrees format.
What groundnets use is the alpha letter at the front of the number portion in the place of a sign and that number portion denoted in degrees decimal minutes.
The HUD as it is makes finding positions for either thing, the init pos and the parking, and also placing an object with the UFO clear to the person using the HUD.
The N-S or E-W at the end of the signed number ( N and E omit the sign as is done in math for positive numbers ) takes the place of having to include the words LAT and LON, which would have to be appended to the numbers if we are to remove the letters so that people will know which number on the screen is which.
The signs and letters in HUD don't read as a math equation, they read as a string. "-10degrees20minutes30second Western Hemisphere Longitude -30degrees20minutes10seconds South of the Equator Latitude.
There has been no other proposal stated thus far, and what we have has always worked for all users ( save two people ) from the inception of FlightGear.
As one poster has said that there may be no standard, and that no poster has posited a suggested better method, I believe that what we have is correct and need no change.
--Ray
@ray: this is too simple for all this c4rp arguing... it is simple math... east of zulu is positive... west of zulu is negative... a negative of a negative is a positive, period... negative drek west is positive drek east... period... your argument doesn't stand in the face of plain simple math...
challenge: find us one aircraft in RL that shows west and/or south coordinates as -fooW or -barS... i'll bet you cannot and i'm not being ugly or obnoxious about this...
Should be fixed by
https://sourceforge.net/p/flightgear/flightgear/ci/092707e78b083ef361b9e4379d489734bbfb622d/
Thanks Torsten!
This is an unfortunate situation for flightgear hud.
Point one -- this has never been an issue in the entire history of
flightgear.
Point two -- there has been recent discussion in the forum about this and
it is evident that the one side is confusing a string of characters for a
math statement.
Point three -- This is not a math statement.This is known in language as a
parenthetical form. This is a normal form of speech and even mathematics
though I admit there shall be people that are not familiar with such forms.
Point four -- The parenthetical form is a combination of the historical
Trinity House Navigation standard used thru-out the world, and the GPS
standard also used throughout the world.
The Trinity House Navigation standard uses the letter with the number.
This has the two fold advantage of differentiating between Lat and Lon as
well as standing in for the direction from Equator or Meridian.
The GPS standard uses the sign. But not just the sign. One has to
differentiate between Latitude and Longitude with a number and sign when no
other designation is used.
That is: if we had only provided a sign we would also have to provide the
words or abbreviations LAT and LON. Possibly we could instead provide an
educational note somewhere that the LAT was on one side of the screen and
the LON on another which is basically the same thing but with much more
fact finding involved.
In the parenthetical form we currently use we do many things without error.
We include the GPS standard sign and use the letter to designate Lat or Lon
as a side effect of having used that letter.
We also provide the Trinity House form because we use the letter.
This has the added benefit of providing both formats without confusion to
two systems of simulation. One is the GPS format required for Initial
positions/starting in air which requires the Decimal Degrees with a sign.
The other system is parking/groundnets which require just the letter in
place of the sign at the front of a format of Degrees Decimal Minutes.
The HUD in it's original format saved this confusion by providing both sign
and letter in a parenthetical form, not to be confused with a math
statement.
For those not familiar with parenthetical forms we can use the example from
accounting where this number 10.33 is positive and this number <10.33> is
negative. Notice that the greater than and less than have a similar
appearance to parenthesis, hence the name.
So even in a mathematics practice there is precedence for the parenthetical
form. One does not see the parenthetical form as a double negative.
Someone mentioned in forum that double negatives in language used in a
sentence is not assumed to mean positive. "I ain't listening to no more"
does not mean "I'm listening to more" we all know this.
So I think it's important to say that what we are reading in the HUD is not
a math statement, but instead a necessary, intuitive, clever, combination
of GPS and Trinity House standards that go a long way to relieving
confusion of gathering information for initial/in air starts and the laying
of parking in groundnets.
Change it and you have to change what everyone using flightgear is used to
for as long was we have had a HUD in flightgear.
Change it,. and be sure to document the change and why.
Change it, and may as well also change the Initial Positions/ start in air
format to be consistent with the new HUD change and how Parking works.
Change it, and may as well abandon the GPS standard.
Change it without discussion and time to build consensus is just being
disrespectful to the community and claiming one knows what the community
wants without evidence.
--Ray
On Mon, Jul 13, 2015 at 8:31 AM, Gilberto Agostinho gilbertohasnofb@users.sf.net wrote:
--
Raymond St. Marie ii,
public E-mail Ray.stmarie@gmail.com
Related
Tickets:
#1778Getting ready for bed and I had another option to consider.
I think the fix should go a bit further than where it currently is at.
Since the HUD options are already a menu option, why not include radio
buttons for
Trinity House standard ( Letter no sign )
GPS standard ( signs no letter but need to differentiate ( possibly )
between LAT and LON)
BOTH what the simulator HUD looked like in the last and every previous
version of flightGear that included a HUD.
This would make everyone happy even if they were not aware of these
conversations.
--Ray
On Mon, Jul 13, 2015 at 9:51 PM, Raymond A. St. Marie rastm2@users.sf.net
wrote:
--
Raymond St. Marie ii,
public E-mail Ray.stmarie@gmail.com
Related
Tickets:
#1778I read through the entire discussion and I am convinced that the previous implementation was buggy.
KSFO is at -122.3deg or 122.3W but not at -122.3W
As this is a core feature (implemented in c++ core), this should be discussed at the mailing list if needed.
Hi Torsten, thanks for you input in this matter.
I would like to make a suggestion.
I would like to handle this at the Menu level and provide more options of
Latitude and Longitude display.
Our fine simulator uses two formats of Latitude and Longitude in two
important areas, Initial Positions ( including starting in air, and another
in Groundnet parking.
In initial positions/start in air we use the GPS standard of signed Decimal
Degrees.
In parking defined in groundnets we use Trinity House Navigation standard
where a letter takes the place of the sign and the format is Degrees
Decimal minutes. This is the older standard used by all navigation systems
other than GPS, except that we normally see the representation to include
Degrees/Minutes/Seconds.
If the change recently made were returned to represent the GPS standard
properly, that is, return the sign format to what it was before today, then
at the MENU level we could ( I could even ) add radio buttons to the HUD
OPTIONS dialog to include:
GPS standard of signs and no letters, most likely appended by LAT and LON
to tell the difference
Trinity House Navigation Standard of positive numbers followed by the N or
S for Lats, and the E or W for Lons.
Another radio button to include the previous display of these two formats
together just as it appeared in the simulator since the HUD was invented.
Some of us, and those that I've had opportunity to discuss this with in
other channels don't see this as a bug but as a parenthetical form of the
the super-imposition of both standards on top of each other.
Handling this at the menu level gives greater opportunity to provide each
user with their choice without forcing any choice on to anyone.
I assume this would require that the change currently made to be reversed
so that the signs are not omitted and can be filtered by the choice one
makes in the additions I propose to the HUD OPTIONS dialog.
--Your thoughts?
Thanks, Ray
On Tue, Jul 14, 2015 at 12:42 AM, Torsten Dreyer <torstendreyer@users.sf.net
--
Raymond St. Marie ii,
public E-mail Ray.stmarie@gmail.com
Related
Tickets:
#1778The issue reported here was: wrong display of a position.
That report was correct as KSFO was displayed as -122W which is plain wrong.
Correct values would be -122 or 122W. I picked the latter and the issue is now closed.
If you think this fix is inappropriate, please discuss this at the mailing list.
If you want to make the display configurable, merge requests are welcome.
Changing the status back to new, as the fix was incorrect.
This has been fixed with https://sourceforge.net/p/flightgear/flightgear/ci/c889198d09c1e12ca3a970c854850c294b3403c4/ and https://sourceforge.net/p/flightgear/fgdata/ci/c6da4a2b65b1caf9ba61d6090fb4e74eff8a3555/.