Re: [geolocation-sensor] questions about new interface

There has been discussion of some of these points on the GitHub issue
tracker <https://github.com/w3c/geolocation-sensor/issues>. Feel free to
comment there or file additional issues for your concerns.
[image: Google Logo]
Reilly Grant
Software Engineer
reillyg@google.com
Google Chrome


On Thu, Nov 1, 2018 at 1:19 PM Andy Gup <agup@esri.com> wrote:

> Hi,
>
>
>
> I’m excited to the see the new work and have a few questions after
> reviewing the Geolocation Sensor Editor’s Draft (17 Oct 2018). I work
> extensively with location-based mobile web apps for both commercial and
> consumer both in the U.S. and internationally.
>
>
>
> 1. There were a number of features in the original Geolocation API that
> were very useful and we don’t see them in the new spec, perhaps these
> haven’t been documented yet?
>
>
>
>    - Are there are any considerations to include options to retrieve the
>    location cache similar to maximumAge?
>    - And, how about a timeout option?
>
>
>
> 2. And, are there any considerations to provide functionality to allow the
> developer to select the geolocation ‘source’: for example, WiFi, Cellular
> or GPS?
>
>
>
>    - The largest issue our customers have encountered is having the
>    location bounce around as different geolocation sources concurrently
>    provide their own location. The typical workaround is to normalize the
>    locations by averaging the geometric center and rejecting locations with an
>    accuracy greater than what’s acceptable for the requirements. Many
>    customers have chosen to use hybrid implementations that take advantage of
>    native-to-javascript bridges that allow one to choose the geolocation
>    source, for example:
>    https://github.com/Esri/cordova-plugin-advanced-geolocation
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Esri_cordova-2Dplugin-2Dadvanced-2Dgeolocation&d=DwMGaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=KdbvNWrP5yTit1RT04E9oX76qjWmH4UNtRMQKXKngos&m=m2WPsALXh8LcVUqsKrA4M8txsIOil0z9PbOs51R-Wq4&s=PdozQ1eLbDmhbADw-oehdaTHMPTcBx_62CIvGF31LSo&e=>.
>
>
>
>
> 3. Specific documentation of HTTPS-only support. We are assuming this will
> continue to be a requirement?
>
>
>
> Any feedback would be appreciated?
>
>
>
> -Andy
>