Something does look funny.  The altitude reported is wrong, but in my case it'd
be wrong if taken as either meters or feet so I don't think it's as simple as a
units mixup and may not be a documentation bug at all.

Maemo mapper running on an N810 with the built-in GPS shows altitude ~50-55m
(which agrees with Ordinance Survey maps for this location).

Running the location-test-gui app with either AGNSS or GNSS method on an N900
shows correct longitude/latitude but altitude values between 90-105.

Sample syslog output:

Nov 22 12:13:34 Nokia-N900-42-11 [1043]: GLIB DEBUG default - location-sb:
enter
ing parse_uncertainty_changed
Nov 22 12:13:34 Nokia-N900-42-11 [1043]: GLIB DEBUG default - location-sb:
updat
e_plugin: ld_status: 3, ld_accuracy: 3, bt_status: 0, bt_accuracy: 0,
old_status
: 3
Nov 22 12:13:34 Nokia-N900-42-11 [1043]: GLIB DEBUG default - location-sb: got
f
ixstatus 3
Nov 22 12:13:34 Nokia-N900-42-11 location-test-gui[6022]: GLIB DEBUG default -
D
evice moved 0.894404 meters
Nov 22 12:13:34 Nokia-N900-42-11 location-test-gui[6022]: GLIB DEBUG default -
l
at = XXXXX, long = XXXXX; 
Nov 22 12:13:34 Nokia-N900-42-11 location-test-gui[6022]: GLIB DEBUG default -
t
ime = 1258892014.000000; 
Nov 22 12:13:34 Nokia-N900-42-11 location-test-gui[6022]: GLIB DEBUG default -
a
lt = 94.000000; 
Nov 22 12:13:34 Nokia-N900-42-11 location-test-gui[6022]: GLIB DEBUG default -
s
peed = 1.836000; 
Nov 22 12:13:34 Nokia-N900-42-11 location-test-gui[6022]: GLIB DEBUG default -
t
rack = 307.650000; 
Nov 22 12:13:34 Nokia-N900-42-11 location-test-gui[6022]: GLIB DEBUG default -
c
limb = -0.600000; 
Nov 22 12:13:34 Nokia-N900-42-11 location-test-gui[6022]: GLIB DEBUG default -
e
pt = 0.000000e+00, eph = 2.111000e+03, epv = 3.600000e+01, epd = 1.770300e+04,
e
ps = 1.230000e+02, epc = 1.970000e+02 
Nov 22 12:13:34 Nokia-N900-42-11 location-test-gui[6022]: GLIB DEBUG default -
S
atellites in view: 15, in use: 7

Comment 2 Andre Klapper 2009-11-27 13:32:21 UTC

Internal comment:

"The unit for altitude is metres, but it seems that altitude is reported above
the WGS84 ellipsoid instead of the more precise reference geoid.
The difference between geoid and ellipsoid can be seen from here:
http://en.wikipedia.org/wiki/File:Geoid_height_red_blue.png
and is for example in Helsinki/Ruoholahti 35m, which would mean that reported
altitude is 35m too high (in Ruoholahti). Depending on where Lucas was using
his device, this could explain why he was getting too high altitude values.
I guess we have to internally decide whether we can just switch to using
altitude above reference geoid.
Units for uncertainty fields have been documented for a while in liblocation
headers, but I don't know how that webpage is updated."

(In reply to comment #2)

Very useful info, thanks.  Comment 1 was in Greater London, UK so the
geoid/ellipsoid difference explains the altitude discrepancy (I can't tell the
exact difference from the image but it looks in the right ballpark).

> I guess we have to internally decide whether we can just switch to using
> altitude above reference geoid.

That would be great, yes - apparently the N810 does this.

(In reply to comment #2)
> Units for uncertainty fields have been documented for a while in liblocation
> headers, but I don't know how that webpage is updated."

Actually, this doesn't seem to be true:

/**
 * LocationGPSDeviceFix:
 * @mode: The mode of the fix.
 * @fields: A bitfield representing what fields contain valid data.
 * @time: The timestamp of the update.
 * @ept: Estimated time uncertainty.
 * @latitude: Fix latitude.
 * @longitude: Fix longitude.
 * @eph: Horizontal position uncertainty.
 * @altitude: Fix altitude (in meters).
 * @epv: Vertical position uncertainty.
 * @track: The current direction of motion (in degrees between 0 and 359).
 * @epd: Track uncertainty.
 * @speed: Current speed (in km/h).
 * @eps: Speed uncertainty.
 * @climb: Current rate of climb (in m/s).
 * @epc: Climb uncertainty.
 *
 * The details of the fix.
 */

(liblocation-dev 0.99-1+0m5)

And here is the documentation from our internal packages. It would be nice if
this also went into the SDK:

/**
 * LocationGPSDeviceFix:
 * @mode: The mode of the fix.
 * @fields: A bitfield representing what fields contain valid data.
 * @time: The timestamp of the update.
 * @ept: Estimated time uncertainty.
 * @latitude: Fix latitude (degrees).
 * @longitude: Fix longitude (degrees).
 * @eph: Horizontal position uncertainty (cm).
 * @altitude: Fix altitude (m).
 * @epv: Vertical position (altitude) uncertainty (m).
 * @track: The current direction of motion (in degrees between 0 and 359).
 * @epd: Track uncertainty (degrees).
 * @speed: Current speed (km/h).
 * @eps: Speed uncertainty (km/h).
 * @climb: Current rate of climb (m/s).
 * @epc: Climb uncertainty (m/s).
 *
 * The details of the fix.
 */

Copying Andre's lost update:

------- Comment #6 from aklapper@openismus.com  2010-01-08 17:10 GMT+3 -------
This will be fixed in location-daemon 0.97-1.
Altitude is now measured above reference geoid.

Comment 7 Andre Klapper 2010-01-13 18:34:55 UTC

This has been fixed in package
location-daemon 0.97-1+0m5
which is part of the internal build version
2010.02-2
(Note: 2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

Comment 8 Andre Klapper 2010-01-13 18:35:17 UTC

Ahem, to clarify:
"Altitude is now measured above reference geoid."

Comment 9 Andre Klapper 2010-02-17 21:26:10 UTC

Tested internally again. Result:
"The altitude was verified at various locations and found to be reasonable."

Comment 10 Andre Klapper 2010-03-15 21:10:44 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).