Looking at the API

[iain]

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?

>From your example below "getAccurracy(&hor, &ver, & alt)" I think you've
mistakenly thought we'd removed altitude accuracy.

> > >  Secondly,  I would have the interface give raw meters and then put
> > > convenience methods on both sides of the api for using these meta
> > > fuzzy enums.   The enums would define ranges in meters.
> > >
> > > getAccurracy(&hor, &ver, & alt)
> > > GEOCLUE_ACCURACY accuracy = meta_accuracy(hor, ver)
> > > if(accuracy == GEOCLUE_ACCURACY_LEVEL_COUNTRY)
> > >  .....
> >

> I think meters is the most informative.   I think you lose information
> in the case you said by passing the ENUM instead of meters.
> I think all the enums should be defined as ranges.   Servers can
> default to one of the enums and it gets the middle of the range in
> meters sent, or if it wants to be more accurate then it can give the
> error directly in meters. (which could even be an estimation).
> On the client side, you can either use meters, or the convenience
> function to go to the enum.
> I don't by the argument that the user will have more information with
> the ENUM, the point is that the program should have the best
> information, because all the smarts are programmed into it.
> 
> This gives the advantage of both the ENUM and Meters, and I think that
> the cost is low.

Giving accuracy in metres does give the best information, but sometimes
that information is simply not available. The example I gave Jussi when
we were discussing it is that if a backend reports that my house is in
Carrick and it reports that the co-ordinates of Carrick are 54,42'N
5,49'W. I then go to my parent's house and it says that I'm in Carrick,
the co-ordinates being 54,42'N 5,49'W. Now, my house is 1000m away from
those co-ordinates, my parents' house is 2500m away. The backend cannot
know what accuracy to report in metres, because all it knows is that the
two locations are somewhere inside the city of Carrick. What range of
values could GYPSY_ACCURACY_LEVEL_CITY have that would fit all cities?

The advantage of the enum is that it says "The best I can tell you is
that you're located inside the city" the user can then use their
knowledge of what it means to be "inside the city" whether the city is
3km across or 25km across.

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.

iain