2010
HTML 5 Geolocation Functions and Mobile Web Browsers: Show the User Where They Are (Sort Of)
Android , JavaScript , Miscellaneous , Web development Add commentsEvery April, the University of Maryland holds a huge open-house event called Maryland Day that draws 60,000+ visitors to the campus to view exhibits highlighting the research conducted at the university and participate in various events and activities. All of the event details are entered into a ColdFusion application, and one of those details is the GPS coordinates (latitude and longitude) of where each event is taking place so visitors to the website can see where the events are located on Google Maps.
Now that smartphones are becoming more prevalent, I wanted to see if it was possible to build a web application that would show the user where they were currently located and then show them on a map how to get from their current location to a particular event.
So I did some research and learned that HTML 5 comes with a Geolocation API. This API allows you to execute Javascript functions within the navigator.geolocation object built into the browser that retrieve the supposed latitude and longitude coordinates of where the browser is located (and, if available, the altitude, heading, and speed at which the browser is moving).
Using the code examples I found on the Gelocation API page on the W3C website and on Oliver Wehren's geolocation demo page, I was able to create my own test page for determining my location and marking it on Google Maps. I then tried using the page with my Motorola Droid, my iPod Touch, and my manager's iPhone.
The default web browsers on all three devices implemented the Geolocation API (my preferred browser on my Droid, the Dolphin Browser, did not). Each of the browsers displayed a confirmation dialog asking for permission to share my location information with the web page (as mandated by the standard), and once I permitted the information to be used, my test page was able to place a marker denoting my location on the map.
However, the location wasn't as accurate as I had hoped. Although the API was coded to accept location data from the on-board GPS system in a mobile device, neither the iPhone nor the Droid seem to provide GPS data to the browser. If I was connected to the campus wireless network, my location was determined via the network topography, and it could be off by as much as 150 feet or so. The accuracy was even worse if I was relying solely on 3G: in that scenario, but the iPhone and the Droid had me located on the side of a state road on the outskirts of campus, a good twenty minute walk from where I actually was. I have no idea what caused both devices to pick that particular spot, as there certainly wasn't a cell tower anywhere near that location.
So I came to the conclusion that while the Geolocation API could be used to determine what town, city, or general area a user was currently in, it wasn't accurate enough (at least with these browsers in these devices) to provide walking or driving directions within a small area, especially given the fact that many of the users for the service I had in mind would only have access to the Internet via a 3G connection.
But if someone knows of a way of increasing the location accuracy of the Geolocation API, a way that doesn't require the end-user to modify their mobile browser in order to make it work, I'd love to hear about it.
Jan 31, 2010 at 3:36 AM I believe you experience with the two browsers showing you as a 20 minute walk from your actual location is based upon the 3G triangulation technique. It is relatively inaccurate, but pretty common with 3G "GPS".
Feb 1, 2010 at 7:52 AM @TJ: Agreed. I just expected it to be a bit more accurate than that, given the number of cell towers in the area.
Feb 25, 2010 at 2:05 PM My compliments on the article Brian. You seemed to have hit the nail on the head. I've been experimenting with geolocation functions myself, and the results are far less accurate than I had expected. I naively thought Safari for the iPhone would be using the same technology as the native Google Maps application, but they seem to be worlds apart in reality.
watchPosition() seems to give better results than the one-off getPosition() method, but still nothing like I hoped for. It's good that the functionality has been spec'd out so well by the W3C though. I think we can expect things to improve much quicker with everybody singing from the same hymn sheet.
May 6, 2010 at 11:26 AM Fantastic article :)
Was there any feedback from the visitors on the app you built?
Was there a particular brand / model of phone that consistently outperformed the others or were there any that just completely failed to play nicely at all? How did you handle graceful degradation?
I've got to build something similar for an event my company are holding next month, and there seems to be very little data around on HTML 5 support for mobile devices at the moment!
Neal
May 6, 2010 at 3:19 PM @Neal: I left the geolocation-powered map out of the mobile web app because it wasn't accurate enough, so I don't have any real-world data I can share with you and I never got as far as figuring out how to handle graceful degradation.
I think you can safely assume that any mobile device with a WebKit-based web browser (iPhone, iPod, Android phones) will be able to use the geolocation aspect of HTML5. Not sure if the mobile version of Opera handles it.
May 19, 2010 at 8:57 AM @Brian,
Thanks for your reply :)
Here's a quick update as to how I'm thinking of implementing this myself.
if the browser has HTML5 geolocation support, go with the flow.
if not, try using google gears geolocation (as it appears a lot of mobile browsers without HTML5 geolocation have google gears installed by default - it seems blackberry is one of these)
otherwise display a normal google map of the location
and if all else fails, display a photo and the address.
Luckily the event we're running is aimed at people at the forefront of technology so I can relatively safely assume at least 90% of my users will be catered for in the first two instances.
I'll just have to hope the phones can provide a good degree of accuracy in London
Neal.
Jun 27, 2010 at 4:40 PM I have made some tests myself, and believe that the accuracy can be increased quite a lot by using watchPosition instead of getCurrentPosition. My testing has been done on an iPhone 3GS (first using iPhone OS 3 and later iOS 4).
getCurrentPosition seems to return a position as quickly as possible, regardless of accuracy. I mostly have an accuracy of about 500 meters using this.
watchPosition checks for your location continuously and starts by giving a low accuracy position just like getCurrentPosition, but after about a second or so it delivers a more accurate position (with about 80 meters accuracy).
I believe the GPS radios need a little time to find an accurate position. This is also consistent with the native Maps application. When finding your position, it starts with quite a big circle which gets smaller as the accuracy improves.
I'd say: Use watchPosition if accuracy below a kilometer or so matters. Just make sure to turn it of when it's no longer needed, so you don't drain the user batteries.
Apr 14, 2011 at 3:04 PM Just a quick check. Were you inside? That can throw GPS accuracy off that far, easily, because of the degraded signal strength.
Also, try forcing high accuracy.