Clarify usage of API contracts surrounding GClueAccuracyLevel
Hello, a lot of frustration has been built up surrounding the API of geoclue and I would argue that this is mostly surrounding some confusion and vagueness of the API and the contract that one enters with the API (the confusion about device orientation vs direction of travel being a recent example).
I have a question that could be clarified through API documentation (perhaps).
The GClueAccuracyLevel is the accuracy level at which I request a location, and currently geoclue always seems to do a best-effort approach and return something in a org.freedesktop.GeoClue2.Location together a Accuracy property in meter. The Client has no clue if this is from a GPS, a WLAN or an Geo-IP resolution. So, application based filtering is a bit hard, because ultimately, I have no clue if that accuracy value has any meaning (what is the accuracy of a geo-ip resolution, and on mobile data I know it will be bad anyway).
The org.freedesktop.GeoClue2.Manager
has a "AvailableAccuracyLevel" property but that is on a manager level, and I have no clue if the location I have just received was a rough estimate because of a temporary GPS glitch, or an especially good one. Also, I have no idea if the "available" accuracy level is based on hardware presence, or reflects the accuracy of the current geo-resolution.
The situation is made worse if applications use geoclue indirectly, e.g. through the QT location service, because that loses some information and makes client-side filtering harder. One could argue this is the fault of QT, but with the API being a bit vague, one can blame QT only so much :-).
So, my questions (and perhaps request): is there a way to request location ONLY at the desired accuracy, forbidding fallbacks? Allowing fallbacks in a best-effort fashion make sense in some cases, but not e.g. while routing. Client-side filtering has been suggested, but
a) if I know I only want EXACT results, it does not make sense to perform geo-ip lookups just to filter them out post-fact
b) if I know I only want EXACT results, the platforms (e.g.) need to convey that information
c) if I know I only want EXACT results and am supposed to do client side filtering, the AvailableAccuracyLevel needs to be queryable per answer, and not only in general (based on hardware availability???)
d) if I know I only want EXACT results, speed based gate fallbacks will only make the situation harder to filter, as they will deliver some faked and flawed Accuracy values in meters.
So, perhaps the API needs to be clarified, an option to NOT provide location fallbacks to anything with worse precision could be added to a GetClient() call. And the corresponding level of accuracy (source of data) could be delivered together with a location response.
Sorry for the long diatribe, I hope this can help to make some of the frustration a bit clearer. It is very annoying to have your navigation application jump withing the whole country whenever it loses GPS reception, and the API is not clear enough in my opinion to resolve this with a simple "applications should just filter client-side".