sorted by: recent | see :
popular
Content Tagged with geo + Ajax
navigator.geolocation now available in Firefox via Geode
When I posted about using navigator.geolocation now the only support that I had was via Gears and the ClientLocation API. I wrote the shim to try to get you the W3C API no matter what, and today we have the first implementation in a browser, via Geode.
Geode is the latest project in Mozilla Labs that gives you that API in Firefox. Aza Raskin has a nice Food Finder application that ties it together with local search and maps.
Differences between Geode and Geolocation in Firefox 3.1
Geode and the Geolocation Services in Firefox 3.1 will use the same W3C API for Geolocation, meaning that the same Javascript code will work in both. The still-in-developement Firefox 3.1 version will allow the user to choose a geolocation service provider, which can either be a peripheral device like a GPS, or a web-based service provider like we’ve used in Geode. We’ll be using the feedback we get from Geode, as well as the feedback we see on the upcoming Firefox 3.1 Beta and Fennec Alpha releases, to refine the feature before shipping it in a future Mozilla product release. We’re particularly interested in ensuring that the final implementation is as sensitive to user privacy and choice as possible.
They also got some partners to start playing with this:
To kick off Geode, two other websites have started innovating with location. Both require accounts before you can try them out.
Pownce is a service that makes it easy to send stuff (music, photos, events, and messages) to your friends. Adding the power of location — where you are when you uploaded a photo or sent a message — paints a compelling picture that helps you discover friends and activities around you. Head there to see it in action (you’ll have to sign up for an account).
Yahoo! Fire Eagle is a service that acts as a broker for your location, creating a single place where any web service, from any device can get access to your last updated location. Fire Eagle integrates with Geode so that you’ll never have to manually enter your location again. Once you have a Fire Eagle account, you can see Geode working here.
navigator.geolocation: Using the W3C Geolocation API today
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
gearsAddressobject 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 asnull, the same as the W3C standard - That
gearsAddressobject 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.
Implementation
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.
