Moving Forward on Geolocation API

Taishan Conference Room, Wuzhou Guest House, Shenzhen
Presentation Material

IRC and Scribing

Scribe: Please volunteer!
How to Scribe: Please refer to the trusty scribe page.
IRC: Please sign into IRC channel: #geolocation.

Introduction

The Geolocation API has now achieved Recommendation status, and is a mature and widely support specification. Since work on this API first began in 2008, many new positioning technologies and location-based services have been commercialized that have moved beyond the functionality that the API could provide. As a result, the current API needs to evolve in order to give developers a viable alternative to native programming. In addition, the DeviceOrientation API has seen implementations with varying levels of consistency. This has also frustrated developers who would like to leverage HTML5 for advanced positioning applications. Therefore a re-chartering of this group is proposed.

Enhancements to Geolocation API

As a starting point, new additions to the Geolocation API that include support for geofencing and indoor positioning are proposed. Although geofencing is certainly feasible using the existing API, it has been shown that in handheld devices hardware-based implementations of geofencing are far more power-efficient. In addition, indoor positioning has become a reality - a device can be placed with increasing levels of accuracy inside a building by leveraging the building infrastructure (e.g. placement of WiFi Access Points).

DeviceOrientation

DeviceOrientation has found widespread user agent support. However, recent testing by Rich Tibbett of Opera has shown significant variability in implementation. Re-chartering the group will allow participating companies to revisit the specification to see if more consistency in implementations is possible.

Notes

Attendees: Lars-Erik Bolstad (Opera), Phil Archer (W3C), Yahui Wang (Huawei), Dominique Hazael-Masseiux (W3C), Giri Mandyam (Qualcomm Innovation Center), Ruinan Sun (Huawei)

1. Lars-Erik pointed out that use cases are necessary for indoor location and geofencing. The original geoloc. WG discussed indoor location in particular, but rejected it. The original WG also rejected reverse geocoding service, and some of the concerns during that time may apply to indoor location (e.g. venue identification). (EDIT: "Rejected" doesn't really reflect what was said in the meeting; Indoor location was never in the scope of Geo v1. Reverse geolocation was part of Geo v2, which was abandoned for different reasons).

2. Phil Archer pointed out that there are efforts that the W3C is spinning up around geospatial information (e.g. the upcoming provisionally-approved conference with Open Geospatial Consortium in March - Linking Geospatial Data) and the EU Inspire directive. He said that the industry is moving towards URI identifiers for venues.

3. Lars-Erik mentioned that reverse geocoding use cases were difficult for the group to determine. Dom mentioned that the scope of the API should be limited to information that cannot be obtained by other means. Reverse geocoding would be an example of information that can be obtained by other means. However, floor information when indoors would be an example of information that cannot be obtained in Javascript via means other than the API.

4. Lars-Erik added that was is exposed regarding indoor location does not need to be human-readable, as long as it's machine-readable. (EDIT: Lars Erik said that we need to decide whether the data passed through the Indoor location api needs to be machine-readable, human-readable, or both)