> > 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 _______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
