forked from w3c/sensors
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathusecases.html
133 lines (99 loc) · 5.84 KB
/
usecases.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
<!DOCTYPE html>
<html lang='en'>
<head>
<meta charset='utf-8'>
<title>Sensor Use Cases</title>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' async class='remove'></script>
<script class='remove'>
var respecConfig = {
specStatus: "ED",
shortName: "tbd",
editors: [
{
name: "Tobie Langel",
company: "Intel Corporation",
companyURL: "http://intel.com/",
w3cid: 78102
}],
wg: "Device APIs Group",
wgURI: "http://www.w3.org/2009/dap/",
wgPublicList: "public-device-apis",
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/43696/status",
edDraftURI: "https://w3c.github.io/sensors/usecases.html",
format: "markdown",
noRecTrack: true,
noLegacyStyle: true,
otherLinks: [{
key: 'Repository',
data: [{
value: 'We are on Github.',
href: 'https://github.com/w3c/sensors'
}, {
value: 'Contributors',
href: 'https://github.com/w3c/sensors/graphs/contributors'
}, {
value: 'File a bug.',
href: 'https://github.com/w3c/sensors/issues'
}, {
value: 'Commit history.',
href: 'https://github.com/w3c/sensors/commits/gh-pages'
}, {
value: 'Mailing list.',
href: 'https://lists.w3.org/Archives/Public/public-device-apis/'
}]
}],
issueBase: "https://www.github.com/w3c/sensors/issues/",
githubAPI: "https://api.github.com/repos/w3c/sensors"
};
</script>
<style>
body {
max-width: 50em;
}
</style>
</head>
<body>
<section id=abstract>
This document lists use cases for sensor data exposed to the Open Web Platform along with code examples of how Web developers ("authors" in spec speech) would listen to sensor data and use it within their application-level code.
</section>
<section id=sotd>
</section>
Introduction
------------
Sensor data is increasingly used in Web application development, especially on mobile devices where new sensors are added regularly. Exposing those to the Web has so far been both slow-paced and ad-hoc. The goal of the Generic Sensor API is to promote consistency across sensor APIs and increase the pace at which they can be Web applications by simplifying both the specification and implementation processes.
There are plenty of different kinds of sensors cattering to plenty more use cases with various performance requirements. The purpose of this document is to describe the minimum number of use cases in order to build an exhaustive list of all requirements with which to inform the design of a Generic Sensor API.
<div class=note>
Some of the examples and use cases in this document rely on sensors that have already been specified by this or other Working Groups. While the editor feels these would be great candidates for building atop the Generic Sensor API, their inclusion in this document does not imply that the relevant Working Groups have given their agreement to do so or a planning to.
</div>
Use Cases
---------
### Displaying the position of the user on a map in real time
In this use case, the user's location is positioned on a map in real time using the device's default geolocation sensor. The users' position is represented on the map by a circle the size of which depends on the accuracy of the data provided by the geolocation sensor. When no signal is available, the circle is greyed-out.
An [example application is available online](https://w3c.github.io/sensors/examples/realtime-positioning/index.html) (best-viewed with a device equipped with a geolocation sensor). Its [source code](https://github.com/w3c/sensors/tree/gh-pages/examples/cached-data) can be found in the same repository as this document.
<!--
TODO Add screenshots
-->
Using the current Geolocation API [[geolocation-API]], the application code to tap into the sensor looks like this:
<pre title="Current Syntax" class="example highlight" data-include="./examples/realtime-positioning/index.js" data-include-sync=yup></pre>
Using the proposed Gerneric Sensor API, application level code would be modified like so:
<pre title="Proposed Syntax" class="example highlight" data-include="./examples/realtime-positioning/proposal.js" data-include-sync=yup></pre>
#### Further improvements
It is worth noting that the current syntax doesn't of the Geolocation API doesn't allow for a number of performance optimizations that require awareness of domain constraints and/or application-level code.
In our particular example application, the frequency at which the Geloocation API must be queried and its precision requirements vary greatly depending on the zoom factor of the map and the speed at which the user is driving.
The more zoomed out we are, the lower our accuracy and frequency requirments become.
The faster the user is moving (for example if they are driving a car), the higher the frequency requirements (as per the [Nyquist–Shannon sampling theorem](https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem)).
#### Requirements
### Relying on cached data in a battery- or CPU-contrained environment
### Head-tracking
### Turn by turn navigation
### Podometer
<div class=issue data-number=12></div>
### Promimity sensors
<section id=acknowledgements>
Acknowledgements
----------------
The following people have greatly contributed to this document through extensive discussions on GitHub: <span id=gh-commenters></span>.
We'd also like to thank <span id=gh-contributors></span> for their editorial input.
</section>
</body>
</html>