Tuesday, August 26th, 2008

navigator.geolocation: Using the W3C Geolocation API today

Category: Gears, Google, JavaScript, Mapping, Standards

Last week I wrote a simple WhereAreYou? application that used the Google Ajax APIs ClientLocation API to access your location via your IP address.

At the same time, we announced support for the Gears Geolocation API that can calculate your address using a GPS device, WiFi info, cell tower ids, and IP address lookups.

Add to all of that, the W3C Geolocation API that Andrei Popescu of the Gears team is editing. You will notice that it looks similar to the Gears API, with subtle differences. The ClientLocation API is quite different.

To make life easier, I decided to put together a shim called GeoMeta that give you the W3C Geolocation API, and happens to use the other APIs under the hood.

If you have the Geolocation API native in your browser (no one does yet, future proof!) that will be used. If you have Gears, that API will be used, and finally, with nothing the ClientLocation API will be used behind the scenes.

To you the API will look similar:

// navigator.geolocation.getCurrentPosition(successCallback, errorCallback, options)
navigator.geolocation.getCurrentPosition(function(position) {
      var location = [position.address.city, position.address.region, position.address.country].join(', ');
      createMap(position.latitude, position.longitude, location);
}, function() {
      document.getElementById('cantfindyou').innerHTML = "Crap, I don't know. Good hiding!";

At least, that is what I would like. Unfortunately, there are a few little differences that leak through.

  • The W3C API only seems to give you a lat / long, so you have to do the geocoding to get address info
  • The Gears API gives you an additional gearsAddress object attached to the resulting position object. This can contain a lot of information on the resulting area (street address to city to …) however for certain providers the API returns that as null, the same as the W3C standard
  • That gearsAddress object has slightly different information from the address data that the ClientLocation API returns. NOTE: I would love to see this just called ‘address’ to help the shim.

To give you control when you need it, you can ask the navigator.geolocation object what type it is. navigator.geolocation.type will be null if it is native, but ‘Gears’ or ‘ClientLocation’ if a shim kicks in. You can also check navigator.geolocation.shim to see if it is augmented code.


There is some fun implementation code in there if you poke around. For example, for the ClientLocation API, when you make a call, it will be added to a queue if the Google Loader hasn’t fully loaded yet, and it will kick off that call when finished. Dealing with dynamically creating <script src> as a loading mechanism sure is fun!

I like the idea of jumping straight to the W3C standard and updating the shim as the APIs change. That way, when browsers catch up, the code will still work using the native APIs and you don’t have to change a thing.

I also hope that we get general reverse geocoding in place, which would enable me to even take the native “standard” and strap on useful address info to the bare bones lat/long.

Where are you?

Posted by Dion Almaer at 9:14 am

3.6 rating from 30 votes


Comments feed TrackBack URI

Looks neat, though for whatever reason the HTML5 version couldn’t find me (though I clicked Allow on the Gears prompt) while the pure ClientLocation version could find me. It doesn’t look like you’re using ClientLocation as a fallback for the HTML5 version?

Comment by Matthew Lieder — August 26, 2008

Take a look at Nico Goeminne’s client side ReverseGeocoder – based on Google Maps API: http://nicogoeminne.googlepages.com/documentation.html

I used it to reverse geocode many points, and it works great.

Comment by webEater — August 26, 2008

I’m getting the same issue as Matthew. Gears can’t find me ;[

Comment by grah — August 26, 2008

Great idea! By the way Firefox 3.1 beta has support for the geo location API, haven’t tested yet though.

I have 2 problems with your current implementation:
– computer that doesn’t have gears installed doesn’t fall back to ClientLocation for some reason
– computer that has gears installed doesn’t fall back on ClientLocation when Deny is clicked.

Will let you know if I find a solution.

Comment by Yannick — October 16, 2008

Sorry, I have to correct my previous comment. Replace the line with:
(I forgot the Not! and second it’s better to test the type of google.gears instead of just doing a boolean check)

Comment by archolyte — March 12, 2009

Nice article. I also created a google gadget application to display a host’s geolocation on google maps. Take a look at it here: http://www.codazzle.com. Hope you guys like it.

Comment by AmitChauhan — March 13, 2009

Client side geolocation accessis limited. 1) safari in iPhone ask the visitor to allow it 2) it works only on mobile devices. Try a look at the IP to Geolocation APIs, combine it and you can access via javascript!


Comment by wingi — August 6, 2009

Leave a comment

You must be logged in to post a comment.