Notification that the requested accuracy is not available

[blairmacintyre]

(pulling out of #2)

Different applications with have different requirements for latency and accuracy of geolocation estimates. Something that wants neighborhood/city-scale can tolerate any reasonable error a modern platform will deliver. But, mapping and (my personal use-case) first-person AR views, need as high an accuracy as can be gotten. We tend to "muddle along" with the typical current GPS accuracy (3-10m, or so), but inside or in "urban canyons" the accuracy can really degrade.

When starting up, it is hard to tell if there is even going to be a potential for high accuracy (e.g., before GPS lock), and some platforms (e.g., desktop or other devices without a GPS) can never achieve GPS-level accuracy.

It would be good to be able to request to be notified if the level of accuracy desired cannot be achieved.

[anssiko]

Thanks for the concrete use case. It is reasonable, and we'll look into this more.

The challenge lies in upfront low accuracy notification implementability. The low bar is no hardware present or total loss of GPS or equivalent. That is easy to implement. But since the capabilities of hardware seem to vary quite a bit, it gets harder as we go from black and white to shader of gray.

Per the GPS Standard Positioning Service (SPS) Performance Standard modern GPS hardware can reach 4 meters rms accuracy, or 7.8 meters with 95% confidence intervals. Some yet to be released products claim much improved accuracy according to Wikipedia. That is, the capabilities of hardware seem to vary quite a bit, and upfront predicting accuracy in any more detail might prove to be challenging. Needs further investigation.

As for the solution in terms of the API, we could allow the developer to pass in an accuracy argument, and borrow some of the generic infrastructure in place to provide notifications at runtime asynchronously similarly to onerror. For example, we could fire a lowaccuracy event as soon as the implementation figures out it cannot satisfy the accuracy requirement (e.g. user is in or enters an urban canyon with poor GPS reception) to allow the application to adapt accordingly:

let requiredAccuracy = 5;
let geo = new GeolocationSensor({ accuracy: requiredAccuracy }); // accuracy arg not spec'd yet

// This event can fire as soon as start() is invoked before any reading events are fired
geo.lowaccuracy = () => showLowAccuracyWarning();

// We continue to receive readings and can evaluate when they satisfy the accuracy requirement
geo.onreading = () => {
  if (geo.accuracy >= requiredAccuracy) {
    doHighAccuracyThings();
  }
};

geo.start();

The default behavior would be to provide best effort accuracy aligned with the legacy Geolocation API. The developer would opt-in to the best effort service by not imposing any requirements at construction time:

let geo = new GeolocationSensor();
geo.onreading = () => console.log(`lat: ${geo.latitude}, long: ${geo.longitude}`);
geo.start();

(That is just one sketch of a possible API shape to illustrate.)

[tomayac]

Can this be merged into #25? The core of this seems to boil down to the questions discussed over there…

FWIW, the current legacy default behavior seems to favor low latency over high accuracy; personally I am fine with this, but I propose we discuss in #25.