W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2018

Re: [whatwg] Popular Background Geolocation question on StackOverflow

From: Roger Hågensen <rh_whatwg@skuldwyrm.no>
Date: Sat, 24 Mar 2018 22:12:26 +0100
To: whatwg@lists.whatwg.org
Message-ID: <67b60ece-59ba-e486-b163-5a85ac743d61@skuldwyrm.no>
On 2018-03-24 21:15, Philipp Serafin wrote:
> If this problem is specific to the "track a route" use-case, and the
> use-case is sufficiently widespread, would a dedicated "route recording"
> API make sense?
> 
> E.g., a web page could ask the browser to continously record location
> changes and - at some time at the browser's discretion - push a list of
> recorded changes to the page.

Hmm! It might.
certainly it makes sense to cache location coords since the device may 
not have a internet connection during the entire time.

In practice it would only need a internet connection at the time of data 
submission to the site of the webapp, the rest of the time it could be 
"offline".

> This would allow the browser to record locations changes with reasonably
> accuracy *without* waking up service workers.

THis part I'm unsure of. Should it be a webapp or a client feature with 
a API for webapps?

> It would also provide some hooks for privacy controls: A browser could show
> a status indicator whenever it's in "GPS recording" mode. It could also
> notify the user when it's about to push the recorded route to the page and
> possibly even show the route for confirmation.

I certainly see the charm and practicality in a webapp asking the client 
(browser) to start logging GPS coords (it must be user initiated at some 
point though, like a button/link click).
And then the same when stopping it.

A _start function and a _stop function and a _get function would be all 
that is needed.

The _stop function should be self explanatory. The _start function would 
allow a argument of milliseconds (or is seconds enough granularity?), 
which specifies the interval the client should use to record the current 
GPS and other info.

The _get function of such a API would just return a JSON array of GPS 
objects, with cords, height and timestamp of the reading, with future 
expandability for including stats like pressure and moisture and 
temperature (can't think of anything else).
For a cyclist/runner/driver/boater the coords might be useful (to get 
distance and route traveled). For a camper or woodsman or farmer or who 
knows what else the moisture and temperature and pressure and elevation 
may be valuable (the GPS coords would be almost identical for each 
reading though).

I'm not sure if this would fit under a geolocation API though, perhaps 
more under a environmental API (where GPS/elevation is just one of many 
data).

Since the user explicitly (or implicitly) press start there is no need 
to ask permission.
But there should be a possibility to ask for site permisssion and have 
the webapp autostart, this would allow to run the wwebapp in a browser 
24/7 and have it send "live" data to a server. This could make a 
smartphone a temporary weather station (a smartphone could have a 
external "weather sensor box" connected for example, providing the 
sensor input for this API, the browser would just see it as OS provided 
sensor data).

Sure a Raspberry Pi or some other IOT with some scripting can do this 
better, but just plopping a smart device to a large battery pack or 
mains power and leaving it over the night sending live data to a server 
could be useful. Hundreds if not thousands of these round the world 
could supplement weather research/sites with that data.


I'd suggest this as a way to detect if such a API is available
if ("environment" in navigator) {
   /* environment API is available */
} else {
   /* environment API IS NOT available */
}
It would really need to be it's own thing instead of adding to the 
geolocation, there should be no issues with both coexisting.


-- 
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.
Roger Hågensen,
Freelancer, Norway.
Received on Saturday, 24 March 2018 21:12:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:46 UTC