Location Service - Geoclue vs whole cloth

Registered by Thomas Voß on 2013-03-01

Ubuntu Touch, as any other smartphone and tablet OS, needs a location service.

A location service is an abstraction layer on top of GPS and other things used to get a device's location. It's a deamon that fetches location from different providers (gps, cellular network, wifi) and gives the resulting location information to client applications.

Blueprint information

Thomas Voß
Thomas Voß
Thomas Voß
Series goal:
Accepted for saucy
Good progress
Milestone target:
Started by
Thomas Voß on 2013-05-28

Related branches



[xnox] for the installer & datetime indicators we are also interested in the geolocation support to e.g. to set a sensible default during installation / configuration of the device and change timezones when one travels. At the moment the installer is using http://geoname-lookup.ubuntu.com/?query=New%20York which is GeoIP based service the source code is available from lp:ubuntu-geonames . It would be nice to integrate/improve geolocation and combine GPS & GeoIP data =)

[dandrader] tvoss want it made in C++/boost instead of Qt. And also the D-Bus interfaces should be considered implementation details and not part of the public API. Both clients and providers would talk to a library and that would be the public API boundary.

[dandrader] Unless it's done in C/GObject there's no hope it can be accepted as freedesktop's GeoClue v2.

[dandrader] Due to my previous two items, the description of this blueprint is pretty much obsolete now.

[dandrader] For simplicity's sake it might be better to focus on in-process providers (i.e. plugins, shared libs) at first.

[from Description]

In the free software world there's a project that is close to what we need. It's called GeoClue and hosted on freedesktop. It's been dead (ie. no active development) for some years now. And its creator was expecting that either him or someone else would have come up with its next version (geoclue2) by now to fix its design and implementation issues (don't have a formal list, I'm just paraphrasing him here).

I studied geoclue's code and android's location service to see where we would go, what we would need. geoclue is written in C/Object which is arguably harder to read and to maintain. It also has no tests. In my personal opinion it's a liability/handicap instead of an asset. Cheap to use at first (it's already there) but costly overtime (improving and maintaining). I started modifying its code to better fit our needs but ended up giving up and gone for a rewrite in Qt/C++, which is a language and toolkit I'm very comfortable/productive with and that I think it's way easier to maintain and faster to develop on (for anyone, not just me :) ). Yes I know about not reinventing the wheel and not-invented-here syndrome, but in this case I do think this is the best way to proceed as the existing whell is kinda squared and cumbersome to work with. And in the end it's a rewrite and not a reinvention as the D-Bus interfaces and concepts, i.e. high level architecture, which is the most difficult part to come up with (and the most damaging, when got wrong), is all being used in geoclue2 (although modified/improved).

So my plan is to write geoclue2 in Qt/C++ and once it reaches its first release we would propose it to freedesktop's GeoClue to be its next version (I don't like to talk empty-handed and prefer to have something working in my hands when I do so). If they accept it, it's all good. If not, we will have to re-brand it as "Ubuntu Location Service".

Why C++:
 - It's arguably easier to write object-oriented code in a language that supports this paradigm.

Why Qt:
 - Ubuntu Touch already relies on Qt for its GUI, so it's a technology that is already there.
 - It's actively developed and is very well documented
 - Besides the regular toolkit features (containers, strings, timers, event loops, signal handdling) is also has an easy-to-use D-Bus wrapper and INI file parser (needed for describing installed providers). So it's a one-stop place for all we need.

Of course that's not the *only* possible good option (e.g. there's C++/Boost, maybe Python) but we have to make a choice and I'm very familiar with those technologies.

What we have

On the device we have ubuntu-gps-service, which is a daemon that has onwership over the GPS receiver and shares its readings with any number of client applications. There's also a plugin for Qt (ubuntu-qtlocation-plugin) that enables QML applications using Qt's Location API to get location info from that service.

geoclue-ubuntu-gps - A modified version of ubuntu-gps-service that implements geoclue's D-Bus interfaces, so that it can be used by geoclue master provider (i.e. geoclue's location service).

geoclue2-qt - It has all the basics in place, although I didn't do a live/real test with it yet (only unit tests and basic runs so far). It finds and loads location providers, selects the most appropriate one and gives location info to clients. Code is currently at lp:~dandrader/geoclue2/qt

Current work

* Client library for geoclue2-qt. A C++/Qt library to ease development of geoclue2 location providers and client applications. Of course, if providers or client applications are written in a different language or use a different toolkit they will have to use D-Bus directly. Unless someone comes up with libraries like libgeoclue2-glib.

* Modifying geoclue-ubuntu-gps to use geoclue2 interfaces, therefore turning it into geoclue2-ubuntu-gps.

What's missing for a first release (besides current work)

* Fine tuning its D-Bus interfaces. Taking in feedback from Loic Minier.
* location service logic: Consider a provider's status when selecting which provider to use
* packaging, testing it all on the phone.


Work Items

Work items for ubuntu-13.05:
Speak to hadess, compare requirements for a location API: TODO
[thomas-voss] Defining the interface for location API to the location providers: DONE
[thomas-voss] Defining the technology: DONE
[thomas-voss] Define location component in platform API: DONE
[thomas-voss] Implement the location service: DONE
[thomas-voss] Expose platform API to QtLocation: INPROGRESS

Dependency tree

* Blueprints in grey have been implemented.