[Twisted-Python] twisted.positioning: storing the error information
Laurens Van Houtven
lvh at laurensvh.be
Thu Sep 3 07:36:25 EDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
First of all, sorry for the lack of promised gpsd support updates
yesterday, I was in bed with the flu (and still am, I guess -- it's
just slightly less bad than yesterday), so if I'm not making any
sense, blame me being delirious.
As you might know t.positioning currently has one object for storing a
bunch of errors, and the IPositioningReceiver interface describes one
method (positioningErrorReceived) for receiving such an error object.
Coming from NMEA (which only reports HDOP VDOP and PDOP), putting all
of it in one object made sense -- there is an obvious mathematical
relation between the three, so in case one is missing we can
calculate it, and that's exactly what t.p.base.PositioningError does.
For more information as to what all these xDOPs are, see:
introduction (skip this paragraph if you already know what xDOP
means): HDOP is the relative imprecision (expressed in the value times
the reference imprecision, which depends on the device) on latitude
and longitude. Suppose the device has a reference imprecision of 1
meter and the HDOP is 5, you know where you are (lat/lon wise) within
a five meter radius. Similarly, VDOP gives you an idea of your
altitude. Suppose the device normally provides altitude precisions up
to one meter, and the VDOP is 5, you know where you are altitude-wise
on a 5 meter line. PDOP is the euclidian norm of the (HDOP, VDOP)
vector, and as such is slightly less useful as something directly
translatable to an error measurement (it's the radius of a sphere...
sort of) but more of a relative measure of goodness-of-fix.
Anyway, the problem is this. Now that I'm implementing GPSD support,
I've noticed that it's perfectly sensible to have your positioning
source report all sorts of errors: climb error estimates, time error
estimates, position error estimates... (all of these measured in
meters, m/s, degrees/second... instead of relative values). This was
actually the original idea, and I think it was only dropped because it
was hard to do with NMEA. However, if there's anything I've learned
about NMEA it's that the less your public API looks like it probably
the better, so perhaps we should change how this works?
Maybe we could have a bunch of separate kinds of errors, and supply
them with that information. The NMEAAdapter, which does not provide
such error estimates yet (in most cases) could provide dummy error
reports with all relevant error attributes set to None. (This could be
elegantly done by simply seeding self._state).
Splitting all of this up isn't incredibly easy though. Obviously HDOP
(as well as XDOP/YDOP, which apparently will be reported separately in
NMEA3.0) is related to the position and VDOP is related to the
altitude. Where do you put PDOP, though?
Thanks in advance for your thoughts
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.8)
-----END PGP SIGNATURE-----
More information about the Twisted-Python