-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
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: http://en.wikipedia.org/wiki/Dilution_of_precision_%28GPS%29. Quick 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 Laurens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.8) iEYEARECAAYFAkqfqegACgkQT5v5zGkvKT74qgCfY2ok9rcFkhpoRU4+f6DIOGot 1t4AoL1n9rb9OUxOwMTuojaiBMlWLG35 =lEq+ -----END PGP SIGNATURE----- _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
