Closed Bug 1333985 (mgga) Opened 7 years ago Closed 5 years ago

[Meta] Revamp Geolocation

Categories

(Core :: DOM: Geolocation, defect)

defect
Not set
normal

Tracking

()

RESOLVED INACTIVE

People

(Reporter: mds, Unassigned)

References

(Depends on 2 open bugs)

Details

(Keywords: meta)

      No description provided.
Alias: mgga
Depends on: 1072859
Depends on: 1269531
Depends on: 784505
Depends on: 1254911
Depends on: 1313242
Depends on: 645325
Depends on: 1335291
Depends on: 1341897
Depends on: 1341928
Depends on: 1344903
Depends on: 1344930
Depends on: 1346172
Please see https://drive.google.com/open?id=0B7Rmd3Rn8_hDMmFqWjlHUG5OQzQ for what is arguably the way forward with Geolocation and Web Apps. There is a aaa_readme.txt.
Sorry that was the wrong link. Here's the correct one: - https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU
Please be advised that I have added the Trip Summary page and you can now map and replay your trip on Google Maps.

The new version of the code is at the same link  https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU 

Most important design/proposed-specification change is that TravelManager subscription should now be Client specific. The TravelEvent must contain the intended Client.id (TravelEvent.source.id). This means that the UA must monitor and filter GeoLocation updates per client. I have also added new demo functionality such as a Trip Summary that is displayed when you press the "Arrive" button. The trip can also be replayed onto Google Maps by pressing "Map Trip" or "Replay". If the last and next geolocation updates for the trip are both visible in the Map window then smooth Marker movement is achieved via CSS transitions.

*PLEASE* help Background GeoLocation get up and help Web Apps compete with Native Apps! 

If there is something wrong with my TravelManager solution design then let me know. Tear holes in it!
Why would you allow the new duplicitous API for GeoLocation to sneak into the sensor API :-(

When would one opt to use the Sensor GeoLocation 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?

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?

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


---------- Forwarded message ----------
From: Richard Maher <maherrj@googlemail.com>
Date: Sun, Oct 1, 2017 at 12:23 PM
Subject: Re: Anssi Kostiainen appointed chair of the Device and Sensors Working Group; Frederick Hirsch steps down
To: "DAP (public-device-apis@w3.org)" <public-device-apis@w3.org>


Hi Anssi,
 
Congratulations on your appointment.
 
Please allow me to take the opportunity to reason with you to de-scope the redundant and duplicitous GeolocationSensor from this group and from the specification https://www.w3.org/TR/generic-sensor/
 
There has been no added value specified here that could justify the confusion of a pluralistic Geolocation API. In fact the sensor specification will surface only a subset of the GeoLocation functionality specified here https://dev.w3.org/geo/api/spec-source.html and implemented universally.
 
While Ultimate Web App developers crave useful additional features, such as background geolocation, precious time and resources are being squandered on this vanity for no obvious nor compelling reason.
 
Cheers
Richard Maher
 
 
From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Fri, 29 Sep 2017 13:18:53 +0000
To: Dominique Hazael-Massieux <dom@w3.org>
CC: W3C Device APIs WG <public-device-apis@w3.org>
 
Hi All,
 
I'm very pleased to join Dom in thanking Frederick for the leadership he has provided to this group since its inception. Under Frederick's watch the group has transformed itself couple of times and made tangible impact to the web platform.
 
I'm thrilled to take over chairing from Frederick who has been taking good care of the group to allow me to start my tenure from a position of strength. The group is currently specifying a very exciting set of technologies and we see these specifications materialize as implementations faster than ever in the history of this group.
 
I look forward to expanding the group's participation and further broadening the adoption of technologies developed by this amazing group of enthusiastic professionals.
 
Thanks,
 
-Anssi (Device and Sensors WG Chair)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.