Camp KDE: Geolocation

At this year's edition of Camp KDE, John Layt reported in on his research to try to determine the right course for adding geolocation features to KDE. Currently, there is no common API for applications to use for tagging objects with their location or to request geolocation data from the system. There are a number of different approaches that existing applications have taken, but a shared infrastructure that allows geolocation data to be gathered and shared between applications and the desktop environment is clearly desirable.

Layt began by explaining that he had more than a passing interest in geolocation, partly because he was born in New Zealand, has lived in Australia and South Africa, and now lives in the UK. Along the way, he has visited 47 countries. He has been studying archeology and how to use Geographical Information Systems (GIS) for that work, which have a clear connection to geolocation. He is best known in the KDE community for his work on calendars, holidays, and printing ("don't ask" about how he got involved in the latter, he said). In 2002, he started writing a virtual globe application called Kartographer, which is a distant ancestor of today's KDE globe application, Marble.

Geolocation basics

At the base level, geolocation consists of using and recording geographic coordinates that correspond to a particular location: latitude, longitude, and altitude will locate a point in 3D space. But there are additional pieces of information that are generally useful, like heading and velocity for navigation applications, as well as the accuracy of the coordinate information. GPS provides data accurate to within 10m or better, while IP address information provides far less accuracy (typically just narrowed down to a city at best). Generally applications are interested in two levels of accuracy, that more or less correspond to those measures, which he termed "fine" and "coarse" accuracy.

There are additional services that should be provided by a geolocation API, such as the current location of the device, as well as historic position information (i.e. where was the object 1 minute or hour ago). Converting things like addresses to geographic coordinates (geocoding), and the reverse, is also required. There are multiple possible providers of location information, GPS, IP address, cellular network location, visible WiFi access points, and so on, and there needs to be ways to switch between them. An application should be able to specify that it only needs coarse location information and the geolocation subsystem should use the appropriate provider(s).

Geolocation information is used in mapping and navigation applications, but there is more than just map data involved as there are various points of interest that get incorporated: landmarks, places, businesses, and so forth. Obviously, these kinds of applications are huge on mobile devices, but there is no good reason that desktops should not have access to the same kinds of data. Providing a geolocation framework just for mobile devices is an "arbitrary split", and one that shouldn't exist, Layt said. "Why should mobiles have all the fun?"

Geolocation applications

Geolocation can be added to applications beyond the obvious mapping/navigation programs, and Layt mentioned several, including star map applications like KStars (using the Android Sky Map application as an example), weather plasmoids (noting that his laptop was still showing London weather after he arrived in San Francisco), proximity for social and messaging applications, and mapping locations in address books. He said that there are "many many more" applications that could use geolocation if it were more easily available.

He also noted some specific applications that already use geolocation. digiKam can place photos on maps based on coordinates in the metadata or add those coordinates to photos that lack them. It allows for fairly sophisticated searches ("give me all the photos within 100m of a particular point"), by using its own library (libkmap) which is an abstraction over Google maps or Marble.

Layt has some ideas on other possibilities that geolocation could enable. Changing locations could modify the state of the desktop and system, by asking the user if they want to switch timezones or locale when their location changes. Moving from work to home could change Plasma activities, closing down work applications and documents, and opening up those that make sense for home. Those kinds of decisions will require a way to name locations (e.g. "home") and to also allow for some fuzziness in what defines the locations. Obviously, "home" is not defined by a single set of coordinates, and different locations will have different sizes, so there will need to be ways to define and store that information.

HTML 5 has geolocation support that could optionally be used to send location information to web sites for narrowing searches or discovering information based on one's current location. In addition, the semantic desktop (e.g. Nepomuk) could log location-based information if it were easily obtainable.

The ideal solution would have single API for all platforms, mobile or desktop. It would be lightweight so that there would be fewer barriers to including it into those platforms. It also would be available at a low level in the stack, so that it can be used by as much of the rest of the stack as possible. The solution would also use free data providers for map data to avoid the restrictions placed by the proprietary data providers (e.g. Google or Bing maps). A solution along those lines would allow the applications to largely free themselves from each having to implement its own solution.

Existing choices

There are a number of current solutions that might be adapted for the needs of a KDE platform solution. One is the Plasma DataEngine for geolocation that has been used by Plasma applets, mostly for weather applications so far. It has backends for gpsd or IP-based geolocation but does not provide support for geocoding.

Marble and libmarble have an extensive feature set for geolocation and mapping using free data providers. The library has few dependencies and can be used in a Qt-only mode, so that there are no KDE dependencies. The library itself is around 840K in size, but the data requirements are, unsurprisingly, much higher, around 10M. The biggest problem with using libmarble is that it does not provide a stable interface, as binary and API compatibility are not guaranteed between releases.

Another option is GeoClue, which is a freedesktop.org project for "geoinformation" that has support for geolocation, but not mapping. It is lightweight at 370K and includes multiple backends, choosing which to use based on the accuracy requirements of the query. One big problem, from the perspective of the KDE project at least, is that GeoClue has a dependency on gconf to provide a single configuration setting. Layt said that the GeoClue developers have been reaching out to KDE to suggest that it use the service, but the gconf dependency makes that impossible. Layt and others have been trying to get that changed for some time, but it hasn't happened yet; the projects need to work together to get that solved, he said.

The QtLocation module, which is part of the QtMobility framework, has support for geolocation, mapping, and landmarks. It only does simple tile maps and its landmarks are stored in non-standard ways, but those can be translated into a usable format. It lives low enough in the stack for use by the rest of the system and is supported and available for all mobile platforms. The desktop version is not maintained, so work would have to be done there, though there is a version for MeeGo that could be adapted for Linux desktop use. The biggest problem with QtLocation is that the available backend is for Ovi Maps, which comes with a huge number of restrictions.

Layt said that the Ovi Maps restrictions were much like those placed on the data from other providers like Google and Bing. The data providers "don't want you to do anything terribly useful with the data". There is a laundry list of things that are forbidden with Ovi Maps, such as reusing the data in a way that competes with the Ovi Maps application or altering the data that gets returned from the server. It requires registration to use, may not be available in some countries, and, rather oddly, requires "good manners" from its licensees.

There were indications that Ovi Maps might be opening up to more uses not so long ago, but Layt didn't seem very optimistic about that given the recent events at Nokia. Basically, he said, KDE needs to use free data from sources like OpenStreetMap.

In summary, there is no current solution that meets the needs of KDE. For now, mobile applications should probably use QtLocation, desktop applications should use libmarble, and Plasma applets should use the DataEngine. For the future there are several possibilities. Layt would like to use libmarble, but the lack of a stable API/ABI makes that difficult. QtLocation is stable enough but would require backends for free data sources. GeoClue is also attractive if the gconf dependency can be removed. He would like to see if a decision on the right approach could be made at the Platform 11 Sprint that will be held in June.

Camp KDE

Camp KDE is the yearly gathering of KDE developers in North America, and is meant to help reconnect developers in that region with their more numerous European counterparts. This is the third Camp KDE and the fourth KDE event held in North America. Around 35 people attended the first day's sessions, with many of those attending Camp KDE for the first time. Celeste Lyn Paul, who helped organize the event, noted that attracting "first timers" was exactly why the event exists, to try to grow the North American community both in size and in the minds the KDE communities elsewhere in the world.