W3C home > Mailing lists > Public > public-device-apis-log@w3.org > November 2017

[sensors] When to use the new GeolocationSensor API

From: MeritBased via GitHub <sysbot+gh@w3.org>
Date: Mon, 13 Nov 2017 01:06:21 +0000
To: public-device-apis-log@w3.org
Message-ID: <issues.opened-273283786-1510535180-sysbot+gh@w3.org>
MeritBased has just created a new issue for https://github.com/w3c/sensors:

== When to use the new GeolocationSensor API ==
When would one opt to use the Sensor [GeoLocation](https://www.w3.org/TR/generic-sensor/#background) API as opposed to the existing standard navigator.geolocation.watchPosition?

Can someone explain the added value of this second API or the use-cases that can be solved by the sensor API that cannot be handled [here?](https://dev.w3.org/geo/api/spec-source.html)

The Web App world desperately needs a background geolocation capability but the sensor API architecturally prohibits this.

What is the point of the following redundant interface to geolocation: -

let sensor = new GeolocationSensor({ accuracy: "high" });

sensor.onreading = function(event) {
    var coords = [sensor.latitude, sensor.longitude];
    updateMap(null, coords, sensor.accuracy);
};

sensor.onerror = function(error) {
    updateMap(error);
};
sensor.start();

If technical merit contributes to W3C/IETF resource allocation surely the battery efficient background geolocation solution proposed [here](https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU) is what should be promoted?

Just because the Sensor API is designed to be "Generic" does not make every future functionality requirement a Screw.

How about new ClockSensor({ granularity: "minute"}) ?

Please view or discuss this issue at https://github.com/w3c/sensors/issues/325 using your GitHub account
Received on Monday, 13 November 2017 01:06:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 November 2017 01:06:26 UTC