Looking at the API

[keith preston]

> > I still like the idea of services providing certain level of Human
> > readable strings.   Here we have ServiceName, but I think we could
> > also have ServiceDescription.   A longer version so that people can
> > understand how their computer knows where they are.
>
> I was thinking about the same thing this week. This might be handy for a
> Geoclue preferences UI (or just a client that wants to expose some
> details to user). Could be that it never gets used, but the cost of
> implementation is so low that I support this.
>
>

Agree cost is low, it's optional.


> [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.

Most places you can look up the general elevation from your lat/long
(error being based on where you are and relative elevations around it)

altimeter (often in watches)

>    b) useful for something

I was in taiwan last week.   A lot of there highways are stacked (one
direction on top, one direction on bottom)   it would be useful to
know which highway you were on by altitude.   (Error for this would
help to approximate)

Hiking.

geocaching in trees (ok that's a stretch)

Hmm..   I'm thinking a weather program that will predict the weather
near your computer when you hook up a barometer (this would also need
to know the altitude accurately)



> Do you have an example use case for this?
>
> >  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)
> >  .....
>
> Iain referred to a long discussion on accuracy: you just found it :)
>
> Iains point, if I remember it correctly, was that using just meters
> would lose information as the user may have additional context that the
> backend does not have: Imagine a user locating herself with an
> Address-based backend (say, hostip). She knows that
> "accuracy=CITY_LEVEL" means about 1km because she happens to be in a
> small town, not Mexico City...


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.

Keith Preston