Looking at the API

[keith preston]

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.

Keith Preston