Long time ago since the last post about software on my blog. However, far of meaning a lack of interest or passion regarding technology, I lived a nice experience working in the MAEMO project and having the opportunity to participate in one of the most interesting GNOME related projects I’ve ever been involved to. I have to admit that it was a working in the shadow age but you all know how this kind of projects are 😉 ; even though I think I contributed with my two cents. Besides the passion and energy applied to the project by all my development group at Igalia, the GDigicam component was born from this effort as a small (for the time being) contribution to the community.
But now its time to live new experiences, perhaps not as much relevant than the ones made for such a famous project, but for sure more exciting in terms of technological challenges and because I’m having the chance to work on what I love. Geolocation is one of my secret passions, being considerably incremented after my experience in the mobile market, where I think this kind of technologies are going to be one of the keys of such smart devices.
Since the Birmingham GUADEC, i’ve been looking at the GeoClue project progress and analyzing the strong and weak points of this technology. This is the first of a series of posts I’m working on, with the aim of providing a complete review of this project.
Lets put the first stone and talk about what GeoClue actually is. From an academic point of view GeoClue could be understood as a framework, in the sense of providing integration of several kind of tools for Geolocation acquiring; it does not provide position data by itself, but through different kind of Geolocation providers:
- Hostip: This provider uses http://www.hostip.info to get current position and address based on the current public IP address.
- Plazes: This provider uses http://plazes.com to get current position and address based on current router mac address
- Manual: This provider exists to let the user specify the current address.
- Localnet: This provider does not strictly speaking require an internet connection, but it does require a connection to a router: it uses the current router mac address and a local keyfile to provide Address data.
- Gsmloc: This provider uses the Gammu library and http://opencellid.org/ to provide position data. It gets cell identification data (MCC, MNC, LAC, CID) from Gammu and queries a position from opencellid with that data.
- Gypsy: Gypsy is a gps multiplexing daemon with a D-Bus interface. Gypsy provider requires the option org.freedesktop.Geoclue.GPSDevice to be set.
- GPSd: GPSd is a gps daemon that uses TCP sockets for communication. The daemon must be running when the provider starts.
- Yahoo: The provider accepts two options org.freedesktop.Geoclue.GPSDevice and org.freedesktop.Geoclue.GPSHost.
- Geonames: This provider uses the Geonames web service to provide geocoding/reverse geocoding service.
The GeoClue project has a great potential, because it integrates several and very different kind of Geolocation services. Nowadays, Geolocation capabilities are a must for both, handheld devices and Desktop, but in a global world and being “mobile people” no one of such services is enough by itself to provide location at any time and place.
I think thats enough for this post. I don’t like too much the posts with huge amount of information, usually hard to digest. So stay tunned because I have a lot to say about GeoClue:
- Technical review of GeoClue.
- Geolocation: state of the art and business opportunities.
- GeoClue and Augmented Reality
- GeoClue and WebKit