On Nov 10, 2007 7:13 PM, iain <[EMAIL PROTECTED]> wrote: > > On Sat, 2007-11-10 at 18:30 -0600, keith preston wrote: > > > Agree cost is low, it's optional. > > I'm in agreement here as well. > > > > > > [On Accuracy-interface:] > > > > Hmmm.... I don't think this is bad, but here's how I would implement > > > > it. First of all you probably want 3d accuracy and not 2d accuracy. > > > > > > I just can't see three accuracy values (latitude_accuracy, > > > longitude_accuracy and vertical_accuracy) being > > > a) available from any data source > > > > GPS will give all of these. > > I admit I'm only looking at a reverse engineered NMEA spec, but I only > see horizontal and vertical accuracy, although the GSA sentence does > have a PDOP field as well (and I'm not actually sure what that means). > > We have 3D accuracy here, except latitudinal and longitudinal accuracy > have been combined in our "horizontal accuracy", and altitude accuracy > (which you mention below) is what we've called "vertical accuracy". Is > there any sources which split horizontal accuracy into latitudinal and > longitudinal accuracy?
Not that I know of. It only makes a difference if you are talking degrees as opposed to meters. This should be fine. > If a backend can provide accuracy in metres then it will and that is > what should be reported to the user, the enum fuzzy values are for when > a backend cannot give any meaningful estimate. So are we providing both? I have no problem with both, I thought we were just arguing over if it was better to include just one. Keith Preston _______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
