HTML5 Geolocation: When, Why, How

As the web moves from interactivity to physical integration, mobile web use explodes all over the world, and the line between virtual and 'real' grows thin -- knowing your user's physical location becomes increasingly important. Location matters to physical people; therefore it will soon matter to web app users as well.

So geographic location will soon leave the land of specialized apps (like Foursquare) and become essential to web apps in general. This, of course, is why the W3C decided to write a specification for geolocation.

But when should you use geolocation? 

Danwel Tran Luciana explains in new developer's guide, offering a slew of use-cases including:

• Public transit sites (for nearby stops/stations)
• Shopping sites (for nearby stores/stock)
• Online games (for linking game assignments to the physical world)

Danwel also explains some of the API details (functions; the position object; different kinds of location data).

But for a more thorough, code-centric take on the How of geolocation, try Ian Devlin's article on html5doctor (which includes, for example, fuller explanations of the getCurrentPosition and watchPosition functions).

Turns out the technical aspect of the API is very straightforward; so the more interesting problem is the When. Danwel's use-cases all makesense, but they don't break any new ground -- except maybe the reality-bending online gaming.

Foursquare was a killer location-specific app -- unsurprisingly, because it was social, another dimension along which the real-virtual distinction is blurring. I had a few ideas for geolocation use-cases, and would appreciate your feedback:

• Historical travel guides with augmented reality: the app would display models (or wireframes, or blueprints, or whatever) that once stood where the user is currently located, drawing on GPS via the geolocation API and also device accelerometers via other (presumably also HTML5) APIs.
• Architectural surveying tools: the app would match geolocation-derived coordinates with weather and other environmental data, and combine this with data from the mobile device's camera to suggest ideal building locations, materials, etc.
• Flavor-localizing the UI: the app would pair the user's location with local aesthetic data (colors, materials, architectural features, population density, etc.) and adjust the UI to match. (I don't fully appreciate this one, but the idea comes from an artist friend of mine -- who absorbs every local aesthetic quite holistically, and is 'emotionally disequilibrated' by her device UI when it doesn't match.)

Of course, these apps would also need integration with good cloud APIs, both location-oriented and not location-oriented (on materials, for instance). But geolocation would figure essentially into all of these -- and with the HTML5 API gaining ground, and new cloud APIs popping up every week, perhaps in the very near future.