Bug 19586

Summary:	Location: reinstate vertical-accuracy, climb?
Product:	Telepathy	Reporter:	Simon McVittie <smcv>
Component:	tp-spec	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED MOVED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	enhancement
Priority:	lowest
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:	semi-wontfix
i915 platform:		i915 features:

Description Simon McVittie 2009-01-15 08:25:31 UTC

The Location spec currently defines some extra keys "climb" (rate of change of altitude in metres per second), "vertical-error-m" (some indication of vertical error in metres), "horizontal-error-m" (some indication of horizontal error in metres). These are struct fields in Geoclue, but there's no reason they couldn't go in the list of well-known keys in XEP-0080; someone should contact psa about this.

The names "*-error-m" are ugly, but are currently there to be unambiguous. If we could get the XEP changed to have "horizontal-error" and "vertical-error" which are definitely in metres, we could lose the "-m" suffix and be happier.

The XEP does contain "error" which is horizontal error in arc-minutes (1/60 degree). Does anyone care about arc-minutes, and can we perhaps get this deprecated or removed or something? It seems like a win to indicate error in a real unit (metres) rather than something whose size varies as you move around the Earth!

We define an "accuracy-level" key in the same namespace: maybe we could ask psa to avoid that name in the XEP, or maybe we could even put it in the XEP as an enumerated thing, with values 'country'/'region'/'locality'/'postal-code'/'street'/'detailed'.

Comment 1 Simon McVittie 2009-07-27 06:44:54 UTC

Stealing this bug back from pierlux, who says he has no time to work on it.

(In reply to comment #0)
> The Location spec currently defines some extra keys "climb" (rate of change of
> altitude in metres per second), "vertical-error-m" (some indication of vertical
> error in metres), "horizontal-error-m" (some indication of horizontal error in
> metres). These are struct fields in Geoclue, but there's no reason they
> couldn't go in the list of well-known keys in XEP-0080; someone should contact
> psa about this.

horizontal-error-m should now be renamed to accuracy as per XEP-0080 v1.6.

vertical-error-m does not exist in the XEP, but we could now call it vertical-accuracy without too much fear of conflict. Perhaps we could get that key into the XEP? It's our binding for Geoclue's geoclue_accuracy_get_detailed @vertical_accuracy. Alternatively, we could just leave it out for the moment.

climb does not exist in the XEP; similar situation. It's our binding for Geoclue's GEOCLUE_VELOCITY_FIELDS_CLIMB. Alternatively, we could just leave it out for the moment.

> We define an "accuracy-level" key in the same namespace: maybe we could ask psa
> to avoid that name in the XEP, or maybe we could even put it in the XEP as an
> enumerated thing, with values
> 'country'/'region'/'locality'/'postal-code'/'street'/'detailed'.

This is related to Bug #19585. We could leave this out for now, too.

Comment 2 Simon McVittie 2009-11-04 09:39:47 UTC

If anyone cares about Location On A Plane, they can fix this themselves :-)

Comment 3 Danielle Madeley 2009-11-04 14:15:00 UTC

Related to this, I was considering whether we could extend the XEP to include timezone (e.g. Australia/Melbourne). It would allow us to display a user's current time in Empathy (which seems like it would be pretty neat).

Comment 4 GitLab Migration User 2019-12-03 20:17:46 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/18.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.