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.
