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