Next-gen geolocation use cases

[tomayac]

For details, please see some use cases over on Discourse in order to avoid cross-posting them here again.

(Background: @marcoscaceres asked in a comment on w3c/ServiceWorker#745 to add use cases on Discourse, and @kenchris asked me to open an issue here. Happy to consolidate the discussions, just let me know where.)

[marcoscaceres]

We can do it here... but I'm worried about scope... does this project want to define both the Geo Sensor and the Geofencing behavior?

It might be interesting to discuss both, but personally I'm worried about overstepping. From Mozilla's perspective, at least, we don't want to tie together the Geo Sensor API with geo fencing, as we feel that we should (hopefully) be able to use Geolocation V1's primitives, in addition to Service Workers, to address the use cases.... that might turn out to be wrong, but it should be the starting default position.

[anssiko]

@marcoscaceres, thanks for your feedback. We are currently in the use case and requirements gathering phase with regard to anything background geolocation and appreciate @tomayac's input. We are not thinking about solutions yet (API shape and the like), and are well aware of the history and do not want to repeat the past mistakes.

The generic mechanism to expose sensors to workers has been discussed in the context of the Generic Sensor API and has been deferred to Level 2 due to a number of open questions that are still unanswered.

Please make sure your related feedback is provided for the new DAS WG Charter, either through DAS WG Charter GitHub issues or during the AC review (expected to start soon). As you know, Geolocation Sensor is in process of graduating from WICG to DAS WG, and we want to make sure Mozilla's feedback is considered.

Regarding scope. After expected graduation the scope will be governed by the WG Charter. Given background sensors is a Level 2 feature for the Generic Sensor API and Geolocation Sensor extends the Generic Sensor API, background geolocation would be in the new WG scope. Then again, no specific solution is enforced by the new Charter. However, since the DAS WG is chartered with privacy and security as a top priority and has related experts actively participating and reviewing the work, the group would only specify features implementers are comfortable with and that pass privacy and security scrutiny. Even as a practical matter, specifying something that has no implementer support would not be a good use of participants' time. To summarize, the WG could work on such a feature, but it does not have to.

That rather elaborate response hopefully clarifies why we're still in the use case and requirements gathering phase regarding anything background geolocation and not heads down specifying a solution and implementing it.

[marcoscaceres]

This is all really comforting to hear! Looking forward to reviewing and expanding on the use cases.

[tomayac]

+1 to what @marcoscaceres wrote, subscribed myself to the DAP Charter repo. Thanks for the elaborate reply, @anssiko! I'm really interested in helping shape this.

[tomayac]

There's some activity on the closed w3c/ServiceWorker#745, should we direct people to here, or what's the plan of action, if any, to reactivate the discussion? Please advise.

[tomayac]

@jonnyscholes has left some interesting cultural use cases over on Discourse. The data fully backs the museum one: cultural institutions should not have to build native apps, especially as their time of life commonly is restricted to the actual visit.

[anssiko]

Use Case: Geolocating sports event competitors in real-time https://github.com/w3c/system-wake-lock/issues/10 from @fadarnell

[marcoscaceres]

Should we move it from that repo to this one?

[anssiko]

Yes, transferred.

[orpic]

Adding my use case -

In a taxi aggregator app, the driver side requires a background location update

when a taxi is booked the customer is updated with the real-time location of the arriving driver, to do so we need the location of the driver but at that very moment the focus of the driver app ( PWA ) is lost because they use google maps to go the pickup location of the customer, and hence during this short period of time the background location fetch ( geolocation.getCurrentPosition ) and update become crucial for the apps functionality and customer experience.

[orpic]

Adding my use case -

In a taxi aggregator app, the driver side requires a background location update

when a taxi is booked the customer is updated with the real-time location of the arriving driver, to do so we need the location of the driver but at that very moment the focus of the driver app ( PWA ) is lost because they use google maps to go the pickup location of the customer, and hence during this short period of time the background location fetch ( geolocation.getCurrentPosition ) and update become crucial for the apps functionality and customer experience.

I guess this is already there - https://w3c.github.io/geolocation-sensor/#use-case-ride-share-applications

[anssiko]

At TPAC, the group agreed to focus on background geolocation for this spec and not duplicate foreground geolocation functionality per https://www.w3.org/2024/09/24-dap-minutes.html#t22

Closing this in favour of #22 where use cases for background geolocation are discussed.