Looking at the API
keithpre at gmail.com
Mon Nov 12 07:24:06 PST 2007
On Nov 10, 2007 7:13 PM, iain <iain at openedhand.com> 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.
More information about the GeoClue